71–80 of 82 posts
Earlier quoted context omitted.
Bourne shell being replaced as /bin/sh by dash doesn't change anything: Linux and OSX don't use /bin/sh as the default shell.
> Linux and OSX don't use /bin/sh as the default shell. You didn't even read the first sentence of the first hyperlinked page.
Earlier quoted context omitted.
my personal belief is that anything one can do in bash i can do in sh. not sure if that's really true in practice, but that's my belief. i never use bashisms because i do not know what they are or how to use them.
You're just having a laugh at the OP, right? In case you're not, here are some "Bashisms" that really suck to be without: * built-in regex support (e.g. `[[ $var =~ ^1\.2\.[34]$ ]]`) * process substitution (e.g. `diff * indexed and associative arrays Some of this can be worked around by shelling off to grep for regular expression matching or awk for arrays, but Bash makes things so much cleaner and maintainable.
AFAIK in POSIX /bin/sh it's not possible to detect if a process that writes into a pipe exits with an error status.
bash has "set -o pipefail" and "$PIPESTATUS" for that.
Earlier quoted context omitted.
Bourne shell being replaced as /bin/sh by dash doesn't change anything: Linux and OSX don't use /bin/sh as the default shell.
> Linux and OSX don't use /bin/sh as the default shell. You didn't even read the first sentence of the first hyperlinked page.
Do, again: whether bin sh is Bourne or Dash doesn't change anything, because a properly written script will specify its interpreter.
Earlier quoted context omitted.
> Linux and OSX don't use /bin/sh as the default shell. You didn't even read the first sentence of the first hyperlinked page.
I believe xe meant "default login shell". Also, "Bourne Again shell", while we're complaining about missing words :-)
Even if bin sh links to bash, bash will still run a bin sh script in Bourne shell mode, stripping newer features, in some cases. Hence why proper scripts alway specify bash explicitly.
However I meant Bourne shell when I wrote 'ignore all the good things bash brings and write everything in Bourne shell.' Bourne shell being the original /bin/sh (though it's murky).
Earlier quoted context omitted.
Do embedded systems count? ;)
I'm having trouble remembering the last time I saw a BSD box during my work day, unless Juniper gear counts. No knock against BSD but seriously how many people are writing POSIX shell scripts because they need their shell scripts to work with Linux, QNX and BSD?
When I mentioned embedded systems I primarily thought of Linux/Busybox-based devices, like OpenWRT. While one surely can have bash there, usually base image doesn't contain it.
Same story about the most common Linux-based OS out there: Android. And, while it's no one manually runs shell scripts there, apps quite frequently exec() things, so shell scripting still matters there - a tiny bit. Also, shell scripting is heavily used in firmware upgrades/patches, as well as a glue for the root/unlocking hacks.
If you plan to write a redistributable component or an useful hack for such platforms, you'd best stick with a very limited subset of POSIX.
Earlier quoted context omitted.
The google shell style uses bash which is not portable, one of the main point of the OP article.
Bash is the default shell on the most popular server nix (Linux) and the most desktop nix (OS X, though it's always a slightly old version). If you use OpenBSD and hate ports, then maybe ignore all the good things bash brings and write everything in Bourne shell. If not, then write bash. Just fire it up with '/usr/bin/env bash' to label it correctly.
If Bourne is not comfortable or powerful enough for the task you're trying to do, you're using the wrong tool and Python is probably what you should be using.
Earlier quoted context omitted.
Bash is the default shell on the most popular server nix (Linux) and the most desktop nix (OS X, though it's always a slightly old version). If you use OpenBSD and hate ports, then maybe ignore all the good things bash brings and write everything in Bourne shell. If not, then write bash. Just fire it up with '/usr/bin/env bash' to label it correctly.
>If you use OpenBSD and hate ports, then maybe ignore all the good things bash brings and write everything in Bourne shell. If not, then write bash. If Bourne is not comfortable or powerful enough for the task you're trying to do, you're using the wrong tool and Python is probably what you should be using.
I guess you think Bourne shell -> Python depending on complexity. I think bash -> Python depending on complexity.
Great post. I disagree on using the concise form of the if statement, however. if [ "$var" = "find" ]; then echo "found" fi Is far more readable than its equivalent [ "$var" = "find" ] && echo "found" I understand the upside of readability. What does concision get me?
Concision gets you fewer places to possibly have a bug, and fewer things to possibly miss/misunderstand.
Earlier quoted context omitted.
>If you use OpenBSD and hate ports, then maybe ignore all the good things bash brings and write everything in Bourne shell. If not, then write bash. If Bourne is not comfortable or powerful enough for the task you're trying to do, you're using the wrong tool and Python is probably what you should be using.
Yeah I'd do most systems work in Python too, but bash has some useful safety options in shopt, some neat syntax items like ..., arithmetic subshells, etc. which can make it fine for basic scripts. I guess you think Bourne shell -> Python depending on complexity. I think bash -> Python depending on complexity.
As long as it's for your own system administration, sure. The moment it's being used for software intended to be used by third parties, no, the niceties of bash over bsh are not worth it.
Earlier quoted context omitted.
Yeah I'd do most systems work in Python too, but bash has some useful safety options in shopt, some neat syntax items like ..., arithmetic subshells, etc. which can make it fine for basic scripts. I guess you think Bourne shell -> Python depending on complexity. I think bash -> Python depending on complexity.
>which can make it fine for basic scripts. As long as it's for your own system administration, sure. The moment it's being used for software intended to be used by third parties, no, the niceties of bash over bsh are not worth it.
Worth what? What do you lose?