Re: [9fans] sam command language

Re: [9fans] sam command language

[Dennis Ritchie]

 > My first experience of Unix (circa 1976) was on an uppercase-only
 > terminal.  The driver would display lowercase characters as
 > uppercase, and uppercase characters escaped with a backslash;
 >keyboard input was the inverse of this.  So it was a common
 >mistake to type something like this in a C program
 > 	PRINTF("\HELLO, WORLD\N"):
 > which would result in "Hello, worldN" and no newline.

 > Exercise for the reader: how many backslashes are required
 > in the ed 's' command to correct the error?

Years ago I ran into a situation with a script
(probably involving all of the shell, ed, and troff)
in which N½ \ were needed.  N was too few, N+1 were
too many.

	Dennis

Re: [9fans] sam command language

[rog]

> you're in a vale of tears these days, aren't you?

story of my life :-)

or should that be :-( ?

actually they're just things that've niggled for years but without
enough incentive to mention them or change them...

my vale of tears at the moment is more to do with the fact that some
9fans messages are taking days and days to get through (i still
haven't seen the original "some of you guys..."  post yet, for
example, or my original post in this thread).

if it's happening for 9fans, god knows how much other
stuff has been lost in the pipeline. unreliable email is a frustrating thing.

Re: [9fans] sam command language

[rog]

> Exercise for the reader: how many backslashes are required
> in the ed 's' command to correct the error?

erm, 5? (or 6, depending on the pattern used)

Re: [9fans] sam command language

[Richard Miller]

> I also forgot about the terminal driver, which in some
> incarnations defaulted to \ as an escape character,

My first experience of Unix (circa 1976) was on an uppercase-only
terminal.  The driver would display lowercase characters as
uppercase, and uppercase characters escaped with a backslash;
keyboard input was the inverse of this.  So it was a common
mistake to type something like this in a C program
	PRINTF("\HELLO, WORLD\N"):
which would result in "Hello, worldN" and no newline.

Exercise for the reader: how many backslashes are required
in the ed 's' command to correct the error?

Re: [9fans] sam command language

[Douglas A. Gwyn]

rob pike, esq. wrote:
> Back to troff: in qed, \ was linear.  You added a
> backslash to quote something.  In a macro, you
> added two backslashes.  In a macro calling a
> macro you added three, etc.   Instead of 2^N,
> you needed N.

I also forgot about the terminal driver, which in some
incarnations defaulted to \ as an escape character,
necessitating typing \\ to enter each one of those \s.
As I recall, Software Tools used @ for all its escape
characters.  Experience seems to suggest that using
the same character as escape at multiple nested levels
of processing is not a good idea ("sucks" is the
technical term).
Followup-To:
Distribution:
Organization: University of Bath Computing Services, UK
Keywords:
Cc:


--
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
D.H.Davis@bath.ac.uk

Re: [9fans] sam command language

[okamoto]

> Actually they're not. Orthogonal means they are not related or dependent.
> Cleary 'was' is related to 'is' when applied the thing what has the state
> 'clean'.

I know what is the difference between boyd and jchoate, that is intelligence.
Both are sometimes/many times? noisy, but boyd has great intelligence.

Kenji

Re: [9fans] sam command language

[rob pike, esq.]

> while on the subject of undo/redo, would it be terrible to have a
> "Redoall" command? as when clicking repetitively on "Redo" i
> invariably click one too many times (whereupon the "Redo" has replaced
> itself by "Put") and write the file unintentionally, sometimes with
> annoying results.

you're in a vale of tears these days, aren't you?

try
	u100
or some such.

Re: [9fans] sam command language

[rob pike, esq.]

> rob pike, esq. wrote:
>> ... The double meaning of \ in Unix and especially
>> Perl REs is regrettable at best.
>
> And especially in troff macro diversions.  I recall
> seeing \\\\\\\\ on more than one occasion.

That wasn't the double meaning I was referring to,
but yes.  I meant that \w makes w special but that
\* makes * not special.

Back to troff: in qed, \ was linear.  You added a
backslash to quote something.  In a macro, you
added two backslashes.  In a macro calling a
macro you added three, etc.   Instead of 2^N,
you needed N.

-rob

Re: [9fans] sam command language

[Dan Cross]

Derek Fawcus <dfawcus@cisco.com> writes:
> So which (natural,  I assume) language uses those as quote characters?

Russian.

	- Dan C.

Re: [9fans] sam command language

[Jim Choate]

On Wed, 8 Oct 2003 rog@vitanuova.com wrote:

> hmm.  "was clean" is quite different from "is clean".  (both are
> useful, but they're orthogonal to one another).

Actually they're not. Orthogonal means they are not related or dependent.
Cleary 'was' is related to 'is' when applied the thing what has the state
'clean'.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] sam command language

[Derek Fawcus]

On Wed, Oct 08, 2003 at 03:33:22PM +0100, rog@vitanuova.com wrote:
> it's not like « and » are common characters to search for.

Well I seem to recall that they are in the sam source so that one can do the
click-inside-quote and have the selection cover the whole quote.

So which (natural,  I assume) language uses those as quote characters?

DF

Re: [9fans] sam command language

[rog]

> feature.  otherwise you couldn't undo to the point it was clean.

hmm.  "was clean" is quite different from "is clean".  (both are
useful, but they're orthogonal to one another).

perhaps the 'f' line could indicate both (e.g.  with an extra
space/backquote to indicate "is clean").

while on the subject of undo/redo, would it be terrible to have a
"Redoall" command? as when clicking repetitively on "Redo" i
invariably click one too many times (whereupon the "Redo" has replaced
itself by "Put") and write the file unintentionally, sometimes with
annoying results.

Re: [9fans] sam command language

[rog]

> just what we need -- more characters to escape in regular expressions.
> if you're going to change anything, it makes more sense to sully ^ and $
> even further.

s'pose so.  seems a pity.  it seems to work quite nicely now i've
implemented it.  it's not like « and » are common characters to search
for.

one could double them, i guess: ^^ and $$.

Re: [9fans] sam command language

[Douglas A. Gwyn]

rob pike, esq. wrote:
> ... The double meaning of \ in Unix and especially
> Perl REs is regrettable at best.

And especially in troff macro diversions.  I recall
seeing \\\\\\\\ on more than one occasion.

Re: [9fans] sam command language

[vdharani]

> i wouldn't modify the meaning of ^ and $, rooted as they are in
> antiquity.  one could always take a brave leap into the almost
> unsullied waters of Unicode...
>
> for instance, one could use « (unicode 0xab) and » (unicode 0xbb) to
> indicate a regex anchored to the start or end of "dot".
>
before taking a brave leap, i think we need to make sure the concept will
work on all environments. Can we enter unicode characters easily in Plan 9,
Inferno, and Sam for Windows and any other ports with Plan9/Inferno origin
(like Inferno IE plugin) using a single method and without any problem? If
not, I suggest we try something else (Is it possible to use multiple
characters instead?). It becomes easier for users to remember a single
style.

Thanks
dharani

Re: [9fans] sam command language

[rob pike, esq.]

> Alternatively, do what perl does:  punctuation uses backslash
> to turn the magic off, letters use punctuation to turn it on.
> So \a and \z could be the end markers.  You'd seldom type
> that, so they're free to use.

This breaks the rules we worked so hard to establish in Plan
9 regular expressions: \ is used only to make something
unmagic.  The double meaning of \ in Unix and especially
Perl REs is regrettable at best.

-rob

Re: [9fans] sam command language

[Scott Schwartz]

| just what we need -- more characters to escape in regular expressions.
| if you're going to change anything, it makes more sense to sully ^ and $
| even further.

Alternatively, do what perl does:  punctuation uses backslash
to turn the magic off, letters use punctuation to turn it on.
So \a and \z could be the end markers.  You'd seldom type
that, so they're free to use.

Re: [9fans] sam command language

[Russ Cox]

just what we need -- more characters to escape in regular expressions.
if you're going to change anything, it makes more sense to sully ^ and $
even further.

Re: [9fans] sam command language

[rob pike, esq.]

>> and then, in the end, i felt the need for the modified version of ^
>> and $ so rarely that i don't really mind not having them.
>
> for me, it's been frequent enough to feel a little frustrated by it
> (particularly when dealing non-line-oriented files).
>
> i wouldn't modify the meaning of ^ and $, rooted as they are in
> antiquity.  one could always take a brave leap into the almost
> unsullied waters of Unicode...

the waters of special characters for regex hacking are muddy
enough already.   i've been in them before and i'm nice and
clean now.  no, thanks.

> BTW while on minor sam/acme gripes, is it a bug or a feature that if a
> file is written, changed, and the change undone, the file is not
> marked as changed?  this means that X/'/w is not guaranteed to write
> out all files that have been modified from their on-disk copies, and
> has bitten me more than once (i don't use that idiom any more!)

feature.  otherwise you couldn't undo to the point it was clean.

ever do this? (probably not)
	X/'/u
send that until nothing happens and you've backed up to the last
clean instance. you can even snarf and send a bunch of them:

	X/'/u
	X/'/u
	X/'/u
	X/'/u
	X/'/u
	X/'/u
	X/'/u
	...

weird, but it works.  (to do a particular file, put more detail in the
pattern.)

-rob

Re: [9fans] sam command language

[rog]

> and then, in the end, i felt the need for the modified version of ^
> and $ so rarely that i don't really mind not having them.

for me, it's been frequent enough to feel a little frustrated by it
(particularly when dealing non-line-oriented files).

i wouldn't modify the meaning of ^ and $, rooted as they are in
antiquity.  one could always take a brave leap into the almost
unsullied waters of Unicode...

for instance, one could use « (unicode 0xab) and » (unicode 0xbb) to
indicate a regex anchored to the start or end of "dot".

e.g.

,x/[a-zA-Z0-9]+/g/«A/d

would delete all alphanumeric sequences starting with
the letter 'A'; or

,y/[ \t\n]/y/«./g/./|tr 'A-Z' 'a-z'

would lowercase all but the first letter of all words.  (aside: has
anyone found a good use for the fact that "y" selects null ranges?)

or

,x/^\.TS/.,/^\.TE/y/«...\n/y/...»/x/.*\n»/g/pattern/d

would delete the last line of a tbl table if it contained "pattern".

it seems useful and quite natural to use (and the implementation looks
trivial, in acme at any rate).

BTW while on minor sam/acme gripes, is it a bug or a feature that if a
file is written, changed, and the change undone, the file is not
marked as changed?  this means that X/'/w is not guaranteed to write
out all files that have been modified from their on-disk copies, and
has bitten me more than once (i don't use that idiom any more!)

Re: [9fans] sam command language

[Axel Belinfante]

> The only thing that bugs me is that sed isn't ssam,
> I know about sam -d but it doesn't stream.

There is a unix ssam (streaming sam)
 http://www.westley.demon.co.uk/software.html

Re: [9fans] sam command language

[steve.simon]

    i think it worked out well.

One day I must make a serious effort to learn acme
but I feel no pressure to as sam is so wonderfull.

The only thing that bugs me is that sed isn't ssam,
I know about sam -d but it doesn't stream.

-Steve

Re: [9fans] sam command language

[boyd]

    i think it worked out well.

so do i.  i've used it for some 12 years now and it only ever screws
up when i do (but i have undo) or /tmp fills up.  once you master 'x'
it's a seriously powerful tool, without all that crap you find in things
like emacs.

Re: [9fans] sam command language

[Micah Stetson]

> by someone accustomed to ed.  i think it worked out well.

I agree.  Sam is a triumph.  I didn't mean to sound like
I was complaining.  Thanks for a tool I use almost every
day and thank God for often.

Micah

Re: [9fans] sam command language

[Rob Pike]

consistency with ed's regexes was paramount when sam was written.
it may be less so now.  i was trying to build an editor that treated the
whole file as one string yet didn't offer too many surprises when used
by someone accustomed to ed.  i think it worked out well.

-rob

Re: [9fans] sam command language

[Micah Stetson]

> lines, unlike ed.  if the whole file is just one long string, which is
> exactly
> how sam works, shouldn't ^ and $ then mean beginning of file and end
> of file?  that's not very useful.

I would tend to expect that they meant beginning and end
of selection.  Then if you want to match at the beginnings
and ends of lines, it's just ',x /^...$/', and beginning
and end of file is ',/^...$/'.  I suppose that has its
disadvantages, too, like ',x /$/i/foo/' would put foo at
the beginning of every line but the first, it's logical,
but it's a little unexpected.  Having to match '\n' when
you wanted it, wouldn't be that bad, though.

Micah

Re: [9fans] sam command language

[Jim Choate]

On Mon, 6 Oct 2003, Rob Pike wrote:

> long ago, i considered making ^ and $ mean this in sam.  they clearly
> need to mean beginning and end of line at the top level, but when we
> x down, maybe they should mean beginning and end of the substring.

> that ^ and $ meaning bol and eol at the top level meant that they
> required

> special handling already, since sam really doesn't know much about
> lines, unlike ed.  if the whole file is just one long string, which is
> exactly
> how sam works, shouldn't ^ and $ then mean beginning of file and end
> of file?  that's not very useful.

Isn't a line just a substring of a file. The extension  of ^ and $ from
line to sub-string is natural. Confusing it with files isn't.

 -- --

God exists because mathematics is consistent, and the Devil exist because we
can't prove it.
                          Andre Weil, in H. Eves, Mathematical Circles Adieu

      ravage@ssz.com                            jchoate@open-forge.com
      www.ssz.com                               www.open-forge.com

Re: [9fans] sam command language

[Rob Pike]

> for instance, suppose i've got a little sam expression that nicely
> isolates particular subregions of text.  i can't work out a way to
> match only characters which appear at the very beginning (or end) of
> "dot".  kind of similar to ^ and $ except with respect to the
> boundaries of the current selection.

long ago, i considered making ^ and $ mean this in sam.  they clearly
need to mean beginning and end of line at the top level, but when we
x down, maybe they should mean beginning and end of the substring.
i think i even tried to implement it.  in any case, i decided against
it; i
think it was a combination of not liking the shift in meaning and the
fact
that ^ and $ meaning bol and eol at the top level meant that they
required
special handling already, since sam really doesn't know much about
lines, unlike ed.  if the whole file is just one long string, which is
exactly
how sam works, shouldn't ^ and $ then mean beginning of file and end
of file?  that's not very useful.

and then, in the end, i felt the need for the modified version of ^ and
$
so rarely that i don't really mind not having them. unlike in the modern
world, back then adding a feature was considered something to consider
carefully, rather than just adding it in case someone might conceivably
want it one day.

-rob

[9fans] sam command language

[rog]

> > (there are a couple of annoying little things i still haven't
> > worked out a good way of doing though)
>
> if they're annoying, don't do them.

they're annoying *because* i can't do them!

for instance, suppose i've got a little sam expression that nicely
isolates particular subregions of text.  i can't work out a way to
match only characters which appear at the very beginning (or end) of
"dot".  kind of similar to ^ and $ except with respect to the
boundaries of the current selection.

e.g.  here's an expression that matches mbox entries in an acme Mail
window (tab replaced by \t):

	,x/.+\n(\t.+\n)*/y/^\(deleted\)-/g/./

it would be useful to be able to guard by message number on the
resulting message lines (without worrying about the contents of the
subject line).