Newsgroups: comp.os.misc
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: Globbing
Message-ID: <1991Apr3.190845.25191@Think.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <44381@cos.com> <?55G-t_e1@cs.psu.edu> <20618@paperboy.OSF.ORG>
Date: Wed, 3 Apr 91 19:08:45 GMT

In article <20618@paperboy.OSF.ORG> coren@osf.org (Robert Coren) writes:
>In article <?55G-t_e1@cs.psu.edu>, schwartz@groucho.cs.psu.edu (Scott Schwartz) writes:
>|> Multics, apparently, had some way to
>|> do redirection ("utterly trivial", cf DMR, 1984), so it might actually
>|> have been possible in Primos.
>
>Multics's "utterly trivial" redirection, at least for output, was done
>outside of the command processor (= shell), which avoided some of the
>complexities inherent in the UNIX approach. The "file_output" command
>would redirect (the equivalent of) stdout to the specified file until
>restored by the use of "revert_output". Instances of "file_output"
>could be "stacked". Simple example:
>
>	file_output listfile; list; revert_output

There is also the syn_output command, which is analogous to Bourne shell's
">&" syntax for linking two file descriptors together.  Since Multics
doesn't have devices in the file system, this is useful along with the more
JCLish syntax for attaching arbitrary devices:

	io attach tape_stream tape_ansi_ <options>
	io open tape_stream output
	syn_output tape_stream; list; revert_output
	io (close detach) tape_stream

>Late in its life (around 1987), Multics added UNIX-style redirection

Damn right it was late in its life -- it was already canceled at the time!

>and piping; I don't remember the details, since by that time I was
>working on something else. (There were difficulties coming up with an
>acceptable syntax, as I recall, since Multics used > as the directory
>separator in pathnames. barmar, do you remember any of the details?)

A little.  I think the token we chose was ";|".  Both of these characters
are used by the command processor, but there is no useful time when they
would be adjacent.  This sequence is used for both piping and redirection,
based on context.  You can write

	<source> ;| <command1> ;| <command2> ;| <destination>

If <source> or <destination> is multiple tokens, they are either commands
to be executed or an I/O attach description; these can be distinguished by
looking for appropriate entrypoints in the executable file (commands have
entrypoints named the same as the command, I/O modules have entrypoints
named <modulename>attach).  If it's a single token, then it could also be a
data file pathname; I think it either looks at the access mode to see
whether the user has execute permission, or perhaps it looks at the
contents of the file to see whether it is in executable format, and treats
it as data if the test is false.

Yes, it's a kludge.  Also, since Multics doesn't really support
multitasking within a login session (there's a lightweight process library,
but programs have to be pretty well behaved to work with it well), pipes
don't work as well as they do on Unix (<command2> won't run until
<command1> has completed).

I think we also added something analogous to Unix `...`.  Multics already
had [<command>] for inline substitution, but this syntax requires the
command to recognize that it is being called as a function and return the
substitution string as its value.  I think we added the syntax [|<command>]
(or something similar), to substitute the standard output.

Finally, I think we added a syntax for collecting output into a temporary
file and then substituting the name of the file into the command line
(since most Multics software is designed to operate on named files, not
standard input).  I'm drawing a complete blank on the syntax we added (it's
possible that the syntax I described in the preceding paragraph was
actually used for this and I don't remember that syntax).

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
