🚀 go-pugleaf

In article <1990Nov5.040638.6580@agate.berkeley.edu> pete@violet.berkeley.edu (Pete Goodeve) writes:
> and the choice of '.' as [a UNIX shell metacharacter] is a real pain!.

Huh? "." isn't a UNIX shell metacharacter. What are you talking about?

> In the shell?  [...Now this is another well trodden path, isn't it?]
> We definitely take different forks here.  The big problem is that you have
> NO guarantee that a command line argument refers to a file -- not even
> if it's a pattern.

On the other hand, if it's not in the shell you have no idea if a given program
handles patterns or if it uses the standard ones. This is a problem in every
operating system that I've used except for UNIX.

> In particular, Mat uses patterns to scan the contents
> of TEXT files (though it does things with filenames too); the "slices" I
> was talking about are used for rearrangement of the matched lines for
> output.

Like \1, \2, \3 and so on in "ed" style regular expressions? What's wrong
with using backslash for that... it doesn't conflict with UNIX anything.

(and I have no problem quoting my "sed" arguments)

(speaking of which, how does MAT differ functionally from sed?)

> What I've wanted -- and we now are getting with 2.0 -- are standard calls
> to the kernel functions that it make it painless for a program to do things
> like (standard) pattern matching itself.

And Commodore themselves don't use them for all programs:

1.Ram Disk:> list foo
Directory "Ram Disk:" on Monday 05-Nov-90
foo                           26 -s--rwed Today     06:15:58
1 file - 2 blocks used
1.Ram Disk:> execute fo#?
EXECUTE: Can't open fo#?

me> [what about ->]

> This I like!  It's certainly suitably "iconic".  (On the other hand it's
> not quite as convenient to type as my '><' suggestion.)  Or you might even
> combine it with Eduardo Horvath's suggestion and make it '=>'.

Which is no easier to type, but does stand out more.

> > 1> pipe list lformat="%s" +
> > cpio -ocv >rdf:df0

> Also not a bad possibility, though once again it has the problem of keeping
> multi-line commands conveniently in a history list.

On the other hand it could be implemented to work in the existing AmigaShell
and CLI.

> In fact the BCPL convention went further than this: the argument part of
> the command line was simply left in the input stream for the program to
> read;

A nice idea but conflicts with redirection. ISIS did the same thing on the
old Intel development systems (ISIS is what originally inspired CP/M, by
the way... what goes around comes around). I've often thought that arguments
should be an input stream, read from a new file descriptor "stdcmd". So you
could write your program as:

	while(getword(stdcmd, buffer)) {
		do_something_with buffer;
	}

So if you opened a pipe to stdcmd...

> All the suggestions we've been tossing back and forth mean more massaging
> on the command line, and just MAY have unexpected consequences.

Which is an advantage for the "pipe command+\ncommand+\ncommand" syntax.

> 'Course on the
> other hand, I guess there's no reason why we can't just start afresh...)

One of these days I've gotta start using SKSH. Maybe when there's a 2.0
version that doesn't use arp.library.
-- 
Peter da Silva.   `-_-'
<peter@sugar.hackercorp.com>.