Common shell script mistakes (2008) • Hacker News Board

Re: Common shell script mistakes (2008)

#21

Post by pwd_mkdb » Sat, Jun 04, 2016, 6:03 AM UTC

majestik wrote: post #19

gizi wrote: post #11

Bash is the love of my life! I have been working for years on this problem now (not full-time of course), gradually moving in the direction of finally being able to challenge this: "Inappropriate use shell is the main domain specific language designed to manipulate the UNIX abstractions for data and logic, i.e. files and processes. ... Correspondingly, please be wary of writing scripts that deviate from these abstrac…

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.

Re: Common shell script mistakes (2008)

#22

Post by Too » Sat, Jun 04, 2016, 6:06 AM UTC

> Just test the string directly like [ "$var" ] && echo "var not empty"

Will this work if you've activated set -u, fail on unset variables? Will the !-z variant do?

Re: Common shell script mistakes (2008)

#23

Post by pwd_mkdb » Sat, Jun 04, 2016, 6:10 AM UTC

gberger wrote: post #9

ourmandave wrote: post #4

Written in 2008.

Shell hasn't changed much, if at all, since, has it?

nope. reminds me of comments where someone is purporting to be able to assess the quality of software based only on looking to see when the last changes to the source code were made.

Re: Common shell script mistakes (2008)

#24

Post by eximius » Sat, Jun 04, 2016, 7:07 AM UTC

pwd_mkdb wrote: post #20

soyiuz wrote: post #18

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.

Something very 'readable' is something read and understood easily. Python is considered very readable, for example. I would not consider Python verbose. C++ Template programming is verbose and it is not particularly pleasant to read. At the same, APL or J or something can be very concise and is largely unreadable to most. Notice how Python, which is considered by most to be readable, is somewhere in between.

Re: Common shell script mistakes (2008)

#25

Post by eximius » Sat, Jun 04, 2016, 7:09 AM UTC

pwd_mkdb wrote: post #23

gberger wrote: post #9

Earlier quoted context omitted.

Shell hasn't changed much, if at all, since, has it?

nope. reminds me of comments where someone is purporting to be able to assess the quality of software based only on looking to see when the last changes to the source code were made.

I'm not saying that is a valid strategy, but man I see more bad old code than new code.

Re: Common shell script mistakes (2008)

#26

Post by int0x80 » Sat, Jun 04, 2016, 7:21 AM UTC

majestik wrote: post #19

gizi wrote: post #11

Bash is the love of my life! I have been working for years on this problem now (not full-time of course), gradually moving in the direction of finally being able to challenge this: "Inappropriate use shell is the main domain specific language designed to manipulate the UNIX abstractions for data and logic, i.e. files and processes. ... Correspondingly, please be wary of writing scripts that deviate from these abstrac…

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 claim that it's way easier to depend on sh being on a (UNIX) system than $SCRIPTING_LANG.

>7) Documentation

?? You can mess up documentation in any language.

Re: Common shell script mistakes (2008)

#27

Post by vacri » Sat, Jun 04, 2016, 7:41 AM UTC

pwd_mkdb wrote: post #20

soyiuz wrote: post #18

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.

If the command is as short as "echo 'found'", then that one-liner is easier, but if it's a nice, lengthy command, I find the 'full' version easier to read.

Re: Common shell script mistakes (2008)

#28

Post by brbsix » Sat, Jun 04, 2016, 8:15 AM UTC

Too wrote: post #22

> Just test the string directly like [ "$var" ] && echo "var not empty" Will this work if you've activated set -u , fail on unset variables? Will the !-z variant do?

If `set -u` is enabled, the aforementioned test will fail on unset variables. To avoid this, you can "declare" `var` at the beginning of the script, e.g. `var=''`. Also instead of `[ ! -z "$var" ]` I prefer `[ -n "$var" ]`, which is the same as `[ "$var" ]` but more explicit.

Re: Common shell script mistakes (2008)

#29

Post by teamhappy » Sat, Jun 04, 2016, 9:09 AM UTC

pwd_mkdb wrote: post #20

soyiuz wrote: post #18

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.

I define readability the same way the Linux kernel style guide does: Avoid tricky expressions.

Re: Common shell script mistakes (2008)

#30

Post by stewartbutler » Sat, Jun 04, 2016, 9:18 AM UTC

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.