4 ms·

I've always wondered why shells based on popular scripting languages don't catch on more...especially after living with Bash's horrible (my opinion) syntax over

by rufugee 16y ago

I've always wondered why shells based on popular scripting languages don't catch on more...especially after living with Bash's horrible (my opinion) syntax over the years, and Korn before that. I know there have been a few shells created based on perl and perhaps python, but when I played with them years ago they seemed half-assed. Is there something special about the shell that requires one to create their own scripting language? I for one would love to have a well-done, reliable login shell based on ruby...

viraptor 16y ago
There are a few shells like that. At least 5 different ruby-based (all barely doing the basic stuff, although http://rush.heroku.com/ http://rush.heroku.com/ is not bad at all). Zoidberg (perl) is ok, but there is a lot of perl involved so you can run into situations where typical bash stuff triggers perl execution... I really like iPython's psh - unfortunately it's not well known, since it's not advertised properly (they concentrate on the python's repl part a lot). It does work quite well though: http://ipython.scipy.org/doc/manual/html/interactive/shell.html http://ipython.scipy.org/doc/manual/html/interactive/shell.h...
cldwalker 16y ago
You may be interested in ripl (https://github.com/cldwalker/ripl https://github.com/cldwalker/ripl) which is modular enough to serve as a base for more complex shells. It has already been used to create a web shell (http://github.com/cldwalker/nirvana http://github.com/cldwalker/nirvana), a ruby/system shell (https://github.com/janlelis/fresh https://github.com/janlelis/fresh) and a js shell (http://github.com/cldwalker/ripl-johnson http://github.com/cldwalker/ripl-johnson).
sjs 16y ago
Traditional shells provide some small conveniences that are hard to give up. You cannot shoehorn this stuff into an existing language by defining global functions, it must be syntax. Ruby could come close by not requiring parens, but still cannot allow something like the following zsh command without extra quoting, parens, or function calls. for f ({foo,bar}/*(.)) { cp -v $f ${f%.js}.min.js } > output.txt
- burgerbrain 16y ago
  Scsh (a Scheme based shell) is probably the most promising example of the shell revisited and done in an established language that I've seen, but there are serious problems with it's implementation. It won't run on x86_64 for starters... S-Expressions should allow you to do anything a shell can do, and with good completion (it'd have to be at least as good as Zsh's) I could see it being usable. Somebody just needs to do it right.
technomancy 16y ago
I've used eshell for years because I can't be bothered to learn a crazy one-off language like bash just to configure my shell. Elisp is atrocious compared to other lisps, but it's a dream compared to any other shell language. It solves most of the complaints in TFA; the only downside is poor documentation and poor performance for IO-heavy operations.
- neutronicus 16y ago
  I was a M-x shell guy until one job where starting to build the project in M-x shell caused the build script to bork. I still have no fucking idea why it happened, but it's scared me off of everything but standard bash since.
  - technomancy 16y ago
    If that had happened to me it would have scared me off custom build scripts.
  - jamesaguilar 16y ago
    If your environment is anything like mine, someone in your organization probably thought using curses in the build script would be a clever thing to do, but didn't gracefully fall back when the script was not running in a terminal.
jimbokun 16y ago
For me, one issue with programming language shells is just getting ls, cd, etc. working with tab completion. The other big issue is having to build up commands to execute through String concatenation, which feels just as awkward and inelegant as building up SQL commands through String concatenation. Maybe you could do some funky namespace stuff where programs on your path are imported as functions? grep("foo", "bar.txt") (Note we still have the superfluous quotation marks. How to get rid of those?) In short, a shell is a DSL for executing programs, redirecting IO, and exploring a file system. It is hard to tweak a general purpose programming language to the point where it is better at those tasks than a shell. I imagine some of the programming language specific shells mentioned in the article have found ways of solving these problems, and I would be interested in hearing what those solutions are.
- technomancy 16y ago
  > I imagine some of the programming language specific shells mentioned in the article have found ways of solving these problems, and I would be interested in hearing what those solutions are. Eshell does a great job at this; it feels like a shell, but it also feels like invoking lisp functions. Obviously you're not typing direct function invocations otherwise you would have to quote all your strings, etc; but it's pretty close. You can pipe output from processes straight into Emacs buffers or even into functions. All the shell commands that have nicer Emacs equivalents (grep, top, man, etc) get intercepted so you get the enhanced hyperlinks in grep results, etc. I find it absolutely indispensible. http://www.masteringemacs.org/articles/2010/12/13/complete-guide-mastering-eshell/ http://www.masteringemacs.org/articles/2010/12/13/complete-g...
  - jimbokun 16y ago
    Um, wow! Eshell could be just what I've been looking for, considering I spend much of my day in Emacs anyways. Might be time to brush up on Emacs Lisp...
- albertzeyer 16y ago
  What does DSL stand for? Edit: Ah, I guess it is Domain-specific language.
rikthevik 16y ago
I don't think a Tcl command shell would be out of the question. It's simple and powerful, but still quite terse. Most EDA software includes an interactive Tcl shell as well - they're quite popular with ASIC and FPGA designers.
- piranha 16y ago
  Yep, I think so as well - TCL could be nice replacement for current shell syntax, but choice and state of TCL shells is quite sad. :(
sandGorgon 16y ago
take that one step further. Currently an Ubuntu system depends on bash, ash, perl and python scripts for various tasks - booting up, init, etc. Take one scripting language and use that completely. Not an easy task, since you will have to do stuff like have a perfectly compatible PCRE library, etc.

by rufugee 16y ago

viraptor 16y ago

There are a few shells like that. At least 5 different ruby-based (all barely doing the basic stuff, although http://rush.heroku.com/ http://rush.heroku.com/ is not bad at all). Zoidberg (perl) is ok, but there is a lot of perl involved so you can run into situations where typical bash stuff triggers perl execution... I really like iPython's psh - unfortunately it's not well known, since it's not advertised properly (they concentrate on the python's repl part a lot). It does work quite well though: http://ipython.scipy.org/doc/manual/html/interactive/shell.html http://ipython.scipy.org/doc/manual/html/interactive/shell.h...

cldwalker 16y ago

You may be interested in ripl (https://github.com/cldwalker/ripl https://github.com/cldwalker/ripl) which is modular enough to serve as a base for more complex shells. It has already been used to create a web shell (http://github.com/cldwalker/nirvana http://github.com/cldwalker/nirvana), a ruby/system shell (https://github.com/janlelis/fresh https://github.com/janlelis/fresh) and a js shell (http://github.com/cldwalker/ripl-johnson http://github.com/cldwalker/ripl-johnson).

sjs 16y ago

Traditional shells provide some small conveniences that are hard to give up. You cannot shoehorn this stuff into an existing language by defining global functions, it must be syntax. Ruby could come close by not requiring parens, but still cannot allow something like the following zsh command without extra quoting, parens, or function calls. for f ({foo,bar}/*(.)) { cp -v $f ${f%.js}.min.js } > output.txt

burgerbrain 16y ago
Scsh (a Scheme based shell) is probably the most promising example of the shell revisited and done in an established language that I've seen, but there are serious problems with it's implementation. It won't run on x86_64 for starters... S-Expressions should allow you to do anything a shell can do, and with good completion (it'd have to be at least as good as Zsh's) I could see it being usable. Somebody just needs to do it right.

technomancy 16y ago

I've used eshell for years because I can't be bothered to learn a crazy one-off language like bash just to configure my shell. Elisp is atrocious compared to other lisps, but it's a dream compared to any other shell language. It solves most of the complaints in TFA; the only downside is poor documentation and poor performance for IO-heavy operations.

neutronicus 16y ago
I was a M-x shell guy until one job where starting to build the project in M-x shell caused the build script to bork. I still have no fucking idea why it happened, but it's scared me off of everything but standard bash since.
- technomancy 16y ago
  If that had happened to me it would have scared me off custom build scripts.
- jamesaguilar 16y ago
  If your environment is anything like mine, someone in your organization probably thought using curses in the build script would be a clever thing to do, but didn't gracefully fall back when the script was not running in a terminal.

jimbokun 16y ago

For me, one issue with programming language shells is just getting ls, cd, etc. working with tab completion. The other big issue is having to build up commands to execute through String concatenation, which feels just as awkward and inelegant as building up SQL commands through String concatenation. Maybe you could do some funky namespace stuff where programs on your path are imported as functions? grep("foo", "bar.txt") (Note we still have the superfluous quotation marks. How to get rid of those?) In short, a shell is a DSL for executing programs, redirecting IO, and exploring a file system. It is hard to tweak a general purpose programming language to the point where it is better at those tasks than a shell. I imagine some of the programming language specific shells mentioned in the article have found ways of solving these problems, and I would be interested in hearing what those solutions are.

technomancy 16y ago
> I imagine some of the programming language specific shells mentioned in the article have found ways of solving these problems, and I would be interested in hearing what those solutions are. Eshell does a great job at this; it feels like a shell, but it also feels like invoking lisp functions. Obviously you're not typing direct function invocations otherwise you would have to quote all your strings, etc; but it's pretty close. You can pipe output from processes straight into Emacs buffers or even into functions. All the shell commands that have nicer Emacs equivalents (grep, top, man, etc) get intercepted so you get the enhanced hyperlinks in grep results, etc. I find it absolutely indispensible. http://www.masteringemacs.org/articles/2010/12/13/complete-guide-mastering-eshell/ http://www.masteringemacs.org/articles/2010/12/13/complete-g...
- jimbokun 16y ago
  Um, wow! Eshell could be just what I've been looking for, considering I spend much of my day in Emacs anyways. Might be time to brush up on Emacs Lisp...
albertzeyer 16y ago
What does DSL stand for? Edit: Ah, I guess it is Domain-specific language.

rikthevik 16y ago

I don't think a Tcl command shell would be out of the question. It's simple and powerful, but still quite terse. Most EDA software includes an interactive Tcl shell as well - they're quite popular with ASIC and FPGA designers.

piranha 16y ago
Yep, I think so as well - TCL could be nice replacement for current shell syntax, but choice and state of TCL shells is quite sad. :(

sandGorgon 16y ago

take that one step further. Currently an Ubuntu system depends on bash, ash, perl and python scripts for various tasks - booting up, init, etc. Take one scripting language and use that completely. Not an easy task, since you will have to do stuff like have a perfectly compatible PCRE library, etc.