After having seen a similar change implemented for glibc, I did the same in dpkg to make its shell invocations more robust and avoid missparsing in case a command starts with a «-» (which would be very unusual, but…). See <https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=f013195c70995235340e99107058f591175f0a57>. Just noticed afterwards that this did not work on FreeBSD's /bin/sh: ,--- $ sh -c -- "echo \$0" name arg echo $0: --: not found `--- This though seems to work fine on posh, dash, ksh93, bash, and the default sh on NetBSD, OpenBSD, Solaris and macOS. But neither on sh, ksh nor bsh on AIX 7.3. For now I guess I'll need to make its usage conditional on the system.
FreeBSDs sh doesn't do any option parsing after -c, this makes accidents due to an unusual nammed command impossible and lead to the behaviour you observe. sh tries to run the command ´--´ and uses ´echo $0´ providing ´arg´ as argument. As you don't have any command named ´--´ on your system sh reports it with its name ´echo $0´. That is POSIX incompatiple behaviour. I'm in favour of documenting this incompatibility and closing this report as ´Works As Intended´
Hit this one, is there a way to detect this broken shell somehow ? posix says you should accept --. POSIX TCs (future standards) says system(3) and popen(3) must behave as execve sh -c -- command too. makes impossible to write a command line that behaves equally on all posix shells.
It should work to prepend a space to the command string.
I'm not sure I understand your comment about prepending a space. Could you clarify with an example invocation?
sh -c ' --' attempts to invoke the '--' utility regardless of the interpretation of '-c'. This does have a side effect of breaking echoed parts of the command (as seen in bash syntax errors) or column numbers, but it is only necessary if the command starts with '-'.