[sf-lug] Fwd: [UMALUG] bash scripting question

[Michael Paoli]

Quoting Kristian Erik Hermansen <kristian.hermansen at gmail.com>:

> OK, let's get picky...
> On Tue, Mar 4, 2008 at 10:27 PM, Michael Paoli
> <Michael.Paoli at cal.berkeley.edu> wrote:
> >  of : would also make that first line a comment).  With execute
> Is the : comment feature compliant and able to be utilized in any shell?

Well, if we get picky ... :-) then no, because you have the logical AND
conjunction of *compliant* AND *any shell*, which is false, before we
even add additional constraints.  Since essentially anyone that can
write or put together a shell can make it as non-compliant as they may
wish, and have : do whatever they want or nothing at all, one doesn't
have much of a guarantee when it comes to "any shell".

But more practically, most any reasonably standards compliant
Bourne/Korn/pdksh/bash/ash/POSIX/SUS/etc. flavor of shell will handle :
quite consistently.

The : command is actually a slight bit more than "just" a comment.  
It's a built-in command that returns true (0).  Much more concise than 
true, /bin/true or /usr/bin/true, and no need to run a command external
to the shell.  So, at least in some regards (e.g. ignoring its
arguments) it can, and I believe once upon a time in history, was used
as a comment character.  Note however, that : won't shield everything
from the shell - : is basically a command that does nothing and returns
true, so command and variable substitution, etc., will still occur (so
it probably makes a relatively poor "comment" character in most
non-ancient contexts).

> >  I mentioned before[1], but I'll also mention again that the <(list)
> >  construct isn't POSIX/SUS[2][3] standards compliant.  One may be well
> >  advised to generally code to the broadest applicable standards as
> >  feasible, to avoid issues with portability and other potentially
> >  unpleasant surprises and "gotchas".
>
> What is an good alternative to opening up those nice file handles that
> is compliant?  It i a nifty little feature, but then again, so is
> /dev/tcp/80 or whatever that crap syntax is that is utterly confusing
> (there is no device like that, but bash has this "feature" to somehow
> interpret this as a raw port connect)...

You weren't expecting a shell to do everything for you now, were you?  
;-)  There are many ways to do relatively similar things, but it will
typically take a few lines or so of coding, to do it in a reasonably
standards conformant and portable way.  E.g. one can set relevant
trap(s) for signal handling, securely create a temporary named pipe, 
start that other command and redirect its output to the named pipe and 
background that command, then use the temporary named pipe as argument
in the desired command, and afterwards, clean up: remove the temporary
named pipe, and perhaps terminate the program that has it open for
writing if that program hasn't already exited, and readjust signal
handling (trap(s)) appropriately.  In many cases, other alternative
approaches are used - e.g. shove the output into a named parameter
(shell variable) - that avoids all the hassle of having to explicitlyy
deal with temporary file(s) (named pipe(s)) in one's script.  Use of a
here-document is also often employed - one can also use parameter
(and/or command) substitution in a here-document ... and by using a
here-document, the shell automagically handles any temporary resources  
that may be needed to deal with that.

> >  cat -vet /proc/$$/cmdline; echo ''
> -v is already implied by both -e and -t ;)  And the '' argument to
> echo seems unnecessary, as echo without any arguments produces the
> same effect...
Depends upon one's cat(1).  Using cat -vet will give more consistent 
results than relying upon the behavior you name, which may be specific
to GNU cat. E.g. have a look at:
http://docs.sun.com/app/docs/doc/801-6680-01/6i11qc09n?a=view
http://docs.sun.com/app/docs/doc/816-5165/cat-1?a=view
On the other hand, none of the -v, -e, or -t options are truly standards
compliant:
http://www.opengroup.org/onlinepubs/000095399/utilities/cat.html  
If I recall correctly, I think the -v, -e, and -t options first   
appeared in System V UNIX, perhaps roughly around 1989 +- a year or
two;  I'm not sure when those options appeared in GNU cat ... may have
been earlier, or later, and it's quite possible they never behaved
precisely the same way.

For better and/or worse, GNU has often implemented things a bit
differently than historical UNIX and/or the applicable standards (e.g.  
POSIX & SUS).

And yes, echo '' is a bit more verbose than necessary, where a mere
echo would suffice.  It could be argued that the explicit null argument
might make the code a bit more readable ... or it could be argued it's
less efficient and a waste of a few bytes.