As the subject states, the `system` function fails when calling it with a command that starts with a hyphen, which is an accepted executable name, and an accepted `sh` command. Let's assume one has an executable starting with a hyphen, as in: ~~~~ ln -s -T /usr/bin/echo ~/.bin/-echo ~~~~ Assuming that `~/.bin` is in `$PATH` the following work in "plain" `sh` / `bash`: ~~~~ type -P -- -echo which -- -echo -echo a b ~~~~ However the following simple `main.c` doesn't work: ~~~~ > cat ./main.c main() { system("-echo a b"); } > gcc -o ./main ./main.c > ./main sh: - : invalid option ~~~~ The issue is simple: * `system("-echo a b")` end's up calling `sh -c '-echo a b'`; * unfortunately the `-c` argument states that it will use as a command the **first non-option argument** which in this case there is none as `-echo a b` is mistaken as an option argument; The solution would be updating `system` to issue `sh -c -- {command}`, as in (taking the manual as example): ~~~~ execl("/bin/sh", "sh", "-c", "--", command, (char *) NULL); ^^^^ this is added ~~~~ However this proposed solution might break systems where `sh` doesn't accept the `--` separator. (Is this the case?) An alternative would be, if the command starts with a hyphen then a space could be added at the beginning, as in: `sh -c ' -echo a b'` My environment: * `sh --version` -- `GNU bash, version 5.0.18(1)-release (x86_64-suse-linux-gnu)`; * `getconf --version` -- `getconf (GNU libc) 2.32`
Unfortunately, this bug is required by POSIX, which requires passing the string as an argument to the -c option of the shell. You could report this to the Austin Group as a defect in POSIX: <https://www.austingroupbugs.net/>
> [...] this bug is required by POSIX [...] OK, I might understand this, however I find it hard to believe that `glibc` can do nothing about this... For example one could: (A) Update the `system(3)` `glibc` man page to warn the user that at the moment there is a bug in the POSIX specification, and that any command starting with `-` would in fact trigger a failure of `sh`. (B) Update the `system(3)` implementation so that when a command starts with `-` it prepends a space. This should have almost zero consequences because spaces are allowed (and trimmed) by virtually all existing `sh` interpreters out there.
POSIX specifies the exact value of the -c argument. The manual pages are maintained as a separate project: https://www.kernel.org/doc/man-pages/
> The manual pages are maintained as a separate project: > https://www.kernel.org/doc/man-pages/ OK, I've opened a feature request there: https://bugzilla.kernel.org/show_bug.cgi?id=211029 ---- Out of curiosity, was this "bug mandated by POSIX" known or?
The Bash manual page does mention that of the "first non-option argument", but the Dash manual page doesn't (Debian has sh -> dash). However, I confirmed this also happens on systems with Dash.
I've started the process of reporting the bug to the POSIX Austin Group, however as I don't have an account there and the procedure requires direct contact with the group's chair, it most likely will take some time... I'll report back when I have some news.
OK, I've opened an issue on the POSIX bug tracker: https://www.austingroupbugs.net/view.php?id=1440