...making Linux just a little more fun!
[ In reference to "Easy Shell Scripting" in LG#133 ]
s. keeling [keeling at spots.ab.ca]
Sat, 2 Dec 2006 16:18:43 -0700
Having suffered through Ben's many yammerings in TAG about nonportable
shell features, hey Ben, I found another!
-------------------------------------------------
Comments in a Shell
In shell scripting, all lines beginning with # are comments.
# This is a comment line.
# This is another comment line.
You can also have comments that span multiple lines by using a colon and single quotes:
:' This is a comment line.
Again, this is a comment line.
My God, this is yet another comment line.'
-------------------------------------------------
-------------------------------------------------
#!/usr/bin/zsh
#
:' Good grief. After all this time, I learn that a colon
followed by a single tick produces a block comment in
*nix shel.
That even includes blank lines!
'
# usage:
#
# calc '2 + 7'
#
function calc ()
{
awk 'BEGIN { OFMT="%f"; print '"$*"'; exit}'
}
# not necessary.
# export -f calc
# from linuxgazette.net Dec2006
#
function putargs () {
IFS="|";
echo "$*";
}
-------------------------------------------------
(0) heretic /home/keeling/procmail/ocelot_ source ~/.funcs
/home/keeling/.funcs:9: command not found: : Good grief. \
After all this time, I learn that a colon\n followed \
by a single tick produces a block comment in\n *nix \
shel.\n\n That even includes blank lines!\n
[long line manually broken]
-- Any technology distinguishable from magic is insufficiently advanced. (*) https://www.spots.ab.ca/~keeling - -
Thomas Adam [thomas.adam22 at gmail.com]
Sat, 2 Dec 2006 23:32:00 +0000
On Sat, Dec 02, 2006 at 04:18:43PM -0700, s. keeling wrote:
> :' Good grief. After all this time, I learn that a colon > followed by a single tick produces a block comment in > *nix shel.
That's misleasing -- a cute trick, if you will. The same goes for:
:" random crap blah "
The fact of the matter is that ':' has no effect at shells apart from expansion and redirection where possible.
-- Thomas Adam
-- "Wanting to feel; to know what is real. Living is a lie." -- Purpoise Song, by The Monkees.
Francis Daly [francis at daoine.org]
Sun, 3 Dec 2006 00:24:02 +0000
On Sat, Dec 02, 2006 at 11:32:00PM +0000, Thomas Adam wrote:
> On Sat, Dec 02, 2006 at 04:18:43PM -0700, s. keeling wrote: > > :' Good grief. After all this time, I learn that a colon > > followed by a single tick produces a block comment in > > *nix shel. > > That's misleasing -- a cute trick, if you will.
It's a cute trick, but doesn't seem to work as desired as described, when using my shells. Shell argument splitting matters...
> The same goes for: > > `` > :" random crap > blah > " > > The fact of the matter is that ':' has no effect at shells apart from > expansion and redirection where possible.
:is a builtin, an alias for true.
So
:'here we go'gives "command not found" (unless ":here we go" is in $PATH, or aliased, or whatever), but
: 'here we go'is the same as
true 'here we go'or
true --helpwhich ignores arguments and set $? to zero.
(/bin/true is different, of course. That might accept options.)
So the original poster is incorrect that it's non-portable, because it's portably broken everywhere[*]. But if it's fixed to be colon space stuff, then stuff is ignored unless it contains exposed shell-relevant command-terminating characters like ; or & or newline. And that should be portable.
[*] you know what I mean.
It may be worth a quick typofix to the article at https://linuxgazette.net/133/cherian.html, unless someone has a shell in which that syntax does work?
Cheers,
f
-- Francis Daly francis@daoine.org
Francis Daly [francis at daoine.org]
Sun, 3 Dec 2006 00:35:06 +0000
On Sun, Dec 03, 2006 at 12:24:02AM +0000, Francis Daly wrote:
> On Sat, Dec 02, 2006 at 11:32:00PM +0000, Thomas Adam wrote:
> > The fact of the matter is that ':' has no effect at shells apart from > > expansion and redirection where possible. > > : > > is a builtin, an alias for true.
> But if it's fixed to be colon space > stuff, then stuff is ignored unless it contains exposed shell-relevant
I should have stopped there
> command-terminating characters like ; or & or newline.
...or redirections or any shell metacharacters.
Not contradicting Thomas.
[The shell does its normal command-and-arguments-and-filehandle stuff. If the command turns out to be ":", that command ignores its arguments.]
f
-- Francis Daly francis@daoine.org
Benjamin A. Okopnik [ben at linuxgazette.net]
Sun, 3 Dec 2006 00:04:10 -0500
On Sun, Dec 03, 2006 at 12:35:06AM +0000, Francis Daly wrote:
> On Sun, Dec 03, 2006 at 12:24:02AM +0000, Francis Daly wrote: > > On Sat, Dec 02, 2006 at 11:32:00PM +0000, Thomas Adam wrote: > > > > The fact of the matter is that ':' has no effect at shells apart from > > > expansion and redirection where possible. > > > > : > > > > is a builtin, an alias for true. > > > But if it's fixed to be colon space > > stuff, then stuff is ignored unless it contains exposed shell-relevant > > I should have stopped there> > > command-terminating characters like ; or & or newline. > > ...or redirections or any shell metacharacters.
I'll get that bit - thanks for pointing it out.
Cherian's article has caused me to reevaluate just what I will and won't accept in terms of article quality. In the past, I just went ahead and fixed broken articles like this one, even if it took hours and hours of work. This time, however, at least three people other than me put their time and effort into that thing - and I still ended up with at least two hours rewriting it - and it still came out broken. Honestly, I was so damn tired when publication time came around (between driving 700+ miles to teach a class, teaching that entire week, spending my evenings driving - sometimes well over a hundred miles - to visit friends and relatives in the area, and negotiating with a new client on top of all that), that I just plain missed all that stuff. Mind you, I'd already fixed a huge bunch of errors - and I suspect that Steve Brown, and maybe other people as well, had fixed a few things also. We've just come back from DC - I drove all the way home - and I'm wiped out again. There's a bunch of other stuff that needs to be fixed, as well... but that's probably not going to happen 'till tomorrow.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
s. keeling [keeling at spots.ab.ca]
Sun, 3 Dec 2006 10:18:14 -0700
Incoming from Francis Daly:
> On Sat, Dec 02, 2006 at 11:32:00PM +0000, Thomas Adam wrote: > > On Sat, Dec 02, 2006 at 04:18:43PM -0700, s. keeling wrote: > > > :' Good grief. After all this time, I learn that a colon > > > followed by a single tick produces a block comment in > > > *nix shel. > [lotsa snippage ...] > : is a builtin, an alias for true. > > So > > :'here we go' > > gives "command not found" (unless ":here we go" is in $PATH, or aliased, > or whatever), but > > : 'here we go' > > So the original poster is incorrect that it's non-portable, because > it's portably broken everywhere[*]. But if it's fixed to be colon space > stuff, then stuff is ignored unless it contains exposed shell-relevant > command-terminating characters like ; or & or newline. And that should > be portable.
Best of all, ": '" does appear to fill my original bill because it does produce a multi-line block comment, including blank lines. At least it does in zsh.
-- Any technology distinguishable from magic is insufficiently advanced. (*) https://www.spots.ab.ca/~keeling - -
Francis Daly [francis at daoine.org]
Sun, 3 Dec 2006 01:21:21 +0000
On Sat, Dec 02, 2006 at 04:18:43PM -0700, s. keeling wrote:
Hi there,
> Having suffered through Ben's many yammerings in TAG about nonportable > shell features, hey Ben, I found another!
[This is probably not worth a TAG-mail, but I reckon some extra editing might be in order, so I'll send it here.]
While I'm at it, it would probably be worth re-checking the shell fragments in the article. They may be just transcription errors, but not all of the examples work as-is.
"Step 2" says "/bin/bash". bash scripting is good, but it's not the same as /bin/sh scripting. If you're going to use sh in the shebang, you should probably limit yourself to posix features. So using /bin/bash everywhere in the article may be wise, because...
function is a many-shell-ism, but not a /bin/sh-ism. Lose that word, and it should work everywhere.
Ditto for ((initialization; condition; increment/decrement)), but I'm not aware of a posix replacement off hand.
The "spaces around the square brackets for test" was explained in the "if" section, but they are missing in the "while" section, leading to breakage.
This "select/case" works in bash and ksh, but as written fails my zsh and is unknown to my dash.
So: s%#!/bin/sh%#/bin/bash%, and check for incorrect significant whitespace, and the examples should all be good.
Yes, I do have on my home machine:
$ ls -l /bin/sh lrwxrwxrwx 1 root root 4 2005-12-03 17:09 /bin/sh -> dashSometimes it comes in handy
Cheers,
f
-- Francis Daly francis@daoine.org
Benjamin A. Okopnik [ben at linuxgazette.net]
Sun, 3 Dec 2006 10:07:58 -0500
On Sat, Dec 02, 2006 at 04:18:43PM -0700, s. keeling wrote:
> Having suffered through Ben's many yammerings in TAG about nonportable > shell features, hey Ben, I found another!
Oh, good. Go take another look at that article - where were they, again?
I've fixed whatever I could find (and Francis sent me a good, detailed rundown of everything he found, which was very helpful). Feel free to ping again if you find anything else.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *