Path: utzoo!utgpu!watserv1!watmath!att!att!pacbell.com!mips!apple!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu (Pete Goodeve)
Newsgroups: comp.sys.amiga.tech
Subject: Re: PIPEs
Message-ID: <1990Nov5.040638.6580@agate.berkeley.edu>
Date: 5 Nov 90 04:06:38 GMT
References: <6977@sugar.hackercorp.com> <1990Nov4.054222.24999@agate.berkeley.edu> <6984@sugar.hackercorp.com>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: University of California, Berkeley
Lines: 101


In  <1990Nov4.150403.28982@cbnewsc.att.com> (4 Nov),
gregg.g.wonderly (gregg@cbnewsc.att.com) writes:
>
> I find the UN*X shells' quoting conventions to be quite adequate at
> avoiding the need to require a SPACE anywhere.  If you want something which
> contains meta characters to become part of a parameter-word, you quote it.
> That makes it pretty simple to put together whatever you need.
> [......]
> Of course the biggest part of this is educating people which characters
> are special meta-characters which the shell will treat in a special way.
> [.....]

I incline somewhat on the opposite tack.  The UN*X shell syntax is
elegant in the abstract, but I've found it is one of the things that
contributes to the reputation for unfriendliness.  The plethora of
metacharacters is one of the problems (and the choice of '.' as one
of them is a real pain!).

Conversely, the use of a space is natural to most people -- and the space
bar is the easiest stroke on a keyboard!


In  <6984@sugar.hackercorp.com> (4 Nov),
Peter da Silva (peter@sugar.hackercorp.com) writes:
>
> I'm unhappy with "extensions" to the pattern matching convention, particularly
> since I think it should be done in the shell (well, I can dream).

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.   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.

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.

> How about making a second-order jump:
>
>       ^. in pascal becomes -> in C, so:
>
> 1> list lformat="%s" -> cpio -ocv > rdf:df0
>
> So "->" is "redirect to program".
>
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 '=>'.  Or, not
quite so mnemonic, but easier to parse (only one metachar to worry about),
"redirect to program" could be ">=".


> Or how about making a new command that uses the "+" syntax like in run?
>
> 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.  (Which, BTW, is a
general difficulty that would be nice to have a cute solution to.  Somehow
you ought to be able to "group" commands -- without having to create a
script -- so that they can be backed up to and re-executed as that group.)


In  <6985@sugar.hackercorp.com> (4 Nov):
>
> Well, I can imagine a pattern matching "nothing or a subdirectory". [...]

Yeah -- no problem here, because "nothing" in a pattern is '%'.


I think that hidden behind all this discussion is a big difference in
philosophy between UN*X and AmigaDOS (well, Tripos).  The C-shell and
so on sort of assume by default that arguments are probably filenames,
so things like globbing get done automatically unless you specifically
tell it otherwise.  On the other hand AmigaDOS essentially believes that
the argument string is only the concern of the program receiving it,
and passes it on (almost) unchanged.

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; if it wanted it could keep ON reading that stream to get more
arguments -- this is how the '+' mechanism works (or did prior to 2.0 --
dunno if it does still).  In practice it's not quite like that, with removal
of comments, quoted strings, redirection, and so on,  All in all, though,
the command line still gets passed on in fairly pure form to its
destination.

All the suggestions we've been tossing back and forth mean more massaging
on the command line, and just MAY have unexpected consequences. As John
Campbell said, "You can't do just one thing"!  Even obvious sounding things
like permitting redirection anywhere on the line mean a change in
assumptions, and have to be considered VERY carefully.  ('Course on the
other hand, I guess there's no reason why we can't just start afresh...)

                                        -- Pete --