The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: markus schnalke <>
Subject: [TUHS] Re: ed: multiple addresses (with semicolons)
Date: Fri, 08 Jul 2022 10:09:47 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


now I did find nroff sources to the manpages of earlier editions
-- still learning about the organization of the code on the TUHS

Already in the 1st Edition the ed(1) manpage writes:

	Commands may require zero, one, or two addresses.  Commands
	which require no addresses regard the presence of an
	address as an error. Commands which require the presence of
	one address all assume a default address (often ".") but if
	given more than one address ignore any extras and use the
	last given. Commands which require two addresses have
	defaults in the case of zero or one address but use the
	last two if more than two are given.

Hence this features was already present from the beginning. My
question must thus shift to QED: Was it present there as well or
was it newly introduced to ed? As it is not listed as a
differences to QED, it seems to have been taken from there

My interest in general use cases and stories around the feature
is still present. ;-)


[2022-07-08 09:47] markus schnalke <>
> Hoi,
> via a recent message from Chris Pinnock to the list I became aware
> of the book ``Ed Mastery'' by Michael W. Lucas. At once I bought
> and read it. Although it is not on the mastery level it claims and
> I would have liked it to be, it still was fun to read.
> This brought me back to my ed interest. I like ed a lot and despite
> my young age, I've actually programmed with ed for fun and have
> prepared the troff slides for a talk on early Unix tools (like ed)
> with ed alone. I use the Heirloom version of ed.
> Anyways, I wondered about the possibility to give multiple
> addresses ... more than two for relative address searches.
> For example, to print the context of the first occurance of `argv'
> within the main function, you can use:
> 	/^main(/;/\<argv\>/-2;+4n 
> For the last occurance it's even one level more:
> 	/^main(/;/^}/;?\<argv\>?-2;+4n
> (The semicolons mean that the next search or relative addressing
> starts at the result of the previous one. I.e. in this case: We go
> to the `main' function, from there go to the function end, then
> backwards to `argv' minus two lines and print (with line numbers)
> this line and four lines more.)
> The manpage of 6th Edition mentiones this possibility to give more
> than two addresses:
> 	Commands may require zero, one, or two addresses.  Commands
> 	which require no addresses regard the presence of an address
> 	as an error.  Commands which accept one or two addresses
> 	assume default addresses when insufficient are given.  If
> 	more addresses are given than such a command requires, the
> 	last one or two (depending on what is accepted) are used.
> You can see it in the sources as well:
> (Search for  ';'  to find the line. There's a loop processing the
> addresses.)
> V5 ed(1) is in assembler, however, which I cannot read. Thus there
> must have been a complete rewrite, maybe introducing this feature
> at that point. (I don't know where to find v5 manpage to check
> that as well.)
> I wonder how using multiple addresses for setting starting points
> for relative searches came to be. When was it implemented and what
> use cases drove this features back in the days? Or was it more an
> accident that was introduced by the implementation, which turned
> out to be useful? Or maybe it existed already in earlier versions
> of ed, althoug maybe undocumented.
> For reference, POSIX writes:
> 	Commands accept zero, one, or two addresses. If more than the
> 	required number of addresses are provided to a command that
> 	requires zero addresses, it shall be an error. Otherwise, if more
> 	than the required number of addresses are provided to a command,
> 	the addresses specified first shall be evaluated and then discarded
> 	until the maximum number of valid addresses remain, for the
> 	specified command.
> Here more explanation rom the rationale section:
> 	Any number of addresses can be provided to commands taking
> 	addresses; for example, "1,2,3,4,5p" prints lines 4 and 5, because
> 	two is the greatest valid number of addresses accepted by the print
> 	command. This, in combination with the <semicolon> delimiter,
> 	permits users to create commands based on ordered patterns in the
> 	file. For example, the command "3;/foo/;+2p" will display the first
> 	line after line 3 that contains the pattern foo, plus the next two
> 	lines. Note that the address "3;" must still be evaluated before
> 	being discarded, because the search origin for the "/foo/" command
> 	depends on this.
> As far as I can see, multiple addresses make only sense with the
> semicolon separator, because the comma separator does not change
> the state, thus previous addresses can have no effect on later
> addresses. The implementation just does not forbid them, for
> simplicity reasons.
> meillo

  reply	other threads:[~2022-07-08  8:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08  7:47 [TUHS] " markus schnalke
2022-07-08  8:09 ` markus schnalke [this message]
2022-07-08 13:23 Douglas McIlroy
2022-07-08 16:01 ` [TUHS] " Ken Thompson
2022-07-08 19:13   ` markus schnalke
2022-07-09  8:10     ` steve jenkin
2022-07-09  8:22       ` Rob Pike
2022-07-10  3:50         ` Jon Forrest
2022-07-10  9:25 ` Angelo Papenhoff
2022-07-10  9:59   ` Ralph Corderoy
2022-07-08 21:36 Douglas McIlroy
2022-07-11 14:40 ` markus schnalke
2022-07-11 17:30 Douglas McIlroy
2022-07-18 10:52 ` markus schnalke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).