9 common mistakes in shell programming

[gasparch]

I think, that all of you, who started to work with Unixes not so long ago face problems when using shell or trying to program in shell. Many of Unix novices dislike writing shell scripts, because it takes too much time from them, scripts does not work as expected, because shell 'is so dumb and it's impossible to write complex things in it'.

I wish to prove, that that's wrong and it's possible to learn shell programming very quick – in 7-10 days.
Thus I'm starting an online training for all Unix novices.

I've collected some questions which novices give about unix shell and categorized them. So let's go on and see, what usually makes difficulties for most of unix shell starters:

1.Misunderstanding now shell does command line expansion, how command arguments are processed and substituted in correct places. In fact shell does not do any magic when it executes command. It just replaces all things to be substituted (variables, command substitution, file patterns) and then executes resulting command.

2.Misunderstanding about how variable expansion works – why does it eat spaces some time, some time does not work at all and etc.

3.Novices practically do not use backtricks to do command substitution, which can be very powerful tool in their hands.

4.Some misconcepts about how input and output redirection works (<, >, >>). Usually novices do not ever heard of here-in documents(<<), which can make your shell scripts much more beatiful and compact.

5.Novices experience fear or difficulties with building long shell pipes (|). Usually you can write very long shell pipe, taking up several lines, which process data or texts and provide exactly that result, what you need.

6.Sed and awk – when I was learning unix, they kept me in awe, because it was too messy and difficult to understand how sed and awk programs work. After some time learning them, I finally got that it's quite easy – but manual pages wrote in a difficult way. It's better to learn sed and awk by examples – which makes learning much more easier, that reading man page.

7.Some great misunderstanding is tied with test command ([ ]), because most of the novices believe, that it is some 'magical' shell command, which is interpreted by the shell itself when used in if/while operators. Usually you can do a lot of funny tricks with it, it you understand how it works.

8.Most of the people experience difficulties with using xargs command in their scripts and command pipes. In fact xargs is very powerful tool too and it should be learned and actively used, when it's necessary – usually when you process huge amounts of data.

9.while operator may be used in a tricky way to parse input data and process them.

If you are really interested in improving your shell programming skills, you are welcome to join my free online training on unix shell programming. It will start 13 or 14 April 2008 and number of places is really limited.

Please see more details and subscribe for the training on the following page bin_sh_en: Online traning on /bin/sh programming

I hope YOU will participate in that training, so GO ON and SUBSCRIBE NOW, while it's free.

With best regards,
Gaspar Chilingarov

[i92guboj]

All of this -except for the awk and sed parts- can be easily solved by reading the bash man page.

So I add the 10th fault, that's also the most important one: people often forget to read man pages.

[gasparch]

All of this -except for the awk and sed parts- can be easily solved by reading the bash man page.

So I add the 10th fault, that's also the most important one: people often forget to read man pages.

Well, even saying someone , that they should read man page makes people really sad It's easier to show them one or two times - which is fater and more effective way of education. At least I think so.

[valan]

The most overlooked shell scripting mistake I've seen is which interpreter is linked to on the first line. Here's the rule:
DO NOT link to /bin/sh if you use bash specific features. If you decide to link to /bin/sh, test it with a posix shell, not with a bash shell.
By standard, /bin/sh is a posix compliant shell and nothing more. Trying to shove bash stuff at it could cause problems. Not really much of a problem on most Linuxes where /bin/sh is actually /bin/bash, but when you get to more specialized distros and other Unices where /bin/sh is not /bin/bash, it can cause some hard to figure out problems. I've seen a box that wouldn't boot because of this. That took awhile to fix because /bin/sh had to be a posix shell in this case, and there were many scripts wrote to /bin/sh using bash features.