Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001529 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Enhancement Request 2021-10-30 15:54 2022-02-11 15:28
Reporter steffen View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name steffen
Organization
User Reference
Section ex
Page Number 2732
Line Number 89418-89420
Interp Status ---
Final Accepted Text See Note: 0005635.
Summary 0001529: ex: follow-up to issue #1440
Description ""
Desired Action on location as above change

  The ex utility shall execute the program named by the shell edit option. It shall pass two arguments to the program; the first shall be −c, and the second shall be the expanded arguments to the ! command as a single argument.

to

  ...three arguments to the program; the first shall be -c, the second --, and the third shall be...
Tags issue8
Attached Files

- Relationships
related to 0001440Applied Calling `system("-some-tool")` fails (although it is a valid `sh` command) 

-  Notes
(0005542)
mirabilos (reporter)
2021-12-05 00:51

I’m not sure requiring the ["sh", "-c", "--", arg] behaviour in the standard is a good thing.

This is an implementation detail.

I agree with requiring it for system() and friends, but for user-space utilities, I would instead write something like “run it with sh -c in a safe way, for example by using a double-dash thingy”.

This leaves people who write portable software (such as MirBSD’s ed(1)) the option to do it by prefixing a space instead, which will work on both “old” and “new” systems; ed(1) has a leading character in the buffer which it can use for this anyway.

Other applications, where the arg comes in on its own, should not need copying, so using “sh -c --” is a good thing there (especially if the standard sh(1) supports that), but your proposed wording makes it harder for real-world systems.
(0005544)
steffen (reporter)
2021-12-06 18:02

This will affect future standards only.
And it only affects compliant systems, Thorsten.
For utilities OpenBSD for example i think entirely removed the possibility to use ! style commands, no? For example..
(0005545)
philip-guenther (reporter)
2021-12-06 20:49

No, Steffen, OpenBSD did not break the '!' command in its ex. This ticket is not a useful place to review the changes you're probably thinking of.

I'm with Thorsten that the standard should just specify that the shell shall be invoked by ex in a manner that results in a shell command that starts with a hyphen actually invoking that shell command and not triggering the shell's own option parsing.
(0005546)
steffen (reporter)
2021-12-07 13:05

Oh i see, Philip. I just remembered de Raadt's ~"one can always use ^Z", and in that context the "removal of many !-style commands in the OpenBSD tree".

We have seen several times that edges were interpreted as "was surely a fault/miss/misnomer in the original standard", and here (and in some other places) the standard text explicitly mentions the complete command line that shall be used, of doubtful correctness.
Philip's suggestion to replace these is of course an option.
(0005635)
Don Cragun (manager)
2022-01-27 16:55
edited on: 2022-01-27 17:02

Change the synopsis of the Escape command on P2730, L89413-89414 from:
! command
[addr]! command
to:
!command
[addr]!command



Add a new paragraph to APPLICATION USAGE following P2743, L89822:
Unlike the system() function, ex does not pass "--" between the "-c" option and the command string, so that programs for which -c takes an option-argument can be used in the shell edit option. Users who want to use an escape command to execute a utility whose name starts with <tt>'-'</tt> or <tt>'+'</tt> need to provide a pathname for that utiity that does not start with either of those characters, or precede the utility name with a <blank> character.


Add a new section to the ex RATIONALE on P2756, before L90368:
Escape


In Issue 8 the system() function (see xref to system()) was changed to require that the POSIX shell be invoked with <tt>"sh"</tt>, <tt>"-c"</tt>, <tt>"--"</tt>, and command arguments to make it easier to execute programs with <hyphen-minus> ('-') or <plus-sign> ('+') as the first character of the program's filename. A similar request to have the ex escape do the same was not accepted. Unlike system() (which always invokes a POSIX shell), ex invokes the program named by the shell option. For example, the csh and tcsh shells that are frequently used as login shells do not recognize <tt>--</tt> after <tt>-c</tt> as an end-of-options indicator. The program need not even be one that recognizes any POSIX shell command line syntax. Some users invoke shell scripts to process lines that are being supplied to the specified utility These utilities know that they will be given <tt>-c</tt> as a first argument and just ignore it. Any utilities used in this manner would have to be modified to skip over another argument (the <tt>--</tt>) to find the desired argument.


(0005672)
geoffclare (manager)
2022-02-11 15:28

When applying this bug I noticed that there is already an entry for Escape in the RATIONALE on page 2762, so I added the new paragraph there instead of in a new Escape entry on page 2756.

- Issue History
Date Modified Username Field Change
2021-10-30 15:54 steffen New Issue
2021-10-30 15:54 steffen Name => steffen
2021-10-30 15:54 steffen Section => ex
2021-10-30 15:54 steffen Page Number => 2732
2021-10-30 15:54 steffen Line Number => 89418-89420
2021-12-05 00:51 mirabilos Note Added: 0005542
2021-12-05 01:11 Don Cragun Relationship added related to 0001440
2021-12-06 18:02 steffen Note Added: 0005544
2021-12-06 20:49 philip-guenther Note Added: 0005545
2021-12-07 13:05 steffen Note Added: 0005546
2022-01-27 16:55 Don Cragun Note Added: 0005635
2022-01-27 16:56 Don Cragun Note Edited: 0005635
2022-01-27 16:58 Don Cragun Interp Status => ---
2022-01-27 16:58 Don Cragun Final Accepted Text => See Note: 0005635.
2022-01-27 16:58 Don Cragun Status New => Resolved
2022-01-27 16:58 Don Cragun Resolution Open => Accepted As Marked
2022-01-27 16:59 Don Cragun Tag Attached: issue8
2022-01-27 17:02 Don Cragun Note Edited: 0005635
2022-02-11 15:28 geoffclare Note Added: 0005672
2022-02-11 15:28 geoffclare Status Resolved => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker