Shared publicly  - 
 
1
Bookie de vries's profile photoRob Shinn's profile photoXah Lee's profile photoNick Alcock's profile photo
23 comments
 
Now if you can find a GUI representation for pipes... or bring back the oold one that never made the jump out of PARC...
Xah Lee
 
+Nick Alcock interesting question, i haven't thought of.

thinking about it for a while, i think that's getting into the realm of programing. (so, wasn't something i originally wanted to address) But nevertheless, am thinking it's doable.

for example, say we want to do
 ls -al | grep mycat

now, the gui version of ls would be the folder viewer, aka file manager, that display folders graphically. So, in the key scheme, all the options of the ls can be done by pressing certain key sequences. Then, grep part is basically a search box. So, there's a key sequence that puts cursor in search. And there's key squence that turn on/off regex or other options.

what about other things feed to grep? e.g. ps, and text search? in the case of grep, it's just searching text, so any app should be able to do it. So i think arbitrary things piping to grep is resolved here.

what about piping to other things? well, if we have A | B | C, that's basically nested function. So again, it's about programing. I think we really need to exam the use cases. unix pipe only pass text. So, piping in a sense happens only because of command line. (MS's PowerShell actually pipe objects)

yeah, now i think piping in general doesn't apply here, because it's actually programing. A GUI analog in the spirit here would be a IDE, where it can also show images, graphics, title, script, syntax highlighting, etc. Emacs would be a good example. Mathematica's default IDE, called Frontend, would be a more powerful example. Today's browser such as Firefox, Chrome, also contain web dev tools, so that's also a excellent example. In all these cases, you basically have a GUI oriented app, and part of it lets you do coding, contains interpreter, compiler, syntax coloring, command line interface, debugger, menus, can show graphics, etc. Yeah, i think this totally answers the question, satisfactory to me.
 
Well, the whole original point of GUIs is that they should be able to do anything a command-line could do. If you write off half of it as "really programming", then you turn users from people who speak a language into people who are restricted to pointing at pictures to say what they want done. We are not all one year old, and I'm sick of the way GUIs assume we are.

(And, no, 'typing into a search box' will not suffice. Pipes exchange text streams at the very least or some sort of formatted Lisp-style object-like entity otherwise, or they're useless. Again, PARC did all this already! They had a UI where you could connect bits together and stuff would stream between them. But Apple threw it away and everyone copied Apple.)

You'd need to split existing GUI programs into a frontend and backend half, where the frontend works by talking to the backend via the same protocol the pipes use, and a lot of programs work by emitting data in said protocol. (Note that there's nothing stopping the pipes being bidirectional!)

So now piping consists of plugging a bunch of these backends together and letting them talk to each other. You could let lowriter open a document and plug a search program (or lowriter with a 'search this' option) on after it and then plug something else in after that... yeah, it's programming, but it's not very complicated: a huge number of sysadmins who do not consider themselves programmers have grasped pipes. The secretaries in Bell Labs grasped not only pipes but troff, don't forget! This sort of one-shot programming is not mystic and is not all that terribly difficult: all the large-scale structuring and maintainability concerns that make programming hard just don't emerge at this scale. Piping is something almost anyone can do. (Heck, it's something four-year-olds do in the physical universe! Doing it in software should not be beyond any mentally normal adult -- if the user interface was right.)
Xah Lee
+
1
2
1
 
Nice info.

Mathematica work that way. What it calls a Frontend (the part we see), talks to a kernel (what we'd call server) thru a communication protocol called MathLink.

on the other hand, i think emacs and firefox would be counter examples. They are both rather powerful IDEs, but they are not really frontend talking to backend in the usual sense. (have you looked at the dev tools in Firefox or Chrome? it's quite powerful. Firefox recently added a 3D thingy, where you can view websites as a 3D object, and rotate it in real time. pretty cool. And the embedded js engine, REPL, and all the html visualizer is quite something.)
 
Yeah, Firefox and Emacs are thoroughly non-Unixy in that respect, and not examples to be emulated. Both are really language interpreters, i.e. mini-OSes, in themselves, and should ideally be sliced apart into their component pieces, only nobody knows quite how to do that. However, this is such an insanely large job and in FF's case the components are changing so fast that even the simple form (cutting the rendering engine off Firefox) has been dropped... :/
 
Yeah, I agree, +Nick Alcock.  Firefox is JavaScript interpreter that happens to look an aweful lot like a Web browser.
 
Note: FF is much more like Emacs than Chrome is, because it lets JS (suitably privileged, in extensions) get at virtually everything, including bits that change with every release. Chrome locks its JS into a jail and only lets it look at stable or semi-stable bits...
 
Your bit on piping, +Nick Alcock , I imagine something like JACK, but for general piping rather than for audio.
 
I can not agree with the command line limitations.
E.g., I use linux with the zsh-shell. The magic-button is the <tab>-button (as it is for many other shells too).
Printing a document via command line is a good example. This can be rather complex and differs from printer to printer.

Typing lpr <tab> a little "menu" will appear under the command line 

lpr <tab>
completing PS/PDF files
doc1.pdf                                                
doc2.pdf                                           
doc3.pdf
-docA.pdf
-docB.pdf

Hence, I get a list of printable PDF files. Continue pressing <tab> scrolls along the list. Typing the first few characters limits the possibilities for auto completion 

What if I want to change printer settings.

lpr -<tab>

completing PS/PDF files
-docB.pdf                                   -docA.pdf                             
completing option
#          - Copies                                                                  
E          - Force encryption                                                        
h          - Disables banner printing                                                
H          - hostname (alternate server)                                             
l          - Raw file                                                                
m          - Send an email on job completion                                        
o          - print job options                                                       
p          - Format with shaded header incl. date, time etc.                         
P          - Destination printer                                                     
q          - Hold job for printing.                                                  
r          - Delete files after printing                                             
T  -J  -C  - job name                                                                
U          - username (for connection to server)

I get all possible options in a list. I want to change the printer first

lpr -P<tab>

lpr -P
completing printers
B430
FUJI_XEROX_DocuPrint_C525_A -- FUJI XEROX DocuPrint
RicohMP5001                 -- Ricoh MP 5001

All printers in a list
Now change the printer option

lpr -P FUJI_XEROX_DocuPrint_C525_A -o <tab> 

completing generic printer options
cpi                    number-up              page-right           
fitplot                orientation-requested  page-top             
landscape              page-bottom            scaling              
lpi                    page-left              sides                
media                  page-ranges                                 
completing printer specific options
Duplex           InputSlot        Option1          PageSize       

A list of all generic and the specific printer options for that printer

lpr -P FUJI_XEROX_DocuPrint_C525_A -o Duplex<tab>
completing print job options
DuplexNoTumble  DuplexTumble    None  

Getting all available values for the option Duplex

finally selecting the document

lpr -P FUJI_XEROX_DocuPrint_C525_A -o Duplex=None doc1.pdf

And hit enter...

This reads much more complex as it really is. Setting up an individual print process is a matter of a few seconds without reading any man page or study options for certain printers. Even more auto-completion makes all the above pressing a couple of letters and <tabs> (the above entire command is about 20 key press). This kind of functionality is available for many command-line commands and it makes using the command line much faster and easier. In a way it comes close to what you suggest as a solution ;)
 
+Xah Lee, zsh is Emacs. The Emacs of shells (though in its sixty billion options and globbing variants it is more like Perl). That fabulously byzantine completion machinery? It's written in bytecompiled shell script. There's a layer of shell script sitting atop a lower-level completion engine in C, and the documentation for these layers takes up half the 500-page manual...
 
Yeah I would say zsh and emacs are good companions... one lacks a bit editor functions... forgot which one ;)
Xah Lee
 
if ubuntu switched zsh as default, or Mac OS does, then that's good. Else, i think zsh has little future.
 
Uh... zsh is decades old. It predates Ubuntu and in all likelihood will postdate it. It's entirely volunteer-developed (thus cannot be killed or slowed by the failure of some company or economic doldrums) and has quite a lot of users who prefer it to other shells, and an active development community..

Why on earth does a random distro choosing it make any difference to anything? It's not like a lot of Ubuntu users really care about the differences between sh/ksh/bash/zsh anyway...
Xah Lee
 
+Nick Alcock the shell war has basically ended in the 1990s. From 2000s on, shell doesn't mean much anymore, the computing langscape moved to real scripting langs such as perl, python. (and perl is pretty dead now, and ruby live) Shell, is relegated to simple interactive session. (most shell scripts, are there for compatibility reasons, i suppose. And, ubuntun made ash as default (2007ish?), which is much simpler sh, for speed reasons for system startup)

That is what i mean by dead. Sure, there's tens of thousands, or millions, of zsh users still, but so are there bsd users, solaris users, still, or even other esoteric ones like BeOS, and there's scsh. These become sub cultish things, will never see the light of the day again.
Xah Lee
 
A popular OS such as Apple, or Ubuntu, can revive it, if they just make zsh default. Then, tutorials, discussions, software, will all pay attention to it, be compatible with it, mention it, etc, if Apple or Ubuntu would do it.
 
+Xah Lee, shell scripts can accomplish certain automations to a level that "real" scripting languages like Python and Perl can't. There is a reason why many build environments make heavy use shell scripts and they're not entirely historical.
 
Yeah, shell scripts are dead. That's why my system startup still relies on it (though systemd has relegated it from that role of late in some domains), lots of daemons rely on it, at least two major financial systems are almost entirely written in it (yes, really), configure scripts are written in it (sure, they're machine-generated, but there are shell fragments in most configure.ac's and lots in Autoconf itself, let alone in things like gnulib), almost all build systems rely on it and if they don't end up reimplementing half of it badly (proof: cmake, scons). The shell remains crucial. Oh, and as for shell one-liners: even Perl hackers perpetrate them all the time.

That's what a dead thing looks like. Oh, wait.
 
this is exactly an idea i had before as well. Shell commands which explain their options through GUI popup windows.
 
+Bookie de vries Not an entirely new idea; as +Torsten Wagner points out, zsh's tab completion (no doubt inspired by ideas in 4DOS/TakeCommand from the late 1980s.) does something like that.  Programming language IDEs do something similar as well. 

I had the exact same idea as early as 1982. I've never ever seen one that's very well put together, though.  I've been tempted to code one up now and then but the main issue I've seen is maintaining responsiveness.  Even zsh bogs down now and then.
Xah Lee
+
1
2
1
 
come to think of it, emacs actually is such a system, except that it uses key chords instead of sequence, and don't pop up menu (gui or text based). Though, one can easily make it so. Am half way there.
 
+Xah Lee, again, look at Icicles; it can pop up a menu for key subsequences using the standard Icicles completion machinery (look up 'key completion' in the manual)
Add a comment...