Crystal::System::Process shell invocation broken on Linux with FreeBSD sh

[valpackett]

Chimera Linux uses FreeBSD sh, so this condition:

crystal/src/crystal/system/unix/process.cr

Lines 215 to 217 in 7aa0282

	{% if flag?(:freebsd) || flag?(:dragonfly) %}
	shell_args << ""
	{% end %}

doesn't match and as a result, the substitution is broken which breaks e.g. the compilation of macros (ld: error: undefined symbol: main due to no object files actually getting provided) :/

Is the conditional actually necessary? I'm not sure when the empty arg could break things…

[nekopsykose]

a quick test in yash, bash, zsh, dash, mksh, busybox ash reveals that all of them are consistent in printing 1 2 3 for shell -c "echo \$@" -- "1" "2" "3" and -c "echo \$@" -- "" "1" "2" "3". the empty "" is only required for the bsd shells apparently, but it also does not break any other. this should be safe to just remove the if condition and make it universal

[nekopsykose]

hm, no, it seems the -- is being passed as $0. so the reason it happens to work 'consistently' is because the shell is actually using -- as $0, and then $@ is 1-onward. but on the bsd shell, the -- delimiter is actually parsed, and then the "" is required to make $0 something else (and so using it universally will break $1 on other shells with a nul)

[nekopsykose]

ah ok, so just replacing -- with sh (any string) should work. /bin/sh -c 'program "$@"' sh 1 2 3 seems to work with every shell

[q66]

basically just replace -- with sh in the original args and then drop the special case for freebsd/dragonfly entirely

[straight-shoota]

Oh that's interesting. So I suppose another option to write the same thing would be ["/bin/sh", "-c" "$0 ${@}", command, *args]?
We can't do that though because it would break use cases where command includes ${@}.