The following issue has been SUBMITTED.
======================================================================
https://www.austingroupbugs.net/view.php?id=1440
======================================================================
Reported By: ciprian_craciun
Assigned To:
======================================================================
Project: 1003.1(2016/18)/Issue7+TC2
Issue ID: 1440
Category: System Interfaces
Type: Omission
Severity: Comment
Priority: normal
Status: New
Name: Ciprian Dorin Craciun
Organization:
User Reference:
Section: system(3)
Page Number: N/A
Line Number: N/A
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2021-01-04 15:49 UTC
Last Modified: 2021-01-04 15:49 UTC
======================================================================
Summary: Calling `system("-some-tool")` fails (although it is
a valid `sh` command)
Description:
This report is in relation to the following `glibc` and Linux man-pages
issues:
* https://sourceware.org/bugzilla/show_bug.cgi?id=27143
* https://bugzilla.kernel.org/show_bug.cgi?id=211029
However it seems that the root cause is the interaction mandated by the
POSIX standard between `system(3)` and `sh(1)`.
In simple terms, calling `system("-some-tool")` has an unexpected behaviour
when delegating that to `sh`, as in `sh -c -some-tool`. (For how to
replicate this just see the first link.)
In more details:
* the `system(3)` specification requires that:
~~~~
# from:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html
The system() function shall behave as if a child process were created using
fork(), and the child process invoked the sh utility using execl() as
follows:
execl(<shell path>, "sh", "-c", command, (char *)0);
~~~~
* however the `sh(1)` specification requires that:
~~~~
# from https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html
sh -c [-abCefhimnuvx] [-o option]... [+abCefhimnuvx] [+o option]...
command_string [command_name [argument...]]
~~~~
I.e. `sh(1)` allows extra flags between `-c` and the `command_string`;
however the `system(3)` doesn't account for a command that might start with
a hyphen.
Thus, depending on what the command might be, the outcome is either a
missing command (if the given command resembles an option accepted by
`sh`), or an unknown option (if the given command doesn't resemble an
option accepted by `sh`).
Desired Action:
The "optimal" solution would be to require `system(3)` to call `sh(1)` with
an extra `--` between `-c` and the `command`, as in:
~~~~
execl(<shell path>, "sh", "-c", "--", command, (char *)0);
^^^^
~~~~
Given that `sh(1)` already mandates a compliant shell to correctly handle
`--`, this shouldn't have many unintended consequences.
Alternatively add a warning in the specification stating that a command
starting with `-` has an undefined behaviour and should be worked-around by
preperding a space to any such command.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2021-01-04 15:49 ciprian_craciunNew Issue
2021-01-04 15:49 ciprian_craciunName => Ciprian Dorin
Craciun
2021-01-04 15:49 ciprian_craciunSection => system(3)
2021-01-04 15:49 ciprian_craciunPage Number => N/A
2021-01-04 15:49 ciprian_craciunLine Number => N/A
======================================================================
