🚀 go-pugleaf

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.  Besides, see my concurrent
post peeling the next layer off the onion to get to the rotten core; it
is a _very_ tough problem when addressed in generality.

The problem is in part that your and my and da Silva's little digression
is mixed among raging arguments about the difficulty of hitting the
space bar before the virigule, a problem all sides of which could have
been presented in three lines at most.

> We were discussing the syntax that a system would need to do such a
> job, I thought.

Yes, designing a syntax that is reasonably natural, contains relatively
few landmines for the unwary, captures the full needed functionality,
and is implementable with reasonable effort is a task in and of itself.
Actually doing the implementation is another question.

> As to the particular suggested syntax, I think it IS probably rather
> more complex than it should be. I considered both Kent's and my
> suggestions as first-cut ones that would need to be hammered on.

Certainly in my case, since I can't implement what I design, I have to
get by on my good looks and sweet disposition, which includes being
pleasent to folks who didn't like my _perfect_ first draft.  ;-)

> The other feature of (unix-shell) pipes of course that has been of
> major concern in this thread is that -- unlike files, temp or
> otherwise -- they 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). Given our proposal functioning, it would probably be best if
the pipe names were silently prefixed with the current process ID. This
would give them "relative names", which would provide the benefits of
anonymous pipes being non-conflicting, while retaining the added
functionality of tagging pipe ends to help the shell parser match up the
correct pieces.  An executing shell script, I hope, would have a process
ID of its own to assign.

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:

	PIPE type >-{2,3} some_garbage +
	type -<2 > pipe:a              +
	type -<3 > *

in CLI window 1, and

	type < pipe:a

in CLI window 2 causing horrid problems.  Perhaps I'm being naive.

> Of course my concern is not really at all with "The Way Unix Does It",
> but what new and BETTER things can we do on the Amiga? And even if
> it's only OCCASIONALLY very useful, that's probably enough... Once a
> facility is available, you find applications you never would have
> thought of otherwise.

And make a base from which others can build.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>