5 ms·

So... He was ... Bashing bash?, I for one like my shells dirty with hidden corners and black magic. Name anywhere where you do not have bash available; embedde

So... He was ... Bashing bash?, I for one like my shells dirty with hidden corners and black magic. Name anywhere where you do not have bash available; embedded, grub, rescue boot shells. I don't do embedded. Never will. But on a serious note, does anyone know a good resource where I can pick up a better la guage and never have to bash script again? I love writing it. It I am sooo restricted by it, yet keep solving problems with it and also making good money like last night. Maybe Python is the way?

teddyh 10y ago
Maybe xonsh would be for you? (http://xon.sh/ http://xon.sh/)
wazoox 10y ago
Python and Perl are both reasonable substitutes. Perl is closer in spirit (black magic, direct call of external programs with backticks or qx(), almost direct translation of sed and awk calls).
sethrin 10y ago
I'm familiar enough with Bash to have written an opinionated but more-or-less comprehensive guide to it. I think Bash should be avoided as much as possible. Bash is great for things that you would have had to type out anyway, but using it to write programs is foolish. My rule of thumb has become, "if it's more than 30 lines long, or if it uses more than two variables, it should be written in another language". That said, I'm in the process of learning how to do that myself. Python is definitely a capable language for scripting, but I would also point out that Homebrew is built on Ruby and uses that to great effect. You might also check out this article on scripting with Ruby: http://radek.io/2015/07/13/ruby-scripting/ http://radek.io/2015/07/13/ruby-scripting/ And if anyone else has any tips on this subject please do pass them along.
- jwhite 10y ago
  I appreciate your point, but I think the choice to write all or parts of an application in shell depends a lot on what you need to achieve. Writing 100 lines of shell to glue parts of your application together may be the best way to ship something today, even if you plan to replace that with another language in 3 or 6 months time. Would you care to give a link to your guide? I'd be interested to read it.
  - sethrin 10y ago
    With a few caveats: * It's a work in progress and a bit lacking in visual presentation at the moment * The target audience is the novice developer * I am writing from my own experience and I am not an expert * "comprehensive guide" should probably have been "comprehensive primer". This is what I think beginning devs should know about the shell. https://tenebrousedge.github.io/shell_guide/shell_guide.html https://tenebrousedge.github.io/shell_guide/shell_guide.html Commentary, contributions, and criticism are invited. As far as 'shipping something today' is concerned, that's what keeps me from learning vim. At the moment I'm both working and going to school full-time, so I feel like I can't quite justify the time investment, but I know I'm holding myself back from being a far more effective programmer. I also have an acquaintance doing computational biology for whom Bash is an essential part of his toolkit for DNA analysis. Bash sometimes is the right tool for the job. It excels at text processing. It's just archaic and ugly, and we have nicer options available for programming languages. (and now that my SO is up I think I'll watch this video)
    - jwhite 10y ago
      Thank you. Looks like you've packed a lot of good stuff in there already. I only skimmed so far, but this quote stuck out: "Programming is fundamentally a way to save human labor, and that includes our own labor." I'm continually amazed at how many software engineers seem to miss this point.
      - sethrin 10y ago
        Yes, that line came out of arguments with greybeards about the problems of the younger generation and using all these fancy frameworks and wasting memory and CPU cycles. I will also add the further caveat for anyone else who arrives here that this was written in stolen hours in the last two weeks, and specifically because the page of 'Assumed Knowledge' referred to in the introduction seems to have been the only instruction in the shell given at Epicodus' Intro to Programming. I'll never love Bash as a programming language, but given that it's a tool developers use every day, I do think there's a certain minimum amount of knowledge required to use it well.
- mannykannot 10y ago
  Bash (and other shells) have their purpose, and that purpose is running processes, and process-, filesystem- and general-system administration. Pipes, especially, are so much easier in a shell than any other way that I have seen (I just noticed ninjin's comment about Julia - I will have to give it a look.) For this sort of thing, I will use a combination of Bash, Awk, Perl and Python, with Bash as the foundation, but often using at least one of the others. For example, if a step in a pipeline can easily be solved with regular expressions and/or simple arrays and hash tables, I will pick Perl, but if it needs more complicated data or functions, I will pick Python.
- thomastjeffery 10y ago
  Ruby is definitely better syntactically for scripting then Python.
ninjin 10y ago
While Python does the trick just fine, I find how Julia handles "shelling out" and IO with the shell to be very pleasing. I am probably still a bit ignorant in terms of what is out there, so I am reading the comments with great interest. https://julialang.org/blog/2012/03/shelling-out-sucks https://julialang.org/blog/2012/03/shelling-out-sucks https://julialang.org/blog/2013/04/put-this-in-your-pipe https://julialang.org/blog/2013/04/put-this-in-your-pipe
cturner 10y ago
I've been down exactly the rabbit hole you're speculating about, and my firm conclusion is: python is not a shell replacement. [update: some other posters here are referring to xonsh. Maybe they succeeded where I failed, and python can be done shellable. Will be looking into this.] * Python does strange things with IO buffering. Just when you think you've nailed all the edge-cases of this, some more come along. Its decisions are good for a general-purpose programming language, and awful for a shell. * Python is awkward for some close-to-the metal operations such as interaction with unix sessions and process groups. * Python forking is wacky. There's magic in there, and there's some stuff that gets inherited under the cover. If you fork and don't immediately execv, you are probably in for Interesting Times. When I looked at the code for Ansible, I felt a bit like I'd encountered a rival alien civilisation who had tested and reacted to the same laws of the universe, and reached identical conclusions. Ansible is written in Python. But it generates bash scripts, and then bash does dispatch. Given the power of general-purpose languages we have on unix, it's remarkable how stunted shell evolution is. Which is to say, there is an exciting opportunity here. A shell built as a Forth dialect could be a game-changer. It would have a certain number of powerful builtins. It may even evolve higher-level programming concepts. I am interested in further discussion towards this, and maybe a new github project, particularly a collaboration with someone with high fluency in Forth. I'm in London: beers. The art of a good shell would merge (1) fluid interaction; (2) effective wrapping of the unix API; (3) high-enough-level programming.
jabl 10y ago
Apart from shells having wacky syntax and semantics, due to shell pipelines being plain text, you spend a lot of time writing flaky mini parsers with stuff like sed/cut/awk/perl one-liners/ to get the data you want. In an alternative universe it would be nice if all these tools would consume and emit s-exprs. Or maybe I'm just wishing for the return of the Lisp machines, where AFAIK "the shell" was the Lisp REPL (never used one myself so I could be all wrong, of course). Kids these days would of course use json instead, at least until the serious (tm) enterprise people would swoop in and replace it all with xml and ShellReplFactoryInstanceFactoryFactoryBean.
- daxelrod 10y ago
  Are you aware of PowerShell? Pipelines act on full .Net objects.
  - catdog 10y ago
    That ties it into the .Net ecosystem. Better to pass strictly data and not behavior but in a more structured way. Yet it should still be pretty simple so sth. like json would be the right direction to go.
- vram22 10y ago
  >ShellReplFactoryInstanceFactoryFactoryBean You forgot to include Adapter, Builder, Strategy and a few other words in that.
- vram22 10y ago
  >Kids these days would of course use json instead JSON? How last week. The cool(est of the cool) kids are already moving on to TOML and its ilk.
smitherfield 10y ago
Ruby is my goto language for replacing shell scripts and even the occasional one-liner. I find it much more suited to that task than Python (more shell-like features, better regex/text processing, more flexible program structure), and much better-designed than Perl.

teddyh 10y ago

Maybe xonsh would be for you? (http://xon.sh/ http://xon.sh/)

wazoox 10y ago

Python and Perl are both reasonable substitutes. Perl is closer in spirit (black magic, direct call of external programs with backticks or qx(), almost direct translation of sed and awk calls).

sethrin 10y ago

I'm familiar enough with Bash to have written an opinionated but more-or-less comprehensive guide to it. I think Bash should be avoided as much as possible. Bash is great for things that you would have had to type out anyway, but using it to write programs is foolish. My rule of thumb has become, "if it's more than 30 lines long, or if it uses more than two variables, it should be written in another language". That said, I'm in the process of learning how to do that myself. Python is definitely a capable language for scripting, but I would also point out that Homebrew is built on Ruby and uses that to great effect. You might also check out this article on scripting with Ruby: http://radek.io/2015/07/13/ruby-scripting/ http://radek.io/2015/07/13/ruby-scripting/ And if anyone else has any tips on this subject please do pass them along.

jwhite 10y ago
I appreciate your point, but I think the choice to write all or parts of an application in shell depends a lot on what you need to achieve. Writing 100 lines of shell to glue parts of your application together may be the best way to ship something today, even if you plan to replace that with another language in 3 or 6 months time. Would you care to give a link to your guide? I'd be interested to read it.
- sethrin 10y ago
  With a few caveats: * It's a work in progress and a bit lacking in visual presentation at the moment * The target audience is the novice developer * I am writing from my own experience and I am not an expert * "comprehensive guide" should probably have been "comprehensive primer". This is what I think beginning devs should know about the shell. https://tenebrousedge.github.io/shell_guide/shell_guide.html https://tenebrousedge.github.io/shell_guide/shell_guide.html Commentary, contributions, and criticism are invited. As far as 'shipping something today' is concerned, that's what keeps me from learning vim. At the moment I'm both working and going to school full-time, so I feel like I can't quite justify the time investment, but I know I'm holding myself back from being a far more effective programmer. I also have an acquaintance doing computational biology for whom Bash is an essential part of his toolkit for DNA analysis. Bash sometimes is the right tool for the job. It excels at text processing. It's just archaic and ugly, and we have nicer options available for programming languages. (and now that my SO is up I think I'll watch this video)
  - jwhite 10y ago
    Thank you. Looks like you've packed a lot of good stuff in there already. I only skimmed so far, but this quote stuck out: "Programming is fundamentally a way to save human labor, and that includes our own labor." I'm continually amazed at how many software engineers seem to miss this point.
    - sethrin 10y ago
      Yes, that line came out of arguments with greybeards about the problems of the younger generation and using all these fancy frameworks and wasting memory and CPU cycles. I will also add the further caveat for anyone else who arrives here that this was written in stolen hours in the last two weeks, and specifically because the page of 'Assumed Knowledge' referred to in the introduction seems to have been the only instruction in the shell given at Epicodus' Intro to Programming. I'll never love Bash as a programming language, but given that it's a tool developers use every day, I do think there's a certain minimum amount of knowledge required to use it well.
mannykannot 10y ago
Bash (and other shells) have their purpose, and that purpose is running processes, and process-, filesystem- and general-system administration. Pipes, especially, are so much easier in a shell than any other way that I have seen (I just noticed ninjin's comment about Julia - I will have to give it a look.) For this sort of thing, I will use a combination of Bash, Awk, Perl and Python, with Bash as the foundation, but often using at least one of the others. For example, if a step in a pipeline can easily be solved with regular expressions and/or simple arrays and hash tables, I will pick Perl, but if it needs more complicated data or functions, I will pick Python.
thomastjeffery 10y ago
Ruby is definitely better syntactically for scripting then Python.

ninjin 10y ago

While Python does the trick just fine, I find how Julia handles "shelling out" and IO with the shell to be very pleasing. I am probably still a bit ignorant in terms of what is out there, so I am reading the comments with great interest. https://julialang.org/blog/2012/03/shelling-out-sucks https://julialang.org/blog/2012/03/shelling-out-sucks https://julialang.org/blog/2013/04/put-this-in-your-pipe https://julialang.org/blog/2013/04/put-this-in-your-pipe

cturner 10y ago

I've been down exactly the rabbit hole you're speculating about, and my firm conclusion is: python is not a shell replacement. [update: some other posters here are referring to xonsh. Maybe they succeeded where I failed, and python can be done shellable. Will be looking into this.] * Python does strange things with IO buffering. Just when you think you've nailed all the edge-cases of this, some more come along. Its decisions are good for a general-purpose programming language, and awful for a shell. * Python is awkward for some close-to-the metal operations such as interaction with unix sessions and process groups. * Python forking is wacky. There's magic in there, and there's some stuff that gets inherited under the cover. If you fork and don't immediately execv, you are probably in for Interesting Times. When I looked at the code for Ansible, I felt a bit like I'd encountered a rival alien civilisation who had tested and reacted to the same laws of the universe, and reached identical conclusions. Ansible is written in Python. But it generates bash scripts, and then bash does dispatch. Given the power of general-purpose languages we have on unix, it's remarkable how stunted shell evolution is. Which is to say, there is an exciting opportunity here. A shell built as a Forth dialect could be a game-changer. It would have a certain number of powerful builtins. It may even evolve higher-level programming concepts. I am interested in further discussion towards this, and maybe a new github project, particularly a collaboration with someone with high fluency in Forth. I'm in London: beers. The art of a good shell would merge (1) fluid interaction; (2) effective wrapping of the unix API; (3) high-enough-level programming.

jabl 10y ago

Apart from shells having wacky syntax and semantics, due to shell pipelines being plain text, you spend a lot of time writing flaky mini parsers with stuff like sed/cut/awk/perl one-liners/ to get the data you want. In an alternative universe it would be nice if all these tools would consume and emit s-exprs. Or maybe I'm just wishing for the return of the Lisp machines, where AFAIK "the shell" was the Lisp REPL (never used one myself so I could be all wrong, of course). Kids these days would of course use json instead, at least until the serious (tm) enterprise people would swoop in and replace it all with xml and ShellReplFactoryInstanceFactoryFactoryBean.

daxelrod 10y ago
Are you aware of PowerShell? Pipelines act on full .Net objects.
- catdog 10y ago
  That ties it into the .Net ecosystem. Better to pass strictly data and not behavior but in a more structured way. Yet it should still be pretty simple so sth. like json would be the right direction to go.
vram22 10y ago
>ShellReplFactoryInstanceFactoryFactoryBean You forgot to include Adapter, Builder, Strategy and a few other words in that.
vram22 10y ago
>Kids these days would of course use json instead JSON? How last week. The cool(est of the cool) kids are already moving on to TOML and its ilk.

smitherfield 10y ago

Ruby is my goto language for replacing shell scripts and even the occasional one-liner. I find it much more suited to that task than Python (more shell-like features, better regex/text processing, more flexible program structure), and much better-designed than Perl.