Home » Linux » A better Linux shell? [closed]

A better Linux shell? [closed]

Posted by: admin November 29, 2017 Leave a comment

Questions:

I use bash, and have done so for over a decade – but occasionally I wonder whether there has been any significant new developments in the world of Linux shells.

A few years back Microsoft released PowerShell, which seemed very interesting. Is there any comparable innovation going on in Linux shells?

Answers:

You can run PowerShell on Linux via Pash. It uses Mono the way PowerShell uses .NET.

Questions:
Answers:

You do realize bash 4 has very recently been released with a load of new features and language additions?

  • Shell options globstar (**/foo) does a recursive search, dirspell fixes typos during pathname expansion.
  • Associative arrays, map strings to strings, instead of just numbers to strings.
  • The autocd shell option allows changing directories by just typing the directory path instead of having to put cd in front.
  • Coprocesses
  • &>> and |& redirection operators that redirect both stdout and stderr
  • Loads of additions to existing builtins for improved scripting convenience.

Check out:

Questions:
Answers:

I’d take a look at zsh or fishshell.

Questions:
Answers:

One of the least touted features of Bash (and several other shells) is the ability to write your own loadables, and have the shell run them as builtins.

Lets say you write the loadable ‘on’ .. and you want it to work like this:

on node 123 run some command
on class nodes run some command
on all nodes run some command

… etc ..

You can follow simple examples on how to write a loadable, then enable it as a bash built in via enable -f /path/to/loadable loadable_name

So in our case, enable -f /opt/bash/loadables/on on

… in your bashrc , and you’ve got it.

So, if you want to have bash interpret your spiffy new language natively, you would write a loadable named ‘use’ or ‘switch_to’, then modify the parser to load a different grammar / runtime if a certain environment variable was set.

I.e.:

#/bin/bash

switch_to my-way-cool-language

funkyfunc Zippy(int p) [[
   jive.wassup(p) ]]

Most people are not going to want to hack their shell, however. I did want to point out that facilities exist to take Bash and make it the way you want it, without fiddling too much with core code.

See /path-to-bash-source/examples/loadables, you might be able to get that to fly where you work, since you’re still using Bash.

Questions:
Answers:

I think the “original improved shell” is ksh93. bash came into existence at a time when the ksh source code was proprietary; if ksh had been open-source then, it might not have been deemed necessary to have a new shell (though with the FSF you never know). ksh is worth studying, especially for its ability to be extended through C modules, but it’s not a clear win over bash. bash’s autocompletion is clearly superior, which may be enough to make bash a win overall. In any case bash and ksh have made substantial effort to converge, so differences are minor.

The other interesting shell is zsh, which attempts to be everything that ksh is while also including csh. Since I never saw any point or use to csh, I am not the right person to advocate for zsh. I will point out one unusual incompatibility: by default, in zsh a variable $var always expands to a single token, even if it contains spaces. This behavior is incompatible with all other sh-derived shells, and it is occasionally inconvenient, but really it makes a lot more sense than the original, and it saves a hell of a lot of quoting.

csh was the first shell to have job control, but in my mind it (and its successors) has been superseded by bash and ksh. It was never mucn fun to write scripts in.

Finally, there are many tiny shells designed for rescue floppies (!) and other Spartan environments, but it sounds like you have little interest in those.

(In the matter of innovation, I should add that more than half the scripts I used to write as shell scripts are now Lua scripts. Others could say the same for Python or Ruby, or back in the day, Perl or Tcl. So I think the real innovation is migration away from the shell for programmable interaction at the command line.)

Questions:
Answers:

IIRC, Powershell is Object Oriented, whereas most unix shells and utilities operate on text. On that regard, Squirrel Shell might interest you. I’ve never used it, though.

Questions:
Answers:

If you’re willing to lose sh compatibility, you could look at using a scripting language like Python or Tcl as your shell. rlwrap can be very handy if the interpreter doesn’t provide line editing, command history, completion, etc.

One philosophy regarding shells is that they should primarily only be used to connect processes with files (here is one page that espouses that approach). That said, people have written some remarkably complex software using them.

Questions:
Answers:

Shells don’t come much more inovative than the Scheme Schell. All the power of Scheme combined with the ability to run Unix commands and an embedded awk interpreter (written in Scheme, of course). The only drawback is that it needs a tiny bit of patching to build on 64 bit Linux.

It’s not exactly Bourne-shell, but it’s different. Of course, you have to learn Scheme – bonus!

Questions:
Answers:

if you like ruby, you can use rush (ruby-unix shell, not irb)

see the presentation here

http://www.slideshare.net/adamwiggins/rush-the-ruby-shell-and-unix-integration-library

or official website to see more examples

http://rush.heroku.com/