That temp file example is a vulnerable to symlink attacks.
Common shell script mistakes (2008)
51–60 of 82 posts
Re: Common shell script mistakes (2008)
#52Earlier quoted context omitted.
This is not @pwd_mkdb's logic though, it's you who brought this to the extreme.
Not really. @pwd_mkdb said he defines readability as "less code to read". 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.
> If that's the only criterion, then the parent just followed the logic.
wodenokoto offered up some reductio ad absurdum and you are calling it logic.
It was not the only criterion. It was the only criterion that was explicit. There are implied criterion and most of us understand what pwd_mkdb means even if we don't necessarily agree with him.
Re: Common shell script mistakes (2008)
#53So 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.
political correctness easily gets in the way of the serious warning that should go out to the younger folks: stay the f*ck away from bash and its siblings! do not ever think it is a solution worth considering! abandon!
instead use something with a cross-platform interface (Python, Chrome or Lua, whatever), compile your own executable or use a compiler that targets bash.
besides, it is only a matter of time before the systemd trojan invades this area, and your newly acquired skills will be obsolete .
Re: Common shell script mistakes (2008)
#54Earlier quoted context omitted.
When it this last time you logged into a box and /bin/bash wasn't an option? Let me guess 1999 on a SPARC box running Sun Solaris?
If you limit yourself to either a popular Linux distro or one of two Unixes/Unix-likes, then bash can be available out of the box. Just as C is not C++, shell is not bash, so a shell script is what runs on (d)ash, busybox, toybox, ksh, bash, zsh, etc., without modifications. If it requires bash or zsh, then it's not a shell script but a bash/zsh/fish script. To name a popular non-Linux OS, take a fresh FreeBSD or Ope…
> To name a popular non-Linux OS, take a fresh FreeBSD or OpenBSD install. No bash to be found, unless installed via ports and rightfully so.
And even if you do install it, it still won't work with scripts that specify /bin/bash (which is a lot of them, thanks to sloppy tutorials), since it will be in /usr/local/bin and not /bin.
Re: Common shell script mistakes (2008)
#55Earlier quoted context omitted.
But once you adopt bash-only features, you're losing the main argument for a shell script: portable scripting without the need to first install something to get something else running. Once you require Bash, it's equally easy to demand Perl and that will provide a much richer scripting experience.
When it this last time you logged into a box and /bin/bash wasn't an option? Let me guess 1999 on a SPARC box running Sun Solaris?
On QNX all you get is ksh, which has little support for bash-isms.
Re: Common shell script mistakes (2008)
#56Earlier quoted context omitted.
But once you adopt bash-only features, you're losing the main argument for a shell script: portable scripting without the need to first install something to get something else running. Once you require Bash, it's equally easy to demand Perl and that will provide a much richer scripting experience.
When it this last time you logged into a box and /bin/bash wasn't an option? Let me guess 1999 on a SPARC box running Sun Solaris?
Do embedded systems count? ;)
Re: Common shell script mistakes (2008)
#57Earlier quoted context omitted.
Not really. @pwd_mkdb said he defines readability as "less code to read". 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.
> If that's the only criterion, then the parent just followed the logic. wodenokoto offered up some reductio ad absurdum and you are calling it logic. It was not the only criterion. It was the only criterion that was explicit. There are implied criterion and most of us understand what pwd_mkdb means even if we don't necessarily agree with him.
>It was the only criterion that was explicit.
Well, even in itself, it is wrong.
It's not just that other criteria apply too -- it's that it alone needs several caveats, as succinctness is quite orthogonal to readability (e.g. sometimes even needless boilerplate syntax that the compiler could infer by itself, make for better readability when present).
Re: Common shell script mistakes (2008)
#58Great 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.
Is ts cmmt esr t rd?
Re: Common shell script mistakes (2008)
#59So 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.
Perl is brutally under-rated as a scripting tool these days. I suppose it's passed into software orthodoxy by this point, the notion that perl is a uniformly horrific tool akin to nuclear waste.
Although Perl6 exists, Perl5 is completely unfit for any purpose on the modern world. And just the memories from helpless hours debugging any simple 30 lines script means that I'll resort to Haskell before trying Perl6 for text manipulation uses.
An younger developer may think differently, but I do think the 'Perl' brand is already too damaged for surviving the transition, even if Perl6 is better than modern languages (what I didn't see anybody claiming yet).
Re: Common shell script mistakes (2008)
#60Earlier quoted context omitted.
>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…
Shell makes it easy to spawn multiple processes. It makes it reasonably easy to read those processes' standard out or standard error, though it's not that much fun to try to do both at the same time while keeping them distinct. [1] It pretty much doesn't do anything else that you might want to do with multiple processes, though, and it tends to encourage multiple processes to communicate via text which is a problemat…
I think with the shell you have to adapt your abstractions to the "unix-way". For example, a queue to process will be a directory with N files, and each file can be processed in pararell by just something like "for f in dir/*; do process.sh "$f" & done;" but yeah ... it has limitations like everything.