12 ms·

I personally can't stand bash for writing scripts (it's fine for typing one-liners into terminal though). This question and its top answer capture the insanity

I personally can't stand bash for writing scripts (it's fine for typing one-liners into terminal though). This question and its top answer capture the insanity of bash quite nicely http://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash http://stackoverflow.com/questions/3601515/how-to-check-if-a... .

david-given 11y ago
Is there a better shell? By which I mean more flexible, more consistent, and simpler. (Anyone who says 'zsh' is disqualified.) I've briefly looked at rc, but while it's significantly simpler and more orthogonal than sh it's got it's own weirdnesses; but the 'Design Principles' section here is worth reading: http://plan9.bell-labs.com/sys/doc/rc.html http://plan9.bell-labs.com/sys/doc/rc.html Surely there must be a usable shell wrapped around an actual modern language?
- traverseda 11y ago
  I like xonsh. http://xonsh.org/ http://xonsh.org/ It has two modes, which can be a bit confusing. A python mode and a bash-ish mode. testdata = $(ls -l) #Takes thes bash command 'ls -l' and saves it to the python variable testdata echo ${testdata.upper()} | grep XLIO $(ls).split("\n") It uses some magic to figure out whether you're in a python context or a bash context, defaulting to python. If you save some stuff to a variable called "ls", you need to del(ls) before you can use ls as a command again.
- toothbrush 11y ago
  > Anyone who says 'zsh' is disqualified. I'm curious as to why you say that? This is a naive question, i have no skin in the game.
  - david-given 11y ago
    zsh is really powerful and flexible, but it does so by being really, really complicated --- it's basically taking bash and turning all the weirdness and bizarity up to 11. It's an uber-bash, which is very much the opposite of what I'm looking for.
    - useerup 11y ago
      > it's basically taking bash and turning all the weirdness and bizarity up to 11 While I certainly understand where you are coming from, I have found that zsh may be more complicated, but less "weird" (i.e. it is more consistent) However, zsh is tons of tons of special cases that may be mostly consistent, but without any clear concept which would allow you to remember or deduce solutions. When you are a zsh wizard you can be really productive, but it is a strange skillset that takes time to achieve and require constant refresh. IMHO the closest thing zsh has to a "concept" is that if it takes too many characters, then there's probably a special case which - if you knew it - could solve the problem in a shorter form.
  - klibertp 11y ago
    Zsh is largely compatible with bash's quirks, and then layers lots of weird things of its own on top of that. ZSH is a great, very powerful shell which I use and enjoy, but it's not any of: "simple", "consistent", "fast" or "lightweight".
    - toothbrush 11y ago
      OK. Fair enough. I use zsh (only scratching the surface) because years ago it turned out that the completion "seemed" to me to be much more powerful (e.g., fuzzy matching, substring matching, etc.), but i haven't invested time to become a wizard. Do you (or anyone else here) endorse a shell which is worth becoming a wizard in? I'm thinking perhaps eshell or simply zsh-in-M-x-shell is perhaps a good starting point, but somehow that's always felt awkward to me, notably because completion seemed to be weaker than simply xterm+zsh.
      - klibertp 11y ago
        Don't go the eshell route unless you're prepared to learn Elisp very well and then write a ton of custom Elisp code. Take a look at its documentation: > Eshell is _not_ a replacement for system shells such as ‘bash’ or ‘zsh’. Use Eshell when you want to move text between Emacs and external processes; if you only want to pipe output from one external process to another (and then another, and so on), use a system shell, because Emacs’s IO system is buffer oriented, not stream oriented, and is very inefficient at such tasks. If you want to write shell scripts in Eshell, don’t; either write an elisp library or use a system shell. And yes, I never managed to make auto-completion work really well in M-x shell (or eshell). One possible shell env you might be interested in is IPython. It's a Python REPL with support for launching external programs, shell-like variable substitution and much more. Coupled with qtconsole it makes for a great shell-like experience. I was using IPython under Windows as my shell for awhile, before switching to PowerShell.
- useerup 11y ago
  > Is there a better shell? By which I mean more flexible, more consistent, and simpler. Yes, PowerShell. And it may actually arrive at Linux/Unix soon, due to CoreCLR. The specification is already open, but until now not much progress has been made towards bringing it uncrippled to Linux/Unix PowerShell is extremely consistent. Examples: All commands are strictly on the verb-noun form where there are only 40 or so "approved" verbs. Noun represent the topic, so if you are working with ACLs, the commands are Get-Acl, Set-Acl, and if you are working with network network adapters, the commands are Disable-NetAdapter, Enable-NetAdapter, Get-NetAdapter, Rename-NetAdapter, Restart-NetAdapter, Set-NetAdapter. All (PowerShell) commands require the parameters in the same way (no - and -- confusion) as it is actually the shell that does the parameter parsing. The grammar is "modern" so it has no surprises for anyone used to context-free grammars (like C, Python, Java, ...). PowerShell is certainly flexible as it comes with the ability to invoke anything that has an exposed .NET API, or even has a WBEN/CIM standard interface (like some network switches etc).
  - nimrody 11y ago
    Can you recommend a resource for learning powershell? (Assuming one has UNIX background) [it does generate annoyingly long error messages!]
    - useerup 11y ago
      Long error messages: Yes, they can be a little strange at first. If they annoy you (or you want errors to cause a little less scrolling) you can set the "error view": $ErrorView = "CategoryView" (unlike bash, whitespace is not significant) As for learning PowerShell, if you lean towards online training, Microsoft Virtual Acedemy has a really good series of courses, even featuring Jeffrey Snover - who is surprisingly good at explaining stuff. This is a good starting point: https://www.microsoftvirtualacademy.com/en-US/training-courses/getting-started-with-powershell-3-0-jump-start-8276 https://www.microsoftvirtualacademy.com/en-US/training-cours... I usually prefer books/articles etc where I can set my own pace, but those online courses are really that good. Otherwise links: * https://technet.microsoft.com/en-us/library/cc281945(v=sql.105).aspx https://technet.microsoft.com/en-us/library/cc281945(v=sql.1... * http://learn-powershell.net/ http://learn-powershell.net/ And let's not forget the very friendly community at http://powershell.org/ http://powershell.org/ with articles such as this one: http://powershell.org/wp/2015/07/31/introduction-to-powershell/ http://powershell.org/wp/2015/07/31/introduction-to-powershe...
- _yy 11y ago
  There's fish: http://fishshell.com/ http://fishshell.com/ Also, a nice experiment: http://xonsh.org/ http://xonsh.org/ (Bash-alike with embedded Python)
  - agentultra 11y ago
    I second fish. I've been using it as my primary shell for more than a few years now. The syntax is better than bash and familiar to those who've done programming in languages like Ruby or Python. The line editor is actually useful. It handles indentation and highlighting. It will display an appropriate help page if you mess up some command. It comes bundled with argument completion for most common Unix tools and is easy to extend for other programs. for file in (ls /home/me/mp3s); echo $file; end It will also highlight incomplete paths, bad syntax, etc, as you type. I know at a glance if I messed up a path or misspelled a program name. Really useful shell.
    - omtose 11y ago
      With that example in particular, fish by default does not mess up file names containing spaces, as opposed to bash which treats them a separate files. I'm not sure why, but it's certainly useful.
      - vodik 11y ago
        What about files with newlines? evil smirk
- EdiX 11y ago
  >Surely there must be a usable shell wrapped around an actual modern language? AFAIK, the answer is no. I've spent a bit of time thinking about this problem and my conclusion is that the things that make a shell nice to use interactively are the same things that make it bad as a programming language. Rc may be as close as we will ever get to it.
- agumonkey 11y ago
  Imagine what if this one had been standard https://wryun.github.io/es-shell/manpage.html https://wryun.github.io/es-shell/manpage.html
barrkel 11y ago
Most bash scripts that I write are extended and more nicely formatted one-liners, packaged up with some help text and sanity checking for easier reuse. Rewriting in a completely different language rather than snipping out the already working text from the terminal seems a little pointless. Your link doesn't really counteract this usage. Your stance seems to be a bit like giving up on writing Javascript because of the JS WAT video. All languages have weird corners; bash has more than most because it's so old, and has only reluctantly added real programming language features, but the better you know the programming language, the more you tend to use it on the terminal. And I spend most of my non-editor, non-browser time in the terminal. I still write bash scripts in preference to Ruby or Python even in less trivial situations, especially when multiprocess orchestration of heterogeneous executables is involved.
- realharo 11y ago
  I mostly just have a problem with the default behavior of ignoring errors and continuing (yes I know it can be overridden). This coupled with the fact that you'll be working almost exclusively with strings, and all the quoting and escaping rules (which can be a huge pain themselves), can easily lead to bugs like this one https://github.com/ValveSoftware/steam-for-linux/issues/3671 https://github.com/ValveSoftware/steam-for-linux/issues/3671 . I have written some bash scripts myself, but none that were longer than maybe 10-20 lines. Above that, I usually reach for other tools.
  - barrkel 11y ago
    I've written some in the 200-300 line range, that took 500+ lines of Ruby to replace. Ruby was less efficient in wall-clock time, but easier to scale up in features. It required using a database for storage rather than line-oriented text files (the problem set was too large to fit in-memory as Ruby objects at least) - a source of performance loss, as I went with sqlite to keep things self-contained. I could have coded in a pipe / batch oriented way like bash, but then I wouldn't have gained any ease of feature implementation. If you can express a problem as a set of filters and pipes, don't need to fork too much, and have efficient executables to run each stage of the pipe, bash can be hard to beat without breaking out a real programming language with threading support. That's because bash isn't doing the heavy lifting, just doing process orchestration - something it does better than any scripting language I've used. <() in particular is tedious to do in most non-shells (and many alleged shells).
fluidcruft 11y ago
I've seen a lot of tools I use migrate from using sh wrappers to python wrappers. My observation is that it's nearly impossible to read and suffers extreme featureitis because "batteries are included".
leni536 11y ago
> This is because it doesn't distinguish between a variable that is unset and a variable that is set to the empty string. Yeah, this is insane and the default settings of bash are quite horrible. You can set some bash options in the beginning to avoid such problems. For the StackOverflow problem "set -o nounset" can be a good safeguard. Other options to look into to safeguard bash scripts from some insane behavior are "errexit" and "pipefail". Even though setting these is good practice, it doesn't stop some stuff that could be expected to be stopped by these. These options are not inherited to subshells invoked by command substitution and the likes. They wouldn't have stopped this nasty steam bug [1] for example. There are other nasty quirks too, it's really hard to unfck bash. [1] https://github.com/ValveSoftware/steam-for-linux/issues/3671#issuecomment-70161790 https://github.com/ValveSoftware/steam-for-linux/issues/3671...
- anh79 11y ago
  All lessons I've known https://github.com/icy/bash-coding-style/blob/master/LESSONS.md https://github.com/icy/bash-coding-style/blob/master/LESSONS...
  - leni536 11y ago
    Some of these are programmer errors though. Quote everything is known best practice for bash, vim lints unquoted variable expansion as red. Also bash scripts frequently interact with the FS so it's no surprise that some bugs remove files that are not meant to be removed. I think "set -o nounset" would stop the RHEL bug, although it's not clear if the variable is unset or really just an empty string. I don't want to protect bash though, but teaching bash scripting best practices would be nice. I learned these options from this site: http://kvz.io/blog/2013/11/21/bash-best-practices/ http://kvz.io/blog/2013/11/21/bash-best-practices/
rnhmjoj 11y ago
I completely agree: it's awful to do even simple things in a shell script. A shell should just be used as a shell: an interface for a human to the system in a terminal. The syntax for if-else, switch, loops, conditions is insane. I will never remember how to write a condition expression: just a missing space can break everything. I quit using bash for scripting a few months ago. Now I use haskell with shell-conduit: http://chrisdone.com/posts/shell-conduit http://chrisdone.com/posts/shell-conduit and bash only for very very simple things where haskell would be just overkill.
agumonkey 11y ago
Following the trends of transpiling modern linguistic ideas to lower languages (see all the xyz -> js), I asked why it wasn't the case, someone told me it "was", it's called awk.

david-given 11y ago

Is there a better shell? By which I mean more flexible, more consistent, and simpler. (Anyone who says 'zsh' is disqualified.) I've briefly looked at rc, but while it's significantly simpler and more orthogonal than sh it's got it's own weirdnesses; but the 'Design Principles' section here is worth reading: http://plan9.bell-labs.com/sys/doc/rc.html http://plan9.bell-labs.com/sys/doc/rc.html Surely there must be a usable shell wrapped around an actual modern language?

traverseda 11y ago
I like xonsh. http://xonsh.org/ http://xonsh.org/ It has two modes, which can be a bit confusing. A python mode and a bash-ish mode. testdata = $(ls -l) #Takes thes bash command 'ls -l' and saves it to the python variable testdata echo ${testdata.upper()} | grep XLIO $(ls).split("\n") It uses some magic to figure out whether you're in a python context or a bash context, defaulting to python. If you save some stuff to a variable called "ls", you need to del(ls) before you can use ls as a command again.
toothbrush 11y ago
> Anyone who says 'zsh' is disqualified. I'm curious as to why you say that? This is a naive question, i have no skin in the game.
- david-given 11y ago
  zsh is really powerful and flexible, but it does so by being really, really complicated --- it's basically taking bash and turning all the weirdness and bizarity up to 11. It's an uber-bash, which is very much the opposite of what I'm looking for.
  - useerup 11y ago
    > it's basically taking bash and turning all the weirdness and bizarity up to 11 While I certainly understand where you are coming from, I have found that zsh may be more complicated, but less "weird" (i.e. it is more consistent) However, zsh is tons of tons of special cases that may be mostly consistent, but without any clear concept which would allow you to remember or deduce solutions. When you are a zsh wizard you can be really productive, but it is a strange skillset that takes time to achieve and require constant refresh. IMHO the closest thing zsh has to a "concept" is that if it takes too many characters, then there's probably a special case which - if you knew it - could solve the problem in a shorter form.
- klibertp 11y ago
  Zsh is largely compatible with bash's quirks, and then layers lots of weird things of its own on top of that. ZSH is a great, very powerful shell which I use and enjoy, but it's not any of: "simple", "consistent", "fast" or "lightweight".
  - toothbrush 11y ago
    OK. Fair enough. I use zsh (only scratching the surface) because years ago it turned out that the completion "seemed" to me to be much more powerful (e.g., fuzzy matching, substring matching, etc.), but i haven't invested time to become a wizard. Do you (or anyone else here) endorse a shell which is worth becoming a wizard in? I'm thinking perhaps eshell or simply zsh-in-M-x-shell is perhaps a good starting point, but somehow that's always felt awkward to me, notably because completion seemed to be weaker than simply xterm+zsh.
    - klibertp 11y ago
      Don't go the eshell route unless you're prepared to learn Elisp very well and then write a ton of custom Elisp code. Take a look at its documentation: > Eshell is _not_ a replacement for system shells such as ‘bash’ or ‘zsh’. Use Eshell when you want to move text between Emacs and external processes; if you only want to pipe output from one external process to another (and then another, and so on), use a system shell, because Emacs’s IO system is buffer oriented, not stream oriented, and is very inefficient at such tasks. If you want to write shell scripts in Eshell, don’t; either write an elisp library or use a system shell. And yes, I never managed to make auto-completion work really well in M-x shell (or eshell). One possible shell env you might be interested in is IPython. It's a Python REPL with support for launching external programs, shell-like variable substitution and much more. Coupled with qtconsole it makes for a great shell-like experience. I was using IPython under Windows as my shell for awhile, before switching to PowerShell.
useerup 11y ago
> Is there a better shell? By which I mean more flexible, more consistent, and simpler. Yes, PowerShell. And it may actually arrive at Linux/Unix soon, due to CoreCLR. The specification is already open, but until now not much progress has been made towards bringing it uncrippled to Linux/Unix PowerShell is extremely consistent. Examples: All commands are strictly on the verb-noun form where there are only 40 or so "approved" verbs. Noun represent the topic, so if you are working with ACLs, the commands are Get-Acl, Set-Acl, and if you are working with network network adapters, the commands are Disable-NetAdapter, Enable-NetAdapter, Get-NetAdapter, Rename-NetAdapter, Restart-NetAdapter, Set-NetAdapter. All (PowerShell) commands require the parameters in the same way (no - and -- confusion) as it is actually the shell that does the parameter parsing. The grammar is "modern" so it has no surprises for anyone used to context-free grammars (like C, Python, Java, ...). PowerShell is certainly flexible as it comes with the ability to invoke anything that has an exposed .NET API, or even has a WBEN/CIM standard interface (like some network switches etc).
- nimrody 11y ago
  Can you recommend a resource for learning powershell? (Assuming one has UNIX background) [it does generate annoyingly long error messages!]
  - useerup 11y ago
    Long error messages: Yes, they can be a little strange at first. If they annoy you (or you want errors to cause a little less scrolling) you can set the "error view": $ErrorView = "CategoryView" (unlike bash, whitespace is not significant) As for learning PowerShell, if you lean towards online training, Microsoft Virtual Acedemy has a really good series of courses, even featuring Jeffrey Snover - who is surprisingly good at explaining stuff. This is a good starting point: https://www.microsoftvirtualacademy.com/en-US/training-courses/getting-started-with-powershell-3-0-jump-start-8276 https://www.microsoftvirtualacademy.com/en-US/training-cours... I usually prefer books/articles etc where I can set my own pace, but those online courses are really that good. Otherwise links: * https://technet.microsoft.com/en-us/library/cc281945(v=sql.105).aspx https://technet.microsoft.com/en-us/library/cc281945(v=sql.1... * http://learn-powershell.net/ http://learn-powershell.net/ And let's not forget the very friendly community at http://powershell.org/ http://powershell.org/ with articles such as this one: http://powershell.org/wp/2015/07/31/introduction-to-powershell/ http://powershell.org/wp/2015/07/31/introduction-to-powershe...
_yy 11y ago
There's fish: http://fishshell.com/ http://fishshell.com/ Also, a nice experiment: http://xonsh.org/ http://xonsh.org/ (Bash-alike with embedded Python)
- agentultra 11y ago
  I second fish. I've been using it as my primary shell for more than a few years now. The syntax is better than bash and familiar to those who've done programming in languages like Ruby or Python. The line editor is actually useful. It handles indentation and highlighting. It will display an appropriate help page if you mess up some command. It comes bundled with argument completion for most common Unix tools and is easy to extend for other programs. for file in (ls /home/me/mp3s); echo $file; end It will also highlight incomplete paths, bad syntax, etc, as you type. I know at a glance if I messed up a path or misspelled a program name. Really useful shell.
  - omtose 11y ago
    With that example in particular, fish by default does not mess up file names containing spaces, as opposed to bash which treats them a separate files. I'm not sure why, but it's certainly useful.
    - vodik 11y ago
      What about files with newlines? evil smirk
EdiX 11y ago
>Surely there must be a usable shell wrapped around an actual modern language? AFAIK, the answer is no. I've spent a bit of time thinking about this problem and my conclusion is that the things that make a shell nice to use interactively are the same things that make it bad as a programming language. Rc may be as close as we will ever get to it.
agumonkey 11y ago
Imagine what if this one had been standard https://wryun.github.io/es-shell/manpage.html https://wryun.github.io/es-shell/manpage.html

barrkel 11y ago

Most bash scripts that I write are extended and more nicely formatted one-liners, packaged up with some help text and sanity checking for easier reuse. Rewriting in a completely different language rather than snipping out the already working text from the terminal seems a little pointless. Your link doesn't really counteract this usage. Your stance seems to be a bit like giving up on writing Javascript because of the JS WAT video. All languages have weird corners; bash has more than most because it's so old, and has only reluctantly added real programming language features, but the better you know the programming language, the more you tend to use it on the terminal. And I spend most of my non-editor, non-browser time in the terminal. I still write bash scripts in preference to Ruby or Python even in less trivial situations, especially when multiprocess orchestration of heterogeneous executables is involved.

realharo 11y ago
I mostly just have a problem with the default behavior of ignoring errors and continuing (yes I know it can be overridden). This coupled with the fact that you'll be working almost exclusively with strings, and all the quoting and escaping rules (which can be a huge pain themselves), can easily lead to bugs like this one https://github.com/ValveSoftware/steam-for-linux/issues/3671 https://github.com/ValveSoftware/steam-for-linux/issues/3671 . I have written some bash scripts myself, but none that were longer than maybe 10-20 lines. Above that, I usually reach for other tools.
- barrkel 11y ago
  I've written some in the 200-300 line range, that took 500+ lines of Ruby to replace. Ruby was less efficient in wall-clock time, but easier to scale up in features. It required using a database for storage rather than line-oriented text files (the problem set was too large to fit in-memory as Ruby objects at least) - a source of performance loss, as I went with sqlite to keep things self-contained. I could have coded in a pipe / batch oriented way like bash, but then I wouldn't have gained any ease of feature implementation. If you can express a problem as a set of filters and pipes, don't need to fork too much, and have efficient executables to run each stage of the pipe, bash can be hard to beat without breaking out a real programming language with threading support. That's because bash isn't doing the heavy lifting, just doing process orchestration - something it does better than any scripting language I've used. <() in particular is tedious to do in most non-shells (and many alleged shells).

fluidcruft 11y ago

I've seen a lot of tools I use migrate from using sh wrappers to python wrappers. My observation is that it's nearly impossible to read and suffers extreme featureitis because "batteries are included".

leni536 11y ago

> This is because it doesn't distinguish between a variable that is unset and a variable that is set to the empty string. Yeah, this is insane and the default settings of bash are quite horrible. You can set some bash options in the beginning to avoid such problems. For the StackOverflow problem "set -o nounset" can be a good safeguard. Other options to look into to safeguard bash scripts from some insane behavior are "errexit" and "pipefail". Even though setting these is good practice, it doesn't stop some stuff that could be expected to be stopped by these. These options are not inherited to subshells invoked by command substitution and the likes. They wouldn't have stopped this nasty steam bug [1] for example. There are other nasty quirks too, it's really hard to unfck bash. [1] https://github.com/ValveSoftware/steam-for-linux/issues/3671#issuecomment-70161790 https://github.com/ValveSoftware/steam-for-linux/issues/3671...

anh79 11y ago
All lessons I've known https://github.com/icy/bash-coding-style/blob/master/LESSONS.md https://github.com/icy/bash-coding-style/blob/master/LESSONS...
- leni536 11y ago
  Some of these are programmer errors though. Quote everything is known best practice for bash, vim lints unquoted variable expansion as red. Also bash scripts frequently interact with the FS so it's no surprise that some bugs remove files that are not meant to be removed. I think "set -o nounset" would stop the RHEL bug, although it's not clear if the variable is unset or really just an empty string. I don't want to protect bash though, but teaching bash scripting best practices would be nice. I learned these options from this site: http://kvz.io/blog/2013/11/21/bash-best-practices/ http://kvz.io/blog/2013/11/21/bash-best-practices/

rnhmjoj 11y ago

I completely agree: it's awful to do even simple things in a shell script. A shell should just be used as a shell: an interface for a human to the system in a terminal. The syntax for if-else, switch, loops, conditions is insane. I will never remember how to write a condition expression: just a missing space can break everything. I quit using bash for scripting a few months ago. Now I use haskell with shell-conduit: http://chrisdone.com/posts/shell-conduit http://chrisdone.com/posts/shell-conduit and bash only for very very simple things where haskell would be just overkill.

agumonkey 11y ago

Following the trends of transpiling modern linguistic ideas to lower languages (see all the xyz -> js), I asked why it wasn't the case, someone told me it "was", it's called awk.