BASH as a Modern Programming Language [ppt]
cdn.oreillystatic.com
cdn.oreillystatic.com
>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.
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.
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.
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.
I'm put off trying to really grok *sh scripting because the landscape seems a bit of a confusing mess.
sudo apt-get install 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....
Installed in /bin/bash? No as well. Don't start portable scripts with #!/bin/bash.
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.
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 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.
Sounds like the next JS. I better create Node.sh before anyone else thinks of it so I get all the credit.
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/
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?
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...
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.
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.
${array[@]:$from:$to}
${array:$from:$to}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 dPowerShell analogue
(build) -and (run_tests)
Really? Embracing commands for simple sequence?
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 whole nature of this site is about stretching things beyond their limits.
There's a line between writing a chess program in SED and claiming it's a good idea.
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?
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.