From: Alan Watson <alan@oldp.astro.wisc.edu>
To: sam-fans@hawkwind.utcs.toronto.edu
Subject: Lines and last lines.
Date: Mon, 30 Nov 1992 19:40:45 -0500 [thread overview]
Message-ID: <9212010040.AA14736@oldp.astro.wisc.edu> (raw)
I'm struggling with sam's supposed break from the line-oriented nature
of most Unix utilities.
Relevant parts of the man page are [1]
\n Match newline.
^ Match the null string immediately after a newline.
$ Match the null string immediately before a newline.
and later [2]
(The peculiar properties of a last line without a newline are tem-
porarily undefined.)
and later still [3]
x/regexp/ command
For each match of the regular expression in the range, run the com-
mand with dot set to the match. Set dot to the last match. If the
regular expression and its slashes are omitted, /.*\n/ is assumed.
Null string matches potentially occur before every character of the
range and at the end of the range.
My first comment is that [2] is somewhat against sam's philosophy that
files are arbitrary byte streams; it does impose a structure on the
file (i.e., that the final character must be \n).
Secondly, let's investigate the interactions of [2] and [3]:
; sam -d
a/abcd\n/
a/efgh\n/
a/ijkl/
,p
abcd
efgh
ijkl <- cursor here
,x/.*\n/p
abcd
efgh
<- cursor here
,x p
abcd
efgh
ijkl <- cursor here
These last two might be expected to give the same output, given the
stated default for x.
Finally, lets investigate the interaction of [1] and [2]:
,x /^.*/p
efghijklabcd <- cursor here
,x /.*$/p
efghabcdabcd <- cursor here
Okay, my point is that it might have been better to define different
semantics for ^ and $, namely that they match the start of a line
(i.e., the null string at the start of the file and the null string
after a \n not at the end of the file) and the end of a line (i.e.,
the null string before a \n not at the end of the file and the null
string at the end of the file).
The default for x might then have been /^.*$/, and this might have
helped to define the semantics of a final line without a newline.
next reply other threads:[~1992-12-01 3:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
1992-12-01 0:40 Alan Watson [this message]
1992-12-01 5:46 ` Chris Siebenmann
1992-12-01 5:08 Byron Rakitzis
1992-12-01 7:01 Alan Watson
1992-12-01 7:11 Michael John Haertel
1992-12-01 7:57 Byron Rakitzis
1992-12-01 19:27 Alan Watson
1992-12-01 19:54 Byron Rakitzis
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9212010040.AA14736@oldp.astro.wisc.edu \
--to=alan@oldp.astro.wisc.edu \
--cc=sam-fans@hawkwind.utcs.toronto.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).