xsimon@its63b.ed.ac.uk (Simon Brown) (01/01/70)
In article <2187@emory.uucp> arnold@emory.UUCP (Arnold D. Robbins {EUCC}) writes: > >There exists a notation to do this in ksh-i, the latest version of ksh. To >use it though, your Unix must have the V8 /dev/fd mechanism (keep an eye >on comp.sources.unix for a driver for 4.3 & NFS systems, from me, originally >from Fred Blonder). Anyway the notation is > > sort (awk) (sort | grep) > >The ()'s enclose a shell pipeline, if preceded by a '<' or left alone, >the pipline's output is connected to a file in /dev/fd passed as the argument >to the program. The file will be the read end of a pipe, so sort would >see, e.g., "/dev/fd/4" and "/dev/fd/5" for its arguments, awk and the >sort|grep pipeline would write on the other side of the pipe. > >Arnold Robbins You can also implement this on a system that has FIFO special files. This has the advantage that the filenames that are passwd to the program are not forced to be of that special form /dev/fd/[number] - anything will do, so long as you can mknod a fifo with that name! This is useful for programs which insist on their filename parameters having special suffixes (such as cc, ld, tex, etc...). The only problem is thinking of a notation for allowing a filename to be given, if required, on the command line to be associated with a command. Something like (#filename command) is pretty gross, but I can't think of anything better. It does mean you can type straight into cc though, with cc (#x.c cat) (which cats from stdin into a fifo called x.c, and cc is called with this fifo as its argument). Another problem is that the fifo has to be removed when the command is finished - which can cause problems when the command is put in the background. %{ Simon. %} -- ---------------------------------- | Simon Brown | UUCP: seismo!mcvax!ukc!its63b!simon | Department of Computer Science | JANET: simon@uk.ac.ed.its63b | University of Edinburgh, | ARPA: simon%its63b.ed.ac.uk@cs.ucl.ac.uk | Scotland, UK. | ---------------------------------- "Life's like that, you know"
jack@cwi.nl (Jack Jansen) (06/03/87)
Last week, Steven Pemberton and I did some brainstorming about icons, user interfaces, pipes, etc. triggered by the recent discussions. We came up with some ideas: - There's a difference between doing something to the object (i.e. executing it) and to the meta-object (i.e. renaming it, write-protecting it). Our idea was to let clicks in the icon refer to the object, and clicks in the title bar to the meta-object. This is similar to what the Mac does (when you've selected an icon and move the mouse to the title string, you can edit it), but more general. I.e. No more 'show info' menu: double-clicking on the title bar will bring up the info menu. - Usually, you don't need to specify where the output of a program goes. Either the program has no output, the output is the same as the input (e.g. editors), or the output file name is constructed from the input file name. So, for most cases, selecting all input files and dragging them to the application is good enough. - If you *do* want to specify the output file, or certain flags, options, etc. you double click the application icon. This will make it grow into a box which contains buttons, etc. for options, and various icons for the input file, output file, etc. Now, you can set uptions, drag the output icon to where you want your output to go, drag your input files to the input icon, etc. Pipes are simple now. for 'ls -l a b | pr >/dev/lp', you do: double-click ls double-click pr drag pr output icon to printer icon drag ls output icon to pr input icon select a and b and drag them to ls input icon - There are two things we didn't really figure out how to do nicely. First is 'move'. Copy is simple (you grab the file, and feed it to the destination disk/directory), but move is slightly different. Shift-drag seems to be a good candidate, but if you want your UI to be orthogonal this means that shift-dragging a file to an application program would delete the file. This is bound to make you lose a lot of files. Second is the difference between starting an application without parameters at all and 'opening' an application to be able to specify the parameters in detail. Both of these are candidates for double click on the application. -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
taw@spar.UUCP (06/05/87)
>Pipes are simple now. for 'ls -l a b | pr >/dev/lp', you do: > double-click ls > double-click pr > drag pr output icon to printer icon > drag ls output icon to pr input icon > select a and b and drag them to ls input icon Not quite so. This approach seems to require a lot more physical movement by the person using it. Typing the command is almost effortless. I don't mean this as a condemnation of window/icon systems in favor of command-line interpreters, but I am interested in finding a visual paradigm that is *at least* as easy and powerful for simple and complicated tasks as a CLI. My major problem with this paradigm is verifiability. Suppose, just before the final step, I suddenly think that I've made an error. With the CLI version, I can re-read the command, and see if it looks right. With your approach, there is no evident control flow. You set up the right abstract pattern on the screen, and the right things happen. If you get the pattern right.... --Tom
esh@icdoc.UUCP (06/10/87)
In article <7405@boring.cwi.nl> jack@boring.UUCP (Jack Jansen) writes: > >Pipes are simple now. for 'ls -l a b | pr >/dev/lp', you do: > double-click ls > double-click pr > drag pr output icon to printer icon > drag ls output icon to pr input icon > select a and b and drag them to ls input icon > The problem with selecting a and b is that how do you tell the application that there are no more parameters, and it should start working.
peter@sugar.UUCP (Peter DaSilva) (06/17/87)
In article <454@ivax.doc.ic.ac.uk>, esh@doc.ic.ac.uk (Edward Hayes) writes: > In article <7405@boring.cwi.nl> jack@boring.UUCP (Jack Jansen) writes: > >Pipes are simple now. for 'ls -l a b | pr >/dev/lp', you do: > > double-click ls > > double-click pr > > drag pr output icon to printer icon > > drag ls output icon to pr input icon > > select a and b and drag them to ls input icon > > > The problem with selecting a and b is that how do you tell the > application that there are no more parameters, and it should start > working. A "GO" icon? Any structure you build should be editable. Thus, you could do this: Pick up ls. Drop it into "Build" window. Drop pr in next to it. Click ls and pr to link them. Pick up files and printer icons. Click a, ls, b, ls, pr, lp to hook them up. Click "GO". If you decide not to ls b, you could pick up b and drop it back on the desktop before you click GO.
adam@gec-mi-at.co.uk (Adam Quantrill) (06/24/87)
In article <454@ivax.doc.ic.ac.uk> esh@doc.ic.ac.uk (Edward Hayes) writes: }In article <7405@boring.cwi.nl> jack@boring.UUCP (Jack Jansen) writes: }> }>Pipes are simple now. for 'ls -l a b | pr >/dev/lp', you do: }> double-click ls }> double-click pr }> drag pr output icon to printer icon }> drag ls output icon to pr input icon }> select a and b and drag them to ls input icon }> }The problem with selecting a and b is that how do you tell the }application that there are no more parameters, and it should start }working. Click a then b with the right button, pick them both up with the right button and drop them in place. The left button is used to pick up just one file, and clears any outstanding right button selections. -Adam. /* If at first it don't compile, kludge, kludge again.*/
peter@sugar.UUCP (Peter DaSilva) (07/06/87)
In article <610@gec-mi-at.co.uk>, adam@gec-mi-at.co.uk (Adam Quantrill) writes: > Click a then b with the right button, pick them both up with the right button > and drop them in place. The left button is used to pick up just one file, > and clears any outstanding right button selections. Some machines have well-defined semantics for what the right button means. For example, the Amiga knows it as the menu button. For that matter, the Amiga has a well defined way of doing what you want: Click a. Hold down the shift key and click b. keep holding down the shift key and drag a and b into the icon you want to deliver them to. For building pipelines, a better way would be: Drag ls into the work window. Drag pr into the work window. Drag the files into the work window. Click a, ls; b, ls; ls, pr; pr, whatever. This connects a to ls, b to ls, ls to pr, and pr to whatever. Then you hit the doit icon or select doit from the menu. (Oh why does everyone have to use pull down menus when popups are so much more convenient?) -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)
hmm@laura.UUCP (07/09/87)
In article <367@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes: >For building pipelines, a better way would be: > >Drag ls into the work window. >Drag pr into the work window. >Drag the files into the work window. > >Click a, ls; b, ls; ls, pr; pr, whatever. > >This connects a to ls, b to ls, ls to pr, and pr to whatever. > >Then you hit the doit icon or select doit from the menu. (Oh why does everyone >have to use pull down menus when popups are so much more convenient?) Why do we have to use icons for everything ? I really see no reason to move my mouse around, collecting icons & selecting menus, when I can do the same thing with just a few keystrokes in a command line interpreter. Of course window systems have their merits, but I think we should not try to translate our good old unix habits into the mouse&icon language. There are some things that can be easily done with an icon-oriented system, like moving files, executing application programs and such stuff. Unix pipes are not among those. Of course, you can use programs and 'graphical pipes' to build up complex blocks, but the net effect is that you've got to do MORE things to get something done, instead of less. A different thing, of course, are the visual pipes or filters that someone suggested a while ago (sorry, can't find the article). If you can take a 'grep' tool like a magnifying glass, move it over some text, and see only the grepped text, you've got something useful. But none of the windowing systems that I've seen work this way. They all are just some kind of graphical shell with icons for filenames, mouse moving for the mv, cp and rm commands, and mouse clicking for the starting of programs. These are all things I can do just as good in a command line interface, thanks. Hans-Martin Mosner (hmm@unido.uucp) University of Dortmund D
peter@sugar.UUCP (Peter da Silva) (07/19/87)
In article <66@laura.irb.informatik>, hmm@unido.UUCP (Hans-Martin Mosner) writes: > In article <367@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes: > >For building pipelines, a better way would be: > > > >[fairly involved method described] > > Why do we have to use icons for everything ? We don't. Some people, however, do. There are people (believe it or not) who are not capable of dealing with anything more complex than a Macintosh. If UNIX is to become a popular operating system (something I find desirable: maybe you prefer everyone standardise on MS-DOS and the Mac), then there has to be some visible advantage that anyone can see. My assertion is that a graphical method for invoking pipelines would be something anyone can do. Also, you can describe some pipelines graphically that you would have a great deal of trouble expressing on a command line. (awk)_______ _(one set of lines) \__(sort both together)|(grep2)_/ (sort|grep)_/ \_(another set of lines) Every now and then I come across something wierd like this I want to do. I usually end up making temp files. Wasn't that the whole point of pipes in the first place? You would end up with an extremely powerful dataflow programming system. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)
throopw@xyzzy.UUCP (Wayne A. Throop) (07/29/87)
(This is being cross-posted to comp.unix.wizards, for the more wizardly denizens of that group to check my "solution" and acompanying assertion, but followups have been directed back to comp.windows.misc only.) > peter@sugar.UUCP (Peter da Silva) > [...] you can describe some pipelines graphically that you would have a great > deal of trouble expressing on a command line. > > (awk)_______ _(one set of lines) > \__(sort both together)|(grep2)_/ > (sort|grep)_/ \_(another set of lines) > > Every now and then I come across something wierd like this I want to do. > I usually end up making temp files. Wasn't that the whole point of pipes > in the first place? I disagree that it is all that hard. Assuming that you have a sort program that reads from descriptors 3 and 4 for the "sort both together", and that you have a grep that writes on descriptors 3 and 4 to generate multiple outputs, it is rendered: (awk)|3<&0((sort|grep)|4<&0 sort2)|grep2 3>one 4>another This doesn't seem all that arcane to me. Further, it can even be done with the standard unix tools, without the sort2 and grep2 processes, assuming that we have a "tee" that writes to descriptor 2 when given no arguments. (I have such a modified tee, since I find this convenient behavior for debugging simple pipelines.) Here it is: ((awk);(sort|grep))|sort|(tee|grep x >one&)2<&1|grep y >another Again, though this *is* arcane, it is not all *that* arcane, though in this case we have forced the awk and the sort|grep to be sequential, though this is not necessary. To get the awk and the sort|grep up front to run concurrently needs the special sort2 process or some general purpose line-oriented wye fitting, but this is perfectly straightforward. Assuming that the programs in the system co-operate by writing to as many output descriptors as necessary for tee junctions, and reading from as many as necessary for wye junctions, I think any directed acyclic graph of dataflow can be constructed out of unix pipes and such processes (subject only to the number of available file descriptors). I haven't rigorously proven this, but I'd be mildly surprised to be wrong. Further, sysV named pipes can easily be used to solve cases with less tractable programs (which want to be fed filenames instead of descriptors, such as the real tee). Using named pipes and an unmodified tee, the example might be p=/tmp/pipe$$.1 /etc/mknod $p p ((awk);sort|grep))|sort|(tee $p|grep x >one)&grep y $p >another rm $p > You would end up with an extremely powerful dataflow programming > system. Shell-ese already seems pretty powerful to me. Of course, it may not be as conveniant or user-friendly as it might be, but it *is* powerful, and it doesn't seem all *that* arcane. -- "You have 15 seconds to comply." --- out-of-control robot from RoboCop -- Wayne Throop <the-known-world>!mcnc!rti!xyzzy!throopw
arnold@emory.uucp (Arnold D. Robbins {EUCC}) (08/01/87)
In article <165@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes: > >> peter@sugar.UUCP (Peter da Silva) >> [...] you can describe some pipelines graphically that you would have a great >> deal of trouble expressing on a command line. >> >> (awk)_______ _(one set of lines) >> \__(sort both together)|(grep2)_/ >> (sort|grep)_/ \_(another set of lines) >> >> Every now and then I come across something wierd like this I want to do. >> I usually end up making temp files. Wasn't that the whole point of pipes >> in the first place? > > [Wayne gives an involved solution using tee and multiple file descriptors.] There exists a notation to do this in ksh-i, the latest version of ksh. To use it though, your Unix must have the V8 /dev/fd mechanism (keep an eye on comp.sources.unix for a driver for 4.3 & NFS systems, from me, originally from Fred Blonder). Anyway the notation is sort (awk) (sort | grep) The ()'s enclose a shell pipeline, if preceded by a '<' or left alone, the pipline's output is connected to a file in /dev/fd passed as the argument to the program. The file will be the read end of a pipe, so sort would see, e.g., "/dev/fd/4" and "/dev/fd/5" for its arguments, awk and the sort|grep pipeline would write on the other side of the pipe. Such a pipeline may be written to as well: command | tee >(prog1) >(prog2) would send command's output to both prog1 and prog2. There is no existing Unix tool that corresponds to the 'grep2' in Peter's example above. -- Arnold Robbins ARPA, CSNET: arnold@emory.ARPA BITNET: arnold@emory UUCP: { decvax, gatech, sun!sunatl }!emory!arnold ONE-OF-THESE-DAYS: arnold@emory.mathcs.emory.edu