Bug 222872 - lang/ruby26, lang/ruby27 and lang/ruby30: does not build with POSIX-compliant sh -c
Summary: lang/ruby26, lang/ruby27 and lang/ruby30: does not build with POSIX-compliant...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ruby (Nobody)
Depends on:
Blocks: 220587
  Show dependency treegraph
Reported: 2017-10-08 21:10 UTC by Jilles Tjoelker
Modified: 2021-04-06 20:29 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (ruby)

allow both current and POSIX-compliant sh -c (906 bytes, patch)
2017-10-08 21:10 UTC, Jilles Tjoelker
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jilles Tjoelker freebsd_committer 2017-10-08 21:10:45 UTC
Created attachment 187013 [details]
allow both current and POSIX-compliant sh -c

The RB_SET_CONF_VAR macro uses a construct like

sh -c 'command' -- arg0 arg1

and assume that $0 will expand to arg0 and $1 will expand to arg1.

Our current sh implements it that way. However, POSIX specifies that $0 will
expand to -- and $1 will expand to arg0, since the command string is an operand
and not an option-argument. Bug #220587 requests making sh POSIX-compliant in
this regard.

If the argument after the command string does not start with '-', the current
sh behaves as required by POSIX. Therefore, the macros should be adjusted so
this is always the case.

Tested with poudriere, stable/10 with patched head sh.
Comment 1 Jilles Tjoelker freebsd_committer 2017-10-08 21:17:56 UTC
The same problem affects lang/ruby23 and lang/ruby24, and the patch is the same (though context differs a bit for lang/ruby24).
Comment 2 Walter Schwarzenfeld freebsd_triage 2019-02-06 13:03:50 UTC
Comment 3 Koichiro Iwao freebsd_committer 2019-02-08 00:38:45 UTC
ruby22 is now EoL and already removed from ports tree.
Comment 4 Koichiro Iwao freebsd_committer 2019-02-08 00:43:36 UTC
Oops, it affects ruby23 and ruby24.
Comment 5 Rene Ladan freebsd_committer 2021-04-06 14:48:10 UTC
Is this still relevant with lang/ruby27 ?
Comment 6 Jilles Tjoelker freebsd_committer 2021-04-06 20:29:17 UTC
(In reply to Rene Ladan from comment #5)
Yes, the problematic code is still in lang/ruby26, lang/ruby27 and lang/ruby30.