JD Gray wrote: > I'm running the below script on my gentoo servers to email me whenever > there are GLSA's affecting me. It works like a charm, but I have one > beef with it. Newlines are not preserved, so I get a lovely Wall Of > Text (tm) when ever it sends me the GLSA. I'm guessing this is because > of the way bash handles variables. Anyone have any insight on how to > correct this? > > #!/bin/bash > > /usr/bin/glsa-check -t all &> /dev/null > CHECK_RESULT="`/usr/bin/glsa-check -t all 2>&1`" > > if [ "$CHECK_RESULT" != "" ]; then > echo $CHECK_RESULT | /bin/mail -s "Frog glsa-check" [EMAIL PROTECTED]; > fi > Simply quote the variable you are echo'ing: echo "$CHECK_RESULT" What's happening here is called "word-splitting"; bash is sending each part of the string as a separate parameter to echo. See: http://www.bash-hackers.org/wiki/doku.php/syntax/words for more.
The best explanation I've seen for why this happens (the one that helps beginners ime) is: "At its base, a shell is simply a macro processor that executes commands. The term macro processor means functionality where text and symbols are expanded to create larger expressions." ..from the bash reference manual: http://tiswww.tis.case.edu/~chet/bash/bashref.html which I don't recommend as a beginning read :) but is definitely worth bookmarking. http://www.grymoire.com/Unix/Quote.html shows how to deal with quoting in various situations; make sure you understand the difference between strong (single) quotes and weak (double) quotes. For instance, "Frog glsa-check" doesn't need double-quotes and single-quotes are a bit faster to parse and evaluate (why lose /any/ speed when you don't need to?) Strong quotes can also be really useful for stuff echo'ed to the terminal, eg a help message where you need to include some script the user might look at or use. update[1] does this for the various help options. I've also heard that mutt is a very useful utility if you need to send mail from shellscripts; I haven't worked with it but aiui it makes it easy to add attachments and so on. BTW you can simply use: if [[ $foo ]] to do the check; see ''help test'' in your terminal; -n is the default, and no word-splitting happens inside [[ so quotes are not needed, which is one of the things that makes it much more convenient. http://wooledge.org/mywiki/BashGuide is the best tutorial I've seen on the web; it's written and maintained by people from #bash on irc.freenode.net which is an invaluable resource, if a little rude sometimes ;) The bash hackers wiki mentioned, is also a good place to learn: http://www.bash-hackers.org/wiki/ The FAQ: http://wooledge.org/mywiki/BashFaq is legendary, and this: http://wooledge.org/mywiki/BashPitfalls is worth reviewing, especially once you've got the basics. Minor style point: varnames in caps are usually reserved for environment vars, or constants; within ebuilds they're also used for standard config things, or variables that cross functions or phases. Oh, one other thing: backticks are deprecated, and $(..) is much preferred, eg: foo=$(cmd 'some param' "$blah" 2>"$errFile") since it's easier to nest and maintain. This is true for POSIX sh as well as BASH; see: http://www.opengroup.org/onlinepubs/009695399/utilities/contents.html ..for the definitive reference on portability. Sticking to the parameters given there for commands (aka utilities), will do wonders for the portability of your BASH scripts. HTH, steveL (I _love_ BASH, can you tell? ;) [1] http://forums.gentoo.org/viewtopic-t-546828.html | You might like update -A which does the glsa-check for you. I'd love feedback from -server users; update -x is an automated mode which logs to the syslog, designed for use under cron. (It's called server in the code.)
