🚀 go-pugleaf

In  <6977@sugar.hackercorp.com> (3 Nov),
Peter da Silva (peter@sugar.hackercorp.com) writes:
>
> The version 6 shell and the version 7 (bourne) shell use either '|' or '^'
> as a pipe character. I understand that at least one Amiga shell requires
> pipes to have white-space around them. The use of '^' might be a better
> alternative, even if it will break c-shell history (which is something
> I want, weird though that might sound to some of you).

I would whimper rather a lot over that choice!  I chose '^' to extend the
pattern matching convention (in Mat), where it indicates a "slice" in the
pattern (and I use it similarly in templates for rearranging the slices).

Actually I sort of fear that ANY character co-opted for a pipe separator
would screw up somebody.  Maybe we'll have to take some other route (Heh..!).

I'm not sure that requiring spaces around the character would be adequate
either -- I often have spaces in my patterns, and it would be quite
possible for them to be adjacent to the '|'.  Of course spaces are always
enclosed in quotes, so maybe there'd be no conflict.


In  <8450@pasteur.Berkeley.EDU> (3 Nov),
David C. Navas (navas@cory.Berkeley.EDU) writes:
>
> Well, I haven't really used ADos pattern matching much -- my only real example
> was taken from an incorrect example provided in my 2.0? Workbench which
> tended to crash my machine every so often :)

I use it a heck of a lot -- mainly for things like:

            copy this_one|that_one|the_other to df0:

> However, wouldn't such uses usually be enclosed in parenthesis?  ala foo.(h|c)

Not necessarily -- see above!
>
>  [.....]                   Having another non-standard symbol would push
> the readability of this news group way down (due to tonnage of abusive flames).

This is true...

> While we're at it, why not make those ">" and "<" placable anywhere on the
> command line?  [IE.  figure out how "run" would redirect output correctly...]

Yurr.  Is there anything in the current CLI/Shell syntax that really
prohibits this?  At one time I had myself convinced that there was, mainly
because you could (in theory) do something like:

        run >somewhere myprog >somewhere_else

Can't say that I've ever found much need for such a construction though
(except for suppressing the "[CLI n]" message with "run >NIL: myprog").
I'd think that any piping shell would call RUN implicitly anyhow, so we're
probably free to do what we like.


In  <890@public.BTR.COM> (3 Nov),
Eduardo E. Horvath (eeh@public.BTR.COM) writes:
>
>       What about "=" ?  It even looks alot more lile a pipe than "|".  I think
> that the only place "=" will cause problems would be when using something like
> set or in scripts where you are doing comparisons.  [.....]
>
I guess the arguments against this are about the same as for '|' and '^'.
It would be hard to be cerain you weren't breaking anything.

Maybe it's time for my own suggestions.
[Uh... just a moment... Darn, this flameproof material is uncomfortable...!]

I'm wondering if we shouldn't broaden possibilities a little.
I'm not sure for example if we should fixate on single line, multi-process,
commands. Supposing we keep to a single command per line as it is now, but
PREFIX the command with some special character?  In this position you
could use almost anything.  Oh, I dunno, how about this sort of thing?:

    <list #?.(c|h)
    <myformatter
    myprinter

This looks perfectly feasible within scripts, but it might be a nuisance
when typing things at the console.  History would be a pain for example.

Alternatively, maybe instead of a single separator character we could
use a unique pair, e.g.:

        list #?.(c|h) >< myformatter ><myprinter

(trailing space optional, leading one required)  I figure that that
particular pair has such a relation to current redirection syntax that it
wouldn't interfere with anything else (except that .BRA & .KET would
probably then be essential!).

[Oof -- time to take the suit off again.]

                                        -- Pete --