31–40 of 82 posts
Don't" [0]
[0] MIT, writing safe shellscripts ~ https://sipb.mit.edu/doc/safe-shell/
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 me less code to read. that's how i define "readability". but if forum commments are any indication, i know my preferences do not follow the norm. most programmers seems to prefer verbosity. however in my case verbosity slows me down.
The google shell style guide linked now lives here and is probably an even better starting point than this article: https://google.github.io/styleguide/shell.xml
Earlier quoted context omitted.
Ok, I'll bite. >> My personal belief is that everything that you can do in other scripting languages, you can also do in Bash, only better. 1) Native JSON, XML 2) Classes, namespacing, objects 3) Multiprocessing, multithreading 4) Performance 5) Package management 6) Portability 7) Documentation 8) Runtime debugging (!set -x) I'm too tired to continue.
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.
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.
Earlier quoted context omitted.
concision gets me less code to read. that's how i define "readability". but if forum commments are any indication, i know my preferences do not follow the norm. most programmers seems to prefer verbosity. however in my case verbosity slows me down.
By that logic you find minified javascript easier to read too.
So many edge cases. I prefer to just use perl if I am doing anything more complicated than making a wrapper for some other executable. Harder to screw up, easier to test, same expressiveness, better portability (works with all shells and with windows), plus you get regular expressions for free. Python is a good alternative as well.
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 me less code to read. that's how i define "readability". but if forum commments are any indication, i know my preferences do not follow the norm. most programmers seems to prefer verbosity. however in my case verbosity slows me down.
That's a bad definition. Readability should be: "code easier to read", not just "less code to read" -- since less is not always easier and can even be much harder.
Case in point: the J language.
Or "magic" constructs that do too much under the scenes and don't let you immediately understand what a part of code is doing.
Earlier quoted context omitted.
By that logic you find minified javascript easier to read too.
This is not @pwd_mkdb's logic though, it's you who brought this to the extreme.
If that's the only criterion, then the parent just followed the logic. Or let's put it another way, if the definition of readability can't survive taking it to the extreme, it is flawed.
Earlier quoted context omitted.
Ok, I'll bite. >> My personal belief is that everything that you can do in other scripting languages, you can also do in Bash, only better. 1) Native JSON, XML 2) Classes, namespacing, objects 3) Multiprocessing, multithreading 4) Performance 5) Package management 6) Portability 7) Documentation 8) Runtime debugging (!set -x) I'm too tired to continue.
>3) Multiprocessing IMO shell makes it very easy to work with multiple process (&). It's built in and natural. >4) Performance If you are carefull and know what you're doing, you can achive very good performance with the shell. Usually, better performance is achived processing less data, ie being inteligent. Rarely depends on the language (unless you care about cycle level performance, then yes :). >6) Portability I…
What I would like in bash is some easy way to limit the number of background processes I can spawn, and to just wait when I try to start another one until an existing one is finished.
Some simple jobs can be converted to use xargs -P, but for more complex things I end up having to do them without parallelisation, so I don't end up spawning 100s of background processes and bring my computer to it's knees.
In a POSIX conforming shell,
&> word
& > word
The more commonly seen >& will bite you even in bash. What does this do?
>& $FILENAME
Note that bash accepts both even in its so-called ‘POSIX compatible’ mode.