|Anonymous | Login||2023-03-21 04:49 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001204||[1003.1(2016/18)/Issue7+TC2] Shell and Utilities||Objection||Clarification Requested||2018-08-31 16:22||2019-12-04 11:37|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||See Note: 0004346|
|Summary||0001204: Vague wording as to the validity of s/RE command without trailing delimiter and replacement|
The s (Substitute) command has the following format:
Under the heading "Commands in ed", the specification says:
"If the closing delimiter of an RE or of a replacement string (for example, '/' ) in a g, G, s, v, or V command would be
the last character before a <newline>, that delimiter can be omitted, in which case the addressed line shall be written.
For example, the following pairs of commands are equivalent:
The wording "the closing delimiter of an RE or of a replacement string" is vague, and can be read as either referring to both the RE and replacement fields of the s command, or just the last field (as it refers to both commands with one argument, and commands with two arguments).
The "s" example is of a command that includes both the RE and replacement, without the closing delimiter.
However, there is no example such as "s/s1" or "s/s1/".
It is not specified in the text if "s/s1" is a valid commands, or how should they behave - specifically, what should be the value of the replacement string.
In contrast, the specification for the ex utility clearly allows "s/s1", and describe how it should be handled:
(quote from the "Substitute" section)
"The trailing delimiter can be omitted from pattern or from repl at the end of the command line. [...]
If only repl is not specified or is empty, the pattern shall be replaced by nothing."
Of the various ed implementation I surveyed, all of them allow for "s/s1", with the replacement string being empty.
One exception is GNU ed, which in the recent release 1.14.2 has decided that "s/s1" is invalid.
See https://lists.gnu.org/archive/html/bug-ed/2017-10/msg00003.html [^]
|Desired Action||Clarify whether the partial command "s/s1" is valid, and how it should be interpreted.|
edited on: 2019-03-28 16:12
The standard states that lines "shall be written" for all of the g, G, s, v, or V commands, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.
Current implementations of ed do not behave as described in the standard.
Notes to the Editor (not part of this interpretation):
On page 2681 line 87421 section ed, change:
If the closing delimiter of an RE or of a replacement string (for example, '/') in a g, G, s, v, or V command would be the last character before a <newline>, that delimiter can be omitted, in which case the addressed line shall be written.
|Interpretation proposed: 7 October 2019|
|Interpretation Approved: 11 Nov 2019|
|2018-08-31 16:22||salty-horse||New Issue|
|2018-08-31 16:22||salty-horse||Name||=> Ori Avtalion|
|2018-08-31 16:22||salty-horse||Section||=> ed|
|2018-08-31 16:22||salty-horse||Page Number||=> 0|
|2018-08-31 16:22||salty-horse||Line Number||=> 0|
|2018-09-16 22:19||Antonio Diaz||Issue Monitored: Antonio Diaz|
|2019-03-28 16:12||nick||Note Added: 0004346|
|2019-03-28 16:12||nick||Note Edited: 0004346|
|2019-03-28 16:13||nick||Interp Status||=> Pending|
|2019-03-28 16:13||nick||Final Accepted Text||=> See Note: 0004346|
|2019-03-28 16:13||nick||Status||New => Interpretation Required|
|2019-03-28 16:13||nick||Resolution||Open => Accepted As Marked|
|2019-03-28 16:14||nick||Tag Attached: tc3-2008|
|2019-10-07 15:17||agadmin||Interp Status||Pending => Proposed|
|2019-10-07 15:17||agadmin||Note Added: 0004610|
|2019-11-11 12:21||agadmin||Interp Status||Proposed => Approved|
|2019-11-11 12:21||agadmin||Note Added: 0004654|
|2019-12-04 11:37||geoffclare||Status||Interpretation Required => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|