Bits BASHing Through Scripts

http://www.bit-tech.net/bits/2007/11/26/bashing_through_scripts/1

Our resident Linux guru Ken Gypen is back to teach you a thing or three about one of the most nebulous but powerful features of 'Nix - using scripts to automate common tasks. So jump in and get ready to learn the basics, then write your own image resize and watermark script.



Digg for Win: http://digg.com/linux_unix/BASHing_Through_Scripts

 

small typo:
by issuing ((i++))

on page 2, should be ((n++)) like the example.

Also telling people how to run the scripts on page 2 would be better then waiting untill page 4.

But a good basic guide to BASH/

 

nicely done, didnt relise vim had colour support, is it by default and multiple languages? if so another incentive to learn how to use it (no more jext and its minute long starts). one slight error thou BASHWatermark.png cannot be found on the server

 

On most distro's VIm has automatic syntax highlighting for about every language that exists (or multiple together, like PHP/HTML). If you however find an exotic language that doesn't have highlighting, it's easy to create your own.

If for some reason your VIm doesn't highlight, try typing:

Code:

:syntax enable

 

I'm trying to fix this with Jamie now - the image is uploaded... just not working somehow

 

Are the userrights set correctly?

 

This is fixed now

 

A few remarks:

* You don't need to install Linux to get the benefits of Unix scripting - I for one run Cygwin on all my Windows desktops, and have written my own equivalent bash/ImageMagick scripts, amongst many others.

* Be careful when working with variables in bash scripts, in particular watch out for quoting. Writing ${i} is no different from writing $i, and provides no extra quoting. Use "$i" etc. in case the file names you're working with have spaces or other characters that need escaping. The braces syntax is useful for bash's special variable features, such as array variables and indexing (e.g. ${i[1]}), replacement (e.g. ${i/foo/bar}), etc.

* Backticks ` are fine for simple scenarios, but if you are in a situation where you may want to nest command execution, and to provide better visibility into nesting, you might want to use the $() syntax instead. Also, be careful with quoting here too. To get the result as a single word, you need to put quotes outside the backtick syntax.

* For numeric statements (rather than expressions) such as increment, I personally use the 'let' command, rather than (()) on a single line; for looping in the C style, I use "for ((i=0; i<10; ++i)); do done"; and for numeric tests in if / while / etc., I use (()) rather than the [ command.

 

awesome points, barrkel - thanks for those additions!

 

Although writing BASH scripts is much more portable than anything else, if this is only for your home server - remember that PHP can be installed as an executable binary, as well as an apache module. So if you can understand a C/PHP syntax better - it might make your life a little easier.

Equally, if you put the same scripts into a web folder with remote access - it means you could start scripts manually over the web - very useful when a firewall/proxy doesn't allow you to use SSH. Be careful about security in those cases though (especially if you allow access outside of the site root), and remember that you will probably need to increase the execution time of PHP for anything that will take over 30 seconds.

 

Love it when im mentioned in a front page article

 

I work as an editor too - for largest IT server in Slovakia
BASH scripting is very powerful, but those simple scripts mentioned in article work well only if your photos are perfect.

I, for example, have to do cropping manually and then i can let scripts do resizing and watermarking. If my photos were perfect - no need for cropping or levels changing - i would use scripts only.

In fact, in Photoshop there is automatic function for cropping, but mostly, it works with white background only - so it is not very useful 4 me.

Anyway, great article ))

 

Thanks for the great article... now if i could stop poking around in my slackware box and killing i tin the process

 

Why didn't you mention elseif at all?

Other then that, good simple guide

p.s.
can you get syntax highlighting in putty, never seems to work in ubuntu/debian for me ...

 

Hmm, I could have added that... However, I find it a lot easier to just throw in a case structure instead of 100 elseifs... Personal taste I guess.

If you get highlighting in a physical terminal, it should work in a SSH terminal too... So yes, you should get it in putty.

 

I just found it odd to not mention it at all ....

sometimes you want a few completely different comparisons ... but those situations are rare i guess

If you get highlighting in a physical terminal, it should work in a SSH terminal too... So yes, you should get it in putty.[/QUOTE]
Hmmm ... maybe just because the servers don't have a gui, they are just using some basic shell, meh, ive lived with it for 5 years, it doesn't really bother me - its only useful if your coding something complicated

 

BASH scripting gave me nightmares last semester...

I need to read this article though

 

The real fun starts when you discover the script you've just spent several hours perfecting has to run on a shell that requires strict posix compliance (in my case it was ksh). I found this was the most helpful source of common "bashisms" and solutions when I googled quickly: https://wiki.ubuntu.com/DashAsBinSh

By the time I discovered the requirement of course I had a large number of bash-specifics, mostly to do with `` command substitution and file redirection)

Lessons learned:
* Backticks are awesome, but they'll stab you in the back (no pun intended)
* {command <<< "input"} is an awesome shortcut for sending short text strings to the input of a running program (I needed to send "yes" to a confirmation prompt), but also bash only. {command << EOF \n input \n EOF} at least works, but doesn't do much for readability.
* Very few shells care for attempts to dispose of standard output and error simultaneously {&> /dev/null} or to combine stderr with stdout {2>&1}
* Coding for 80x25 char terminals sucks
* ${#var} returns the length of ${var}. Amazingly that one is posix standard


Some other functions I cooked up that day which people might find useful:
http://qupada.orcon.net.nz/bash.sh

Reading variables - 3 variants, min length, no length constraint, default value (ie blank entry = default)
Just do (for example) {get_var_minlength "foo" "Enter at least 6 characters" 6 "I said at least 6"}. When the user enters enough text at the prompt, ${foo} will be set to their response.

Command-line processing - as the article pointed out, $1 is the first argument to the script (if you're looking for it, $0 is the filename of the script that was run), with the combination of the while loop and the 'shift' command we can process as many arguments as the user gives. With extra 'shift' statements commands of the form {--comand "value"} can be processed too {--command|-c) shift; VAR="$1" ;;}.


I hope someone gets something useful out of that lot.

 

Pfft, my GUI + CLI OS is Emacs.

The article was decent, but I have one request. Instead of this:

Or even just this:

Could you please enclose code-related regions within <code>...</code>? That would make it a lot clearer as well as more readable, and obviate the (eventual) need for "(remove the quotes)".