View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00015291003.1(2016/18)/Issue7+TC2Shell and Utilitiespublic2021-10-30 15:542024-06-11 09:07
Reportersteffen Assigned To 
PrioritynormalSeverityEditorialTypeEnhancement Request
Status ClosedResolutionAccepted As Marked 
Namesteffen
Organization
User Reference
Sectionex
Page Number2732
Line Number89418-89420
Interp Status---
Final Accepted TextSee 0001529:0005635.
Summary0001529: ex: follow-up to issue #1440
Description""
Desired Actionon 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...
Tagsissue8

Relationships

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

Activities

mirabilos

2021-12-05 00:51

reporter   bugnote:0005542

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.

steffen

2021-12-06 18:02

reporter   bugnote:0005544

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..

philip-guenther

2021-12-06 20:49

reporter   bugnote:0005545

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.

steffen

2021-12-07 13:05

reporter   bugnote:0005546

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.

Don Cragun

2022-01-27 16:55

manager   bugnote:0005635

Last edited: 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.

geoffclare

2022-02-11 15:28

manager   bugnote:0005672

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 0001529: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
2024-06-11 09:07 agadmin Status Applied => Closed