From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from netcomsv.netcom.com ([192.100.81.101]) by hawkwind.utcs.toronto.edu with SMTP id <2845>; Tue, 1 Dec 1992 14:57:16 -0500
Received: from netapp.UUCP by netcomsv.netcom.com with UUCP (4.1/SMI-4.1)
	id AA05683; Tue, 1 Dec 92 11:52:57 PST
Received: from ghoti.netapp by netapp.netapp.com (4.1/SMI-4.1)
	id AA03668; Tue, 1 Dec 92 11:54:39 PST
Date:	Tue, 1 Dec 1992 14:54:39 -0500
From:	byron@netapp.com (Byron Rakitzis)
Message-Id: <9212011954.AA03668@netapp.netapp.com>
To:	alan@oldp.astro.wisc.edu, sam-fans@hawkwind.utcs.toronto.edu
Subject: Re: Lines and last lines.

The treatment of whitespace in the sam lexical analyzer is
very idiosynchratic.

Here are the features:

	B<space>

means "open a new file".

	x<space>

is the RE hack we talked about. This applies to y, X and Y as
well. Also it means that either an RE or a space is *required*
between "x" and any other command. This is why I think the
comment in the man page about omitting the RE reads so poorly.

BTW,

	x<nl>

also works, and seems to be equivalent to

	x/(\n|.)*/p


Here are some more dubious features:

	f<space>

sets the current filename to null.

	w<space>

prints

	?no file name

which is consistent with "f<space>" setting the filename to
null, at least.

Otherwise, whitespace *seems* to be optional. Did I cover all
the cases?

BTW, reading and writing an octal dump a binary editor does not
make. I can do exactly the same with vi (the editor that the
labs people detest), including the bit about piping the whole
file through an octal dumper & undumper.