Re: ed(1) man page doesn't mention use of single / and ?
On Sat, Jul 13, 2019 at 12:37:29AM +0200, Ingo Schwarze wrote:
> Hi Jason,
>
> Jason McIntyre wrote on Sun, Jul 07, 2019 at 08:56:43PM +0100:
>
> > this is getting silly - we're mixing talking about how /re/ and ?re?
> > work as addresses and as regular expressions in other places. dropping
> > the trailing [/?] does not apply to regular expressions everywhere.
>
> Actually, it does, though you are right in so far as the three
> cases (addresses, global searches, and replacements) differ in
> subtle ways.
>
> > even if i have this wrong (to be fair, not that unlikely), we should
> > just concentrate on one thing at a time.
>
> We have now taken care of the case of addresses.
>
> The case of replacements is already described correctly:
>
> > regarding how dropping two delimiters works in an 's' command, although
> > i'm not sure really of the reason, you can do:
> > 1,$s/re
> > which effectively drops /replacement/
>
> Yes, this is described as follows:
>
>If one or two of the last delimiters is omitted, then the last line
>affected is printed as though the print suffix p were specified.
>
> Admittedly, the grammar is awkward ("two of things is omitted"),
> and it is not said explicitly that omitting both delimiters implies
> deleting the re without a replacement - but one could argue that
> is implicitly to be expected because omitting the middle delimiter
> implies that the replacement can only be empty. If you think this
> should be improved, we can polish it later.
>
>
> So what remains to be decsribed is the case of global searches (gGvV).
>
> Here is what POSIX says about those:
>
> 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 , that delimiter can be omitted, in
> which case the addressed line shall be written.
>
> Our implementation appears to comply.
>
> While documenting this, also fix a few glitches in the vicinity:
>
> * The wording "the current address is set to the last line affected
>by command-list" can easily be misunderstood. The temporal sense
>of "last" is intended, but it can easily be read as the last (i.e.
>highest numbered) line in the file. So let's better talk about
>the "last command executed", not about the "last line".
>You can easily see that this is correct with a command like
>
> g/.../+p\
> -p
> .
>
>which, for each matching line, first prints the following line,
>then the matching line itself, and leaves the matching line
>(printed by the last command) as the current line, not the
>following line, even though the following line was also "affected"
>and comes later in the file.
>
> * Avoid the confusing wording "a newline alone in command-list".
>The newline is not *in* the command list, but it comes after
>the command list, terminating it.
>
> * For G, explicitly say that an empty command list has a different
>effect compared to g: for g, it does the same as p, whereas for G,
>it does nothing at all.
>
> There is nothing to do for v and V, which mostly point to g and G only.
>
> OK for the patch below?
>
> Yours,
> Ingo
>
hi.
yes, ok by me.
jmc
>
> Index: ed.1
> ===
> RCS file: /cvs/src/bin/ed/ed.1,v
> retrieving revision 1.72
> diff -u -p -r1.72 ed.1
> --- ed.1 12 Jul 2019 19:28:48 - 1.72
> +++ ed.1 12 Jul 2019 22:17:47 -
> @@ -377,7 +377,7 @@ The current address is set to the line c
> command-list is executed.
> At the end of the
> .Ic g
> -command, the current address is set to the last line affected by
> command-list.
> +command, the current address remains as set by the last command executed.
> If no lines were matched,
> the current line number remains unchanged.
> .Pp
> @@ -392,22 +392,26 @@ Any commands are allowed, except for
> .Ic v ,
> and
> .Ic V .
> -A newline alone in command-list is equivalent to a
> +An empty
> +.Ar command-list
> +is equivalent to a
> .Ic p
> command.
> +In this case, the trailing slash can be omitted.
> .Sm off
> .It (1,$) Ic G No / Ar re No /
> .Sm on
> Interactively edits the addressed lines matching a regular expression
> .Ar re .
> +The trailing slash after
> +.Ar re
> +can be omitted.
> For each matching line, the line is printed, the current address is set,
> and the user is prompted to enter a
> .Ar command-list .
> At the end of the
> .Ic G
> -command, the current address is set to the last line affected by
> -.Pq the last
> -command-list.
> +command, the current address remains as set by the last command executed.
> If no lines were matched,
> the current line number remains unchanged.
> .Pp
> @@ -415,11 +419,10 @@ The format of
> .Ar command-list
> is the same as that of the
> .Ic g
> -command.
> -A newline alone acts as a null command list.
> +command, but an empty command list does
Re: ed(1) man page doesn't mention use of single / and ?
Hi Jason,
Jason McIntyre wrote on Sun, Jul 07, 2019 at 08:56:43PM +0100:
> this is getting silly - we're mixing talking about how /re/ and ?re?
> work as addresses and as regular expressions in other places. dropping
> the trailing [/?] does not apply to regular expressions everywhere.
Actually, it does, though you are right in so far as the three
cases (addresses, global searches, and replacements) differ in
subtle ways.
> even if i have this wrong (to be fair, not that unlikely), we should
> just concentrate on one thing at a time.
We have now taken care of the case of addresses.
The case of replacements is already described correctly:
> regarding how dropping two delimiters works in an 's' command, although
> i'm not sure really of the reason, you can do:
> 1,$s/re
> which effectively drops /replacement/
Yes, this is described as follows:
If one or two of the last delimiters is omitted, then the last line
affected is printed as though the print suffix p were specified.
Admittedly, the grammar is awkward ("two of things is omitted"),
and it is not said explicitly that omitting both delimiters implies
deleting the re without a replacement - but one could argue that
is implicitly to be expected because omitting the middle delimiter
implies that the replacement can only be empty. If you think this
should be improved, we can polish it later.
So what remains to be decsribed is the case of global searches (gGvV).
Here is what POSIX says about those:
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 , that delimiter can be omitted, in
which case the addressed line shall be written.
Our implementation appears to comply.
While documenting this, also fix a few glitches in the vicinity:
* The wording "the current address is set to the last line affected
by command-list" can easily be misunderstood. The temporal sense
of "last" is intended, but it can easily be read as the last (i.e.
highest numbered) line in the file. So let's better talk about
the "last command executed", not about the "last line".
You can easily see that this is correct with a command like
g/.../+p\
-p
.
which, for each matching line, first prints the following line,
then the matching line itself, and leaves the matching line
(printed by the last command) as the current line, not the
following line, even though the following line was also "affected"
and comes later in the file.
* Avoid the confusing wording "a newline alone in command-list".
The newline is not *in* the command list, but it comes after
the command list, terminating it.
* For G, explicitly say that an empty command list has a different
effect compared to g: for g, it does the same as p, whereas for G,
it does nothing at all.
There is nothing to do for v and V, which mostly point to g and G only.
OK for the patch below?
Yours,
Ingo
Index: ed.1
===
RCS file: /cvs/src/bin/ed/ed.1,v
retrieving revision 1.72
diff -u -p -r1.72 ed.1
--- ed.112 Jul 2019 19:28:48 - 1.72
+++ ed.112 Jul 2019 22:17:47 -
@@ -377,7 +377,7 @@ The current address is set to the line c
command-list is executed.
At the end of the
.Ic g
-command, the current address is set to the last line affected by command-list.
+command, the current address remains as set by the last command executed.
If no lines were matched,
the current line number remains unchanged.
.Pp
@@ -392,22 +392,26 @@ Any commands are allowed, except for
.Ic v ,
and
.Ic V .
-A newline alone in command-list is equivalent to a
+An empty
+.Ar command-list
+is equivalent to a
.Ic p
command.
+In this case, the trailing slash can be omitted.
.Sm off
.It (1,$) Ic G No / Ar re No /
.Sm on
Interactively edits the addressed lines matching a regular expression
.Ar re .
+The trailing slash after
+.Ar re
+can be omitted.
For each matching line, the line is printed, the current address is set,
and the user is prompted to enter a
.Ar command-list .
At the end of the
.Ic G
-command, the current address is set to the last line affected by
-.Pq the last
-command-list.
+command, the current address remains as set by the last command executed.
If no lines were matched,
the current line number remains unchanged.
.Pp
@@ -415,11 +419,10 @@ The format of
.Ar command-list
is the same as that of the
.Ic g
-command.
-A newline alone acts as a null command list.
+command, but an empty command list does nothing.
A single
.Sq &
-repeats the last non-null command list.
+repeats the last non-empty command list.
.It Ic H
Toggles the printing of error explanations.
By default, explanations are not printed.
Re: ed(1) man page doesn't mention use of single / and ?
On Sun, Jul 07, 2019 at 10:12:13PM +0300, cho...@jtan.com wrote: > ropers writes: > > > matthew: "ed reacts differently depending whether or not it's included". > > > can you explain how? > > If I recall correctly, if the trailing delimiter is _not_ included then ed > prints the result of the substitution. Possibly only if interactive. > > > W/r/t Matthew's concerns, I also note that the > > > (.,.)s/re/replacement/ > > section does mention this in its second paragraph: > > >> If one or two of the last delimiters is omitted, then the last line > > >> affected is printed as though the print suffix p were specified. > > I'm not quite sure what is meant by omission of *two* of the last > > delimiters there, but this does at least seem relevant to what we're > > discussing here. > > Yes that sounds about right. Looks like some part of this behaviour is in > documented already. > > The pedantic part of me likes getting this pointless thing right but the > pedantic part of me also wants to make sure it's actually right before > changing something that evidently works already and isn't bothering anybody. > I managed to learn ed with the manpage as it is. > > It sounds like there might be a bit of confusion wrt. what does/doesn't > happen vs. what's documented. Can the various interactions under discussion > be actually clarified and enumerated to be sure we're not changing a minor > mistake for a new mistake? I can do this tomorrow if nobody else jumps in but > I'd get it wrong if I tried it now. > > Matthew > this is getting silly - we're mixing talking about how /re/ and ?re? work as addresses and as regular expressions in other places. dropping the trailing [/?] does not apply to regular expressions everywhere. even if i have this wrong (to be fair, not that unlikely), we should just concentrate on one thing at a time. regarding how dropping two delimiters works in an 's' command, although i'm not sure really of the reason, you can do: 1,$s/re which effectively drops /replacement/ so here's my diff. i think we should keep it short. if there are other cases where things can dropped, i'd rather look at them separately. the question for me is: posix mandates this in address ranges. our ed behaves this way. is there a reason not to document this? jmc Index: ed.1 === RCS file: /cvs/src/bin/ed/ed.1,v retrieving revision 1.70 diff -u -r1.70 ed.1 --- ed.126 Apr 2018 12:18:54 - 1.70 +++ ed.17 Jul 2019 19:56:11 - @@ -267,6 +267,7 @@ .Ar re . The search wraps to the beginning of the buffer and continues down to the current line, if necessary. +The second slash can be omitted if it ends a line. .Qq // repeats the last search. .It Pf ? Ar re ? @@ -274,6 +275,7 @@ .Ar re . The search wraps to the end of the buffer and continues up to the current line, if necessary. +The second question mark can be omitted if it ends a line. .Qq ?? repeats the last search. .It \&' Ns Ar lc
Re: ed(1) man page doesn't mention use of single / and ?
ropers writes: > > matthew: "ed reacts differently depending whether or not it's included". > > can you explain how? If I recall correctly, if the trailing delimiter is _not_ included then ed prints the result of the substitution. Possibly only if interactive. > W/r/t Matthew's concerns, I also note that the > > (.,.)s/re/replacement/ > section does mention this in its second paragraph: > >> If one or two of the last delimiters is omitted, then the last line > >> affected is printed as though the print suffix p were specified. > I'm not quite sure what is meant by omission of *two* of the last > delimiters there, but this does at least seem relevant to what we're > discussing here. Yes that sounds about right. Looks like some part of this behaviour is in documented already. The pedantic part of me likes getting this pointless thing right but the pedantic part of me also wants to make sure it's actually right before changing something that evidently works already and isn't bothering anybody. I managed to learn ed with the manpage as it is. It sounds like there might be a bit of confusion wrt. what does/doesn't happen vs. what's documented. Can the various interactions under discussion be actually clarified and enumerated to be sure we're not changing a minor mistake for a new mistake? I can do this tomorrow if nobody else jumps in but I'd get it wrong if I tried it now. Matthew
Re: ed(1) man page doesn't mention use of single / and ?
On 07/07/2019, ropers wrote: > Second thought, maybe the 'i.e.'s should be changed to 'e.g.'s, > because '/' and '?' also work (instead of '//' and '??', > respectively), so '/re' and '?re' are indeed only examples. > > Or maybe this is overdoing it. I don't know. Whatever you all think is > best and most correct. I have no strong personal opinion on this. I'm > just trying to respond to mazocomp's reasonable observation and > suggestion. Okay, so here's an "e.g." version of the patch, which also removes an extraneous `Ns` that was still present in the earlier, "i.e." version: Index: ed.1 === RCS file: /cvs/src/bin/ed/ed.1,v retrieving revision 1.70 diff -u -r1.70 ed.1 --- ed.126 Apr 2018 12:18:54 - 1.70 +++ ed.17 Jul 2019 13:19:34 - @@ -269,6 +269,9 @@ current line, if necessary. .Qq // repeats the last search. +The second slash is optional for a bare search without any suffixed command, e.g.\& +.Qq / Ns Ar re +is sufficient when followed by a newline. .It Pf ? Ar re ? The previous line containing the regular expression .Ar re . @@ -276,6 +279,9 @@ current line, if necessary. .Qq ?? repeats the last search. +The second question mark is optional for a bare search without any suffixed command, e.g.\& +.Qq ? Ns Ar re +is sufficient when followed by a newline. .It \&' Ns Ar lc The line previously marked by a .Ic k However: *This isn't even my final form*, because it does not take into account Matthew's concerns, which he hasn't clarified yet, perhaps because he's not subscribed to tech@: Thus Spake Chohag-jtan: >> Better to be thorough, if this is to be done. The final slash in a >> substitution is also unnecessary and ed reacts differently depending >> whether or not it's included. I expect it's the same for the other >> commands with delimited options. >> >> Matthew Quoth the Jason: > let's keep this on one mailing list only. since there's a diff, i guess > tech is now fine. > > matthew: "ed reacts differently depending whether or not it's included". > can you explain how? > > jmc Also, it says in the DESCRIPTION in `man 1 ed` that >> (...) commands have the structure: >> [address [,address]]command[parameters] and I guess since /re[/] and ?re[?] are technically addresses, that means that, with bare single addresses being legal and sufficient for search, the command is technically optional too. So would one write that as follows? >> [address [,address]][command[parameters]] Or would it make more sense to add a second, bare address form there? W/r/t Matthew's concerns, I also note that the > (.,.)s/re/replacement/ section does mention this in its second paragraph: >> If one or two of the last delimiters is omitted, then the last line >> affected is printed as though the print suffix p were specified. I'm not quite sure what is meant by omission of *two* of the last delimiters there, but this does at least seem relevant to what we're discussing here. Oh, and Jason, earlier on you recommended NOT to document the second delimiter omission with `g/RE`. Is there a reason why? I appreciate that on its own, `g/RE` may not seem to make too much sense at first sight, but it's actually different from `/RE`, and these are all legal: $ alias ed alias ed='ed -p ed:\ ' $ ed ed.1 20317 ed: H ed: /tuple .Ar n Ns -tuple ed: g/tuple .Ar n Ns -tuple .Ar n Ns -tuple . ed: 200,210g/tuple .Ar n Ns -tuple .Ar n Ns -tuple . ed: 200,205g/tuple .Ar n Ns -tuple ed: g/tuple/n 203 .Ar n Ns -tuple 208 .Ar n Ns -tuple . ed: q $ I've included the /n command form for clarification there. This is my edited ed.1. YMMV w/r/t line numbers. My ed has an `ed: ` prompt because I've aliased ed(1) to that. I would *maybe* even weakly suggest this diff: Index: dot.profile === RCS file: /cvs/src/etc/skel/dot.profile,v retrieving revision 1.5 diff -u -r1.5 dot.profile --- dot.profile 2 Feb 2018 02:29:54 - 1.5 +++ dot.profile 7 Jul 2019 16:17:19 - @@ -4,3 +4,5 @@ PATH=$HOME/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games export PATH HOME TERM + +if (-x /bin/ed) alias ed='ed -p ed:\ ' (NB: Perhaps `alias ed='ed -p ed\>\ '` or `alias ed='ed -p ed\*\ ' would be more acceptable?) This would be a confusion-decreasing convenience for new users, but maybe this is imposing too much of a personal viewpoint; you tell me; I have no strong opinion on this. I do however have a strong opinion on the next thing I've just found: The following diff incorporates three additional changes that fix a documentation bug that could result in actual data loss, or at least that's where it could lead an unwary user: Index: ed.1 === RCS file: /cvs/src/bin/ed/ed.1,v retrieving revision 1.70 diff -u -r1.70 ed.1 --- ed.126 Apr 2018
Re: ed(1) man page doesn't mention use of single / and ?
On Sun, Jul 07, 2019 at 08:07:48AM +0300, cho...@jtan.com wrote: > ropers writes: > > Okay, so since nobody else appears to be making any pertinent noise, I > > guess it falls to me: > > > > Index: ed.1 > > === > > RCS file: /cvs/src/bin/ed/ed.1,v > > retrieving revision 1.70 > > diff -u -r1.70 ed.1 > > --- ed.126 Apr 2018 12:18:54 - 1.70 > > +++ ed.16 Jul 2019 21:20:15 - > > @@ -269,6 +269,9 @@ > > current line, if necessary. > > .Qq // > > repeats the last search. > > +The second slash is optional for a bare search without any suffixed > > command, i.e.\& > > +.Qq / Ns Ar re > > +is sufficient when followed by a newline. > > .It Pf ? Ar re ? > > The previous line containing the regular expression > > .Ar re . > > @@ -276,6 +279,9 @@ > > current line, if necessary. > > .Qq ?? > > repeats the last search. > > +The second question mark is optional for a bare search without any > > suffixed command, i.e.\& > > +.Ns Qq ? Ns Ar re > > +is sufficient when followed by a newline. > > .It \&' Ns Ar lc > > The line previously marked by a > > .Ic k > > > > Questions? Comments? Complaints? Secondary trade sanctions? > > Better to be thorough, if this is to be done. The final slash in a > substitution is also unnecessary and ed reacts differently depending whether > or not it's included. I expect it's the same for the other commands with > delimited options. > > Matthew > let's keep this on one mailing list only. since there's a diff, i guess tech is now fine. matthew: "ed reacts differently depending whether or not it's included". can you explain how? jmc
Re: ed(1) man page doesn't mention use of single / and ?
Second thought, maybe the 'i.e.'s should be changed to 'e.g.'s, because '/' and '?' also work (instead of '//' and '??', respectively), so '/re' and '?re' are indeed only examples. Or maybe this is overdoing it. I don't know. Whatever you all think is best and most correct. I have no strong personal opinion on this. I'm just trying to respond to mazocomp's reasonable observation and suggestion. Ian On 07/07/2019, ropers wrote: > mazocomp opined: >> Hi! >> >> I am not good at explaining something shortly and clearly to fit into >> proper documentation, so I'll just describe my experience here. >> >> Terminating regular expressions with / or ? is necessary only if they >> are followed by commands, otherwise the following are legal in both >> OpenBSD ed, Plan 9 ed and GNU ed: >> /something >> / >> ? >> g/ing >> >> I hope I made life of many ed users easier :) > > >> On Thu, Jul 04, 2019 at 11:47:50PM +0200, ropers wrote: >>> Do I understand correctly that this is in reference to these parts of >>> man >>> 1 ed: >>> >>> > /re/ >>> >The next line containing the regular expression re. The search >>> > wraps >>> > to the beginning of the buffer and continues down to the current line, >>> > if necessary. ???//??? repeats the last search. >>> >>> > ?re? >>> >The previous line containing the regular expression re. The search >>> > wraps to the end of the buffer and continues up to the current line, >>> > if >>> > necessary. repeats the last search. >>> >>> and: >>> >>> > (1,$)g/re/command-list >>> >Applies command-list to each of the addressed lines matching a >>> > regular expression re. The current address is set to the line >>> > currently >>> > matched before command-list is executed. At the end of the g command, >>> > the current address is set to the last line affected by command-list. >>> > If >>> > no lines were matched, the current line number remains unchanged. >>> > >>> >Each command in command-list must be on a separate line, and every >>> > line except for the last must be terminated by a backslash (???\???). >>> > Any commands are allowed, except for g, G, v, and V. A newline alone >>> > in >>> > command-list is equivalent to a p command. >>> >>> >>> If yes, then the corresponding parts of ed.1 are: >>> >>> >>> >>> and: >>> >>> >>> >>> I'm not actually sure how to rewrite that. Would this call for >>> separate /re, ?re and (1,$)g/re entries, or would it suffice to say >>> that the second question mark or slash can be omitted if immediately >>> followed by a newline? >>> >>> Does anyone else have any ideas? >>> >>> NB: In case people haven't seen it, here's an excellent ed(1) >>> tutorial: https://sanctum.geek.nz/arabesque/actually-using-ed/ >>> I just thought I'd mention that. > > > Mohamed proffered: >> To add to Ian's reference. "Ed Mastery" is the only book I know >> specific to ed(1). >> >> Mo > > > Jason McIntyre expounded: >> >> hi. >> >> if we were going to document it, i'd say it definitely wouldn;t warrant >> adding separate entries. it would be enough to describe when the / or ? >> were optional. >> >> neither freebsd nor netbsd seemingly document this. >> >> posix documents it for /re/ and ?re?, but not g/RE/command-list, like >> this: >> >> In addition, the second can be omitted at the end of a >> command line. >> >> without having tested any of this, i guess we'd want to add such a note >> to /re/ and ?re?, but not g/RE/command-list. something along the lines >> of: >> >> The second slash is optional when followed by a newline. >> >> you could ping a diff to tech, and see if anyone has any input that >> could help. if no one does, i'll take it. > > > Okay, so since nobody else appears to be making any pertinent noise, I > guess it falls to me: > > Index: ed.1 > === > RCS file: /cvs/src/bin/ed/ed.1,v > retrieving revision 1.70 > diff -u -r1.70 ed.1 > --- ed.1 26 Apr 2018 12:18:54 - 1.70 > +++ ed.1 6 Jul 2019 21:20:15 - > @@ -269,6 +269,9 @@ > current line, if necessary. > .Qq // > repeats the last search. > +The second slash is optional for a bare search without any suffixed > command, i.e.\& > +.Qq / Ns Ar re > +is sufficient when followed by a newline. > .It Pf ? Ar re ? > The previous line containing the regular expression > .Ar re . > @@ -276,6 +279,9 @@ > current line, if necessary. > .Qq ?? > repeats the last search. > +The second question mark is optional for a bare search without any > suffixed command, i.e.\& > +.Ns Qq ? Ns Ar re > +is sufficient when followed by a newline. > .It \&' Ns Ar lc > The line previously marked by a > .Ic k > > Questions? Comments? Complaints? Secondary trade sanctions? > > And no, don't ask me how much of my weekend I wasted figuring out how > to suppress mandoc's insistence upon two spaces after the 'i.e.' just > because there's a period at the end of a line. Because
Re: ed(1) man page doesn't mention use of single / and ?
mazocomp opined: > Hi! > > I am not good at explaining something shortly and clearly to fit into > proper documentation, so I'll just describe my experience here. > > Terminating regular expressions with / or ? is necessary only if they > are followed by commands, otherwise the following are legal in both > OpenBSD ed, Plan 9 ed and GNU ed: > /something > / > ? > g/ing > > I hope I made life of many ed users easier :) > On Thu, Jul 04, 2019 at 11:47:50PM +0200, ropers wrote: >> Do I understand correctly that this is in reference to these parts of man >> 1 ed: >> >> > /re/ >> >The next line containing the regular expression re. The search wraps >> > to the beginning of the buffer and continues down to the current line, >> > if necessary. ???//??? repeats the last search. >> >> > ?re? >> >The previous line containing the regular expression re. The search >> > wraps to the end of the buffer and continues up to the current line, if >> > necessary. repeats the last search. >> >> and: >> >> > (1,$)g/re/command-list >> >Applies command-list to each of the addressed lines matching a >> > regular expression re. The current address is set to the line currently >> > matched before command-list is executed. At the end of the g command, >> > the current address is set to the last line affected by command-list. If >> > no lines were matched, the current line number remains unchanged. >> > >> >Each command in command-list must be on a separate line, and every >> > line except for the last must be terminated by a backslash (???\???). >> > Any commands are allowed, except for g, G, v, and V. A newline alone in >> > command-list is equivalent to a p command. >> >> >> If yes, then the corresponding parts of ed.1 are: >> >> >> >> and: >> >> >> >> I'm not actually sure how to rewrite that. Would this call for >> separate /re, ?re and (1,$)g/re entries, or would it suffice to say >> that the second question mark or slash can be omitted if immediately >> followed by a newline? >> >> Does anyone else have any ideas? >> >> NB: In case people haven't seen it, here's an excellent ed(1) >> tutorial: https://sanctum.geek.nz/arabesque/actually-using-ed/ >> I just thought I'd mention that. Mohamed proffered: > To add to Ian's reference. "Ed Mastery" is the only book I know > specific to ed(1). > > Mo Jason McIntyre expounded: > > hi. > > if we were going to document it, i'd say it definitely wouldn;t warrant > adding separate entries. it would be enough to describe when the / or ? > were optional. > > neither freebsd nor netbsd seemingly document this. > > posix documents it for /re/ and ?re?, but not g/RE/command-list, like > this: > > In addition, the second can be omitted at the end of a > command line. > > without having tested any of this, i guess we'd want to add such a note > to /re/ and ?re?, but not g/RE/command-list. something along the lines > of: > > The second slash is optional when followed by a newline. > > you could ping a diff to tech, and see if anyone has any input that > could help. if no one does, i'll take it. Okay, so since nobody else appears to be making any pertinent noise, I guess it falls to me: Index: ed.1 === RCS file: /cvs/src/bin/ed/ed.1,v retrieving revision 1.70 diff -u -r1.70 ed.1 --- ed.126 Apr 2018 12:18:54 - 1.70 +++ ed.16 Jul 2019 21:20:15 - @@ -269,6 +269,9 @@ current line, if necessary. .Qq // repeats the last search. +The second slash is optional for a bare search without any suffixed command, i.e.\& +.Qq / Ns Ar re +is sufficient when followed by a newline. .It Pf ? Ar re ? The previous line containing the regular expression .Ar re . @@ -276,6 +279,9 @@ current line, if necessary. .Qq ?? repeats the last search. +The second question mark is optional for a bare search without any suffixed command, i.e.\& +.Ns Qq ? Ns Ar re +is sufficient when followed by a newline. .It \&' Ns Ar lc The line previously marked by a .Ic k Questions? Comments? Complaints? Secondary trade sanctions? And no, don't ask me how much of my weekend I wasted figuring out how to suppress mandoc's insistence upon two spaces after the 'i.e.' just because there's a period at the end of a line. Because
