🚀 go-pugleaf

In  <1990Nov18.141954.15308@zorch.SF-Bay.ORG> (18 Nov),
Kent Paul Dolan (xanthian@zorch.SF-Bay.ORG) writes:
> pete@violet.berkeley.edu (Pete Goodeve) writes:
> [heavily edited]
>
|>  [As others have noted, this thread is now worn thin, but one more time
|>  for those who don't yet have it in their kill file...]
>
> Not to worry, this is a tough problem, being attacked in a tech group
> where tough problems are the meat and potatos.

My remark was prompted, I guess, by finding a couple of folks at BADGE
last week who had the topic in their kill files.  Sorry you weren't there:
we could have used the blackboard for some of this...! (:-))

> [.....]
|>                    [unix-style pipes] -- unlike files, temp or
|>  otherwise -- are unnamed; you can run several copies of a script
|>  at once, without them interfering with each other.
>
> Well, be a bit careful here. In my proposal, and your amendment of it,
> the pipes were named by the numbers assigned to the output end of each
> pipe. From the command line, this would name the pipes. If the command
> were backgrounded and another piping command typed, there would be
> interference (or interaction, depending whether the results were
> desired).

Yeah, well there are names and names...  I should have made the distinction
that file names are GLOBAL in the system; whatever names we use to
distinguish pipes within a command group are local to that group.  I was
simply assuming that your next statement (or something similar) would be
the case:
>            Given our proposal functioning, it would probably be best if
> the pipe names were silently prefixed with the current process ID.
> [.......]
>
> This gives away the benefit of the AmigaOS named pipes that can hand data
> from one CLI window to another. though.  Nothing says we can't mix and
> match; I don't see [gives example...]
>  causing horrid problems.  Perhaps I'm being naive.

No I don't see any problems at all with this either.  I've been assuming
that named pipes would be the only way of communicating between SEPARATE
"Command Groups" (for want of a better term).

[Your concurrent posting, Kent, will take a little longer to digest before
I respond. (...say about two weeks! (:-)).  Lots more to think about there.]

                                            -- Pete --