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

[jim stockford]

    i've always viewed the  :  command as a no op
(aka nop).
    even after reading and pondering, i cannot figure
out a use other than perhaps as a placeholder, but
a comment seems a much more useful placeholder.

    what is a good reason for putting the  :  command
in a shell script?



On Mar 7, 2008, at 7:16 AM, Michael Paoli wrote:

> 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.
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>