[FoRK] Should Exist: a new UNIX shell

Jeff Bone <jbone at place.org> on Sun Jun 3 09:21:17 PDT 2007

On Jun 3, 2007, at 10:39 AM, Lucas Gonze wrote:

> The biggest thing the shell needs is discoverability.

fish emphasizes discoverability specifically as one of its top goals.

	http://www.fishshell.org/

	http://www.fishshell.org/user_doc/design.html

I can't really agree that this is the biggest thing the shell needs,  
as if it was I suspect lots more people --- me included --- would be  
using fish. ;-)  Here's my problem;  I sit in the shell and schlep  
huge amounts of data for analytical purposes day in, day out.  In  
doing so, at least once a day I find myself forced to actually drop  
down to some other tool just because I have some relatively simple  
--- yet more complicated than is suitable for e.g. bc --- numerical  
or otherwise complex computation I need to do.  Or I need a data  
structure more complicated than delimited line-oriented records.  Or  
I've got to join data that's coming from two different places /  
APIs / tools in two different formats.  Etc., etc., etc., --- such is  
my life. ;-)

Often I'll knock out a piece of awk inline, but when things get more  
complicated than that it's a problem;  and the fact that I've  
"tunneled" awk syntax into the shell w/ '' is vexacious, as is the  
fact that if I want to do several things w/ the awk data structures I  
create I have to write a bigger and more multi-function awk program  
than is reasonable inline.  (Same comments apply for inline Perl,  
Python, etc.)

I could use another language entirely as my interactive environment;   
I have and sometimes do exactly that.  Python / IPython / SciPy, R,  
Mathematica, whatever.  The problem with all of these is that (a)  
they make accessing the rich and infinitely composable "standard"  
UNIX toolkit and environment difficult and unnatural to use the way  
you would from a shell, and (b) they don't support that style of on- 
the-fly composition, really.  So I end up using those purely as  
languages for writing tools, or for solving limited problems, while  
the shell remains the generalist tool / interactive environment and  
compositional paradigm;  thus I don't get the benefit of the  
interactivity of those languages, except as a freebie in the debug  
cycle.

A few pointers to relevant and hopfully interesting papers...

An oldie but goodie, one of my all-time favorites, highly recommended:

	http://www.rdb.com/lib/4gl.pdf

Also check out the following;  the first is a paper about es, a shell  
with lexical scoping and higher-order functions.  The second is a  
paper about Inferno's sh, which is inspired by es and rc and has a  
different approach to first-class code blocks.

	http://citeseer.ist.psu.edu/haahr93es.html

	http://www.vitanuova.com/inferno/papers/sh.html

Also, in the section on inspirations I forgot to mention osh;  it's a  
cluster tool written in Python that supports piping of tuples  
containing Python datatypes.  It suffers from the aforementioned  
weakness of using awk on the command line --- you're "tunneling" a  
Python-like syntax into the shell through single quotes, thus there's  
impedance.  Nonetheless, it's been a sometimes-useful tool.

	http://geophile.com/osh/

> Personally, I learned about "less" when I
> happened to be watching a friend working in a shell window.

I suspect that's how most folks learn most things about the UNIX  
shell, unfortunately...

I agree --- discoverability is *a* requirement.  It is in fact the  
main thing I was implying when I listed "usability."  It's necessary  
--- but not sufficient.  To allow the shell to reach it's full  
potential, i.e. to allow me to spend more of my time solving problems  
in the shell itself rather than bopping around between various  
language tools, there are much more pressing requirements.  ;-)  (I  
don't think my use case is all that unique, btw, which is why I'm  
willing to use myself as a proxy Joe user for requirements  
generation...)

The embarrassing bit is that Microsoft --- MICROSOFT --- appears to  
have come up with a CLI that scales much more fully to "real  
programming."

Aaaargh!


jb


More information about the FoRK mailing list