[sf-lug] Fwd: [UMALUG] bash scripting question
jim at well.com
Fri Mar 7 17:15:18 PST 2008
i've always viewed the : command as a no op
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
> 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, but I'll also mention again that the <(list)
>>> construct isn't POSIX/SUS standards compliant. One may be
>>> 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:
> On the other hand, none of the -v, -e, or -t options are truly
> 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
More information about the sf-lug