BASH as a Modern Programming Language [ppt](cdn.oreillystatic.com)
cdn.oreillystatic.com
BASH as a Modern Programming Language [ppt]
http://cdn.oreillystatic.com/en/assets/1/event/95/BASH%20as%20a%20Modern%20Programming%20Language%20Presentation%201.ppt
17 comments
Agreed. Many/most of the shell scripts I've ever seen using 'bash' could be using the standard 'sh' instead; most need no changes at all, and the rest need just a few minor tweaks to eliminate non-POSIX-compliant behavior.
Since Debian and other distros now use the BSD-licensed `dash` as their default system shell (system, not user) I suspect they've become more motivated to reduce unnecessary bashisms in shell scripts. Debian's 'devscripts'[1] project includes a Perl script called 'checkbashisms'[2] which you can use to detect many of these common 'bashisms'.
For those of you running Ubuntu, you can install 'devscripts' with apt-get: sudo apt-get install devscripts
For those of you running FreeBSD, you can install 'devscripts' from the devel/devscripts port.
[1]: http://packages.qa.debian.org/d/devscripts.html
[2]: http://anonscm.debian.org/gitweb/?p=collab-maint/devscripts....
Since Debian and other distros now use the BSD-licensed `dash` as their default system shell (system, not user) I suspect they've become more motivated to reduce unnecessary bashisms in shell scripts. Debian's 'devscripts'[1] project includes a Perl script called 'checkbashisms'[2] which you can use to detect many of these common 'bashisms'.
For those of you running Ubuntu, you can install 'devscripts' with apt-get: sudo apt-get install devscripts
For those of you running FreeBSD, you can install 'devscripts' from the devel/devscripts port.
[1]: http://packages.qa.debian.org/d/devscripts.html
[2]: http://anonscm.debian.org/gitweb/?p=collab-maint/devscripts....
There's no FreeBSD port called "devscripts", perhaps you meant devel/checkbashisms
You're absolutely correct, the port is devel/checkbashisms. My mistake.
https://www.freshports.org/devel/checkbashisms/
https://www.freshports.org/devel/checkbashisms/
I wish there was a linter to check shell scripts for non-POSIX syntax and command invocations.
I'm put off trying to really grok *sh scripting because the landscape seems a bit of a confusing mess.
I'm put off trying to really grok *sh scripting because the landscape seems a bit of a confusing mess.
Give checkbashisms a look. You can install it on Debian and its derivatives with
sudo apt-get install devscripts
Thank you - I'm checking it out.
[deleted]
I don't think it's true of anything but OSX and most desktop linux-en. Solaris, hp-ux, AIX use(d) ksh, QNX too I think.
Even for OSX its kinda iffy as statements go. I think (been a while now) tcsh was the default for < 10.3, 10.3 was zsh and maybe 10.4, then it moved to /bin/bash as default shell.
I think it's safe to wash <= 10.3 at this point, it has less than 0.01% market share. Most stat gatherers have actually stopped tracking anything below 10.4 or 10.5.
Also, I didn't know that zsh was ever the default? I thought it switched from tcsh to bash around 10.3 or 10.4.
Also, I didn't know that zsh was ever the default? I thought it switched from tcsh to bash around 10.3 or 10.4.
So I have an old copy of Mac OS X for Unix Geeks here.
10.2 was tcsh, 10.3 was tcsh for user shells and /bin/sh for scripts.
I think 10.4 was the zsh experiment, then 10.5+ bash. We'll see how long bash lasts being a gpl shell.
10.2 was tcsh, 10.3 was tcsh for user shells and /bin/sh for scripts.
I think 10.4 was the zsh experiment, then 10.5+ bash. We'll see how long bash lasts being a gpl shell.
zsh was only in I think 10.4 or 10.3, hard to tell anymore as I don't have any ppc machines to install any old os's on any longer.
Just giving historical context, not trying to say anything about markeshare or anything. Apple seems really willing to change shells is basically all my post amounts to.
Just giving historical context, not trying to say anything about markeshare or anything. Apple seems really willing to change shells is basically all my post amounts to.
It was zsh emulating csh. they messed up by not using the almquist shell like the other BSDs.
Even if not the default shell on BSD, is bash available (by default)?
It can be installed via ports or packages.
By default, no. Installable, yes.
Installed in /bin/bash? No as well. Don't start portable scripts with #!/bin/bash.
Installed in /bin/bash? No as well. Don't start portable scripts with #!/bin/bash.
Oh please, don't get me started on this.
Bash is much more powerful than it's usually thought of (I wrote a decent chunk of bash code, there are middle-sized projects like DKMS written in bash, etc), but still it's a language for a narrow niche (file-management and gluing other tools) with a lot of limitations:
- very weak data structures support: no trees, no decent maps (`declare -A` seems to be searched in linear time), no arrays-in-arrays;
- no typing at all, everything is a string;
- it does not have a complete standard, very much behavior is implementation-specific;
- heavy dependence on external tools (they're like libraries in modern languages);
- stunning amount of pitfalls in syntax and corner cases, escaping hell (e.g.: `scp host:"File\\ name\\ with\\ spaces" .`).
Although I have to say that multiple jobs orchestration is amazing for a language from 70ths.
Bash is much more powerful than it's usually thought of (I wrote a decent chunk of bash code, there are middle-sized projects like DKMS written in bash, etc), but still it's a language for a narrow niche (file-management and gluing other tools) with a lot of limitations:
- very weak data structures support: no trees, no decent maps (`declare -A` seems to be searched in linear time), no arrays-in-arrays;
- no typing at all, everything is a string;
- it does not have a complete standard, very much behavior is implementation-specific;
- heavy dependence on external tools (they're like libraries in modern languages);
- stunning amount of pitfalls in syntax and corner cases, escaping hell (e.g.: `scp host:"File\\ name\\ with\\ spaces" .`).
Although I have to say that multiple jobs orchestration is amazing for a language from 70ths.
The syntax corner cases are the killer, hard to debug in some cases too. And it's really really slow...
I know there would be religion issues but I'm sort of surprised there isn't a dsl and repl loop shell in ruby or python or even node that hasn't taken hold among hipsters.
I know there would be religion issues but I'm sort of surprised there isn't a dsl and repl loop shell in ruby or python or even node that hasn't taken hold among hipsters.
Bash/sh/zsh family is brilliant at intense interaction with humans. Aliases, short built-in commands, oneliner-oriented nature, keyboard ergonomics, really concise file/process handling - all of this makes it _the shell_.
I think it's hard for a language to be both suited for interactive and scripting programming, Python/Ruby/Node explicitly are languages for "heavy" scripting, they're poor choices for spending all day long with in a shell. Conciseness and obscurity of bash makes it a poor choice for "heavy" scripting. Also I think that Perl would be a nice shell and maybe that's why it's so often blamed for write-only code.
I think it's hard for a language to be both suited for interactive and scripting programming, Python/Ruby/Node explicitly are languages for "heavy" scripting, they're poor choices for spending all day long with in a shell. Conciseness and obscurity of bash makes it a poor choice for "heavy" scripting. Also I think that Perl would be a nice shell and maybe that's why it's so often blamed for write-only code.
One attempt which comes close, I think, is Shelly[1]. It's in Haskell and it's definitely not quite right for interactive(!) human interaction, but I'd use it for any remotely non-trivial scripts where quoting might be an issue.
[1] http://hackage.haskell.org/package/shelly
[1] http://hackage.haskell.org/package/shelly
> - very weak data structures support - no typing at all, everything is a string - it does not have a complete standard - stunning amount of pitfalls in syntax and corner cases, escaping hell
Sounds like the next JS. I better create Node.sh before anyone else thinks of it so I get all the credit.
Sounds like the next JS. I better create Node.sh before anyone else thinks of it so I get all the credit.
Nearly everything in the slides can be done in portable POSIX sh(1) with only minor syntactic changes to avoid bashisms.
If you really want a big shell with more language features, check out ol' AT&T ksh¹, with things like nestable structured types and floating point arithmetic. [EDIT: and 'call by reference' using variable names, to address the problem of returning or mutating complicated things.] Some of bash's features originated in ksh, as did most of the POSIX sh features added since original sh.
(1) http://pubs.opengroup.org/onlinepubs/9699919799/idx/shell.ht... ¹ http://kornshell.org/
If you really want a big shell with more language features, check out ol' AT&T ksh¹, with things like nestable structured types and floating point arithmetic. [EDIT: and 'call by reference' using variable names, to address the problem of returning or mutating complicated things.] Some of bash's features originated in ksh, as did most of the POSIX sh features added since original sh.
(1) http://pubs.opengroup.org/onlinepubs/9699919799/idx/shell.ht... ¹ http://kornshell.org/
What the...
1. Bash is definitely not the default OS shell for "all OSs" except Windows. Most Android devices, most embedded devices running a variation of Linux, a lot of Unix systems and increasingly more desktop Linux systems don't run bash as a default.
2. Pretty much every shell invokes a myriad of native binaries. That's kind of what a shell does. cmd.exe does that just as easy as bash does.
Don't get me wrong, bash is nice, but the opening part of this presentation is bullshit. Also, what the fuck happened to O'Reilly?
1. Bash is definitely not the default OS shell for "all OSs" except Windows. Most Android devices, most embedded devices running a variation of Linux, a lot of Unix systems and increasingly more desktop Linux systems don't run bash as a default.
2. Pretty much every shell invokes a myriad of native binaries. That's kind of what a shell does. cmd.exe does that just as easy as bash does.
Don't get me wrong, bash is nice, but the opening part of this presentation is bullshit. Also, what the fuck happened to O'Reilly?
.ppt? Really? Is this not available in any other format?
Ironic, what with claiming to be "modern".
I agree! Can someone upload a pdf please? I cant open ppt at the moment.
EDIT: http://www.viewdocsonline.com/document/b37ou4
EDIT: http://www.viewdocsonline.com/document/b37ou4
Google docs can convert it.
You can still use the Google viewer functionality without having to log in (i.e. "anonymously"), if you toss the original URL into the right Google URL. I don't have that particular Google URL (prefix) noted on this machine.
P.S. Here's another way to get at it, and what look to be links to pages with further details.
https://docs.google.com/viewer
https://www.google.com/#q=google+viewer+URL
http://docs.google.com/viewer?url=http%3A%2F%2Fcdn.oreillyst...
P.S. Here's another way to get at it, and what look to be links to pages with further details.
https://docs.google.com/viewer
https://www.google.com/#q=google+viewer+URL
http://docs.google.com/viewer?url=http%3A%2F%2Fcdn.oreillyst...
Bash has many features and for me has been useful to know because it's almost everywhere, but it was never designed to be what it has become. I'm working on escaping it forever with gherkin, a Lisp I wrote in Bash 4.
gherkin is still in its early days, but if you're interested in such a thing see https://github.com/alandipert/gherkin or join us in #gherkin on freenode.
gherkin is still in its early days, but if you're interested in such a thing see https://github.com/alandipert/gherkin or join us in #gherkin on freenode.
Can somebody add `[ppt]` tag to title? I can't as I don't have enough points.
My experience with bash: Once you do something a bit more complex where bashisms would be handy any shell is so slow and complicated to use that you're better of with Python, even if all your system provides is Python 2.4. And Python is pre-installed under every (non-embedded) Linux distribution I've seen and also on Mac OS X.
Python is more powerful than shells but at the same time has a much simpler syntax (much less to remember). The only thing I miss in Python sometimes is how easy you can do complex piping in shells. It's possible in Python but not at all as handy as in (ba)sh.
Python is more powerful than shells but at the same time has a much simpler syntax (much less to remember). The only thing I miss in Python sometimes is how easy you can do complex piping in shells. It's possible in Python but not at all as handy as in (ba)sh.
Ah, also FreeBSD, Solaris and probably many other Unix (like) operating systems have Python pre-installed.
Bash sucks at slicing arrays (always need a `[@]`):
${array[@]:$from:$to}
${array:$from:$to}In Bourne-descended shells, as an unfortunate historical accident, if FOO is an array, then referring to FOO without a subscript is equivalent to referring to its zeroth element.
For your example,
For your example,
${array:$from:$to}
${array[0]:$from:$to}
$ FOO=(a b c d)
$ FOO=x
$ echo ${FOO}
x
$ echo ${FOO[@]}
x b c dModerna bash/shell language? check out Window's Power Shell [1]. The one shell scripting language what I would use and the only of its type that its syntax don't scare me...
[1]: http://en.wikipedia.org/wiki/Windows_PowerShell
[1]: http://en.wikipedia.org/wiki/Windows_PowerShell
build && run_tests
PowerShell analogue
(build) -and (run_tests)
Really? Embracing commands for simple sequence?
PowerShell analogue
(build) -and (run_tests)
Really? Embracing commands for simple sequence?
Simple sequence would just be:
build; run_tests
The syntax you quoted is doing a logical AND of two expressions. Expressions are any bit of script - including calls to executables (like the example).
It's a pity that PowerShell is Windows-only (Pash notwithstanding); its syntax is small, supports pithiness and verbosity equally well, and has an easy to understand flow once you're over the first learning hump.
The syntax you quoted is doing a logical AND of two expressions. Expressions are any bit of script - including calls to executables (like the example).
It's a pity that PowerShell is Windows-only (Pash notwithstanding); its syntax is small, supports pithiness and verbosity equally well, and has an easy to understand flow once you're over the first learning hump.
Can you upload this to slideshare or something? Many people despise ppt files.
Sounds like a 1st april headline. If this article is accurate, it stretches the "Modern" qualification way too far far
Why do "modern programming languages" return 0 for true?
APL returns 1.
I know you jest, but the reason why shell programming uses 0 for success is understandable: that way you can have distinct non-zero returns for different kinds of errors (and several Unix utilities do have them). Arguably, testing for non-zero is a more satisfying idiom than testing for "non-one".
Thanks.
Are you saying that the shell (or C or assembly) is a language closely tied to a system, e.g., a CPU, a kernel and utilities - a system that can produce various types of errors?
Whereas APL is not tied to such a system, other than mathematics?
Are you saying that the shell (or C or assembly) is a language closely tied to a system, e.g., a CPU, a kernel and utilities - a system that can produce various types of errors?
Whereas APL is not tied to such a system, other than mathematics?
The shell is closely tied to running commands and the exit code of commands make up the true/false values. "return 0" in the main function of a C program means "no error" which is interpreted as true by the shell. Different non-zero return values signal different command (program) specific error states.
"The shell is closely tied to running commands..."
s/commands/programs/
But yes, I agree.
To arrive at a return value, APL evaluates a mathematical operation, whereas the shell evaluates the result(s) of executing a file.
s/commands/programs/
But yes, I agree.
To arrive at a return value, APL evaluates a mathematical operation, whereas the shell evaluates the result(s) of executing a file.
For an interesting take on "Modern Bash" I came across this a few months ago, from the deliciously twisted genius that is Ingy döt Net: https://github.com/ingydotnet/bpan-bash
I use fish instead of bash, it is pretty awesome.
[deleted]
>Is the default shell for all OSs except for Windows
BSD users would very much disagree, as would embedded Linux users and others. In fact, this assumption is a very common cause of portability problems for free and open source software.
I'm as guilty as anyone of assuming every shell is bash but when I had to make my software compile and run tests on both Linux and FreeBSD straight out of the repository I discovered that targeting the POSIX shell was not as limiting as you might think. I have since made it a habit to avoid "bashisms" in most scripts; a good way to start with that is to learn what is and isn't a bashism using a handy list found at http://mywiki.wooledge.org/Bashism.