[FoRK] Should Exist: a new UNIX shell

Stephen D. Williams <sdw at lig.net> on Sun Jun 3 09:32:13 PDT 2007

Good point, however some existing alternatives are actually worse once 
you are past the shallow level.  MS Windows, for instance, is an opaque 
mess unless you have registry guides, extra software, etc.  I can 
unravel configuration, execution paths, startup, etc. for most things in 
just about any Unix/Linux I walk up to while I'm still in the dark about 
many system things in Windows because I don't think I should have to get 
all kinds of extra stuff and information.

I used to find Unix commands by just looking through /usr/bin to find 
things I didn't understand yet.  It would be great to have a graphic 
that organized Unix/Linux software, and at another level, commands and 
config, in a logical and searchable way.


Lucas Gonze wrote:
> The biggest thing the shell needs is discoverability.  A shell
> experience is like sensory deprivation -- you are there with a
> blinking cursor, figure it out.  There are no indications of the
> possibilities.
> For example, when the "less" utility was in the process of replacing
> the "more" utility, there was no intrinsic way for "more" users to
> find out that this new thing was available.  "less" was just another
> unknown executable in $PATH.  People learned through outside means,
> like casual conversation  Personally, I learned about "less" when I
> happened to be watching a friend working in a shell window.
> Search doesn't have that problem.  Discoverability is a core part of
> the experience.  Searching for "5*3" may give you "15", but it may
> also give you instances of the term "5*3", and from there you can find
> new patterns.
> On 6/2/07, Jeff Bone <jbone at place.org> wrote:
>> Venture philanthropy --- giving away the ideas... ;-)
>> -- 
>> UNIX needs a new shell.
>> It's an embarrassment that Monad (aka msh, aka PowerShell) now
>> represents the shell state-of-the-art --- the current crop of UNIX
>> shells is far too long in the tooth.  Jettison POSIX compatibility,
>> it's an albatross at this point.  A new shell should have:
>>    * much saner quoting rules, scoping, and more consistent syntax
>> overall (cf. fish, es)
>>    * higher-order functions and first-class blocks / closures (cf. es)
>>    * data structures and a rich set of literal syntaxes for (lots of)
>> common data types (cf. rebol)
>>    * the ability to pass data structures through pipes (cf. Monad)
>>    * a module system, with on-the-fly code replacement (cf. Erlang)
>>    * decent math abilities
>>    * (perhaps) lightweight concurrency in-the-shell (cf. Erlang)
>>    * much more reflection / introspection (cf. es)
>>    * more orthogonality (cf. fish)
>>    * more usability focus (cf. fish - but lose the UI, leave that
>> elsewhere!)
>>    * a portable and higher-level set of abstractions than just libc
>> (cf. AT&T's astlib)
>>    * possibly also dialects / extensible meta-syntax (cf. rebol)
>>    * json as universal marshalling syntax, maybe + atoms?
>> Inspirations:  Monad, es, Inferno's sh, rc, ksh, fish (both the
>> Perlish research shell of that name and the "Friendly Interactive
>> Shell"), rebol, awk, tcl;  also Plan 9 / Plan B, AT&T Research's
>> astlib work and 3DFS, the JXTA *idea* (if not execution) and Erlang
>> to a lesser degree.
>> jb
>> _______________________________________________
>> FoRK mailing list
>> http://xent.com/mailman/listinfo/fork
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork

More information about the FoRK mailing list