barratt@DASH.MITRE.ORG (Jeff Barratt) (01/06/90)
Brian,
With regard to John Ramsdell's question about parameter
expansion: The syntax
${param:?[value]}
is supposed to substitute "param" if it is not null, otherwise it
should write "value" to stderr. If value is omitted, then sh writes
param: parameter null or not set
This is paraphrased from UNIX Shell Programming, by Kochan and Wood.
As you can see from the transcript below, sh will also accept
${param?[val]} (e.g. without the internal ":"). sh only writes the
"value" string if the variable "param" is not set. If the variable is
set, sh attempts to execute the contents of param as a command.
Script started on Fri Jan 5 14:41:09 1990
bash$ sh
$ set
ARCH=sun3
BASH=/bin/sh
..
..many other variables...
..
$ echo $abc
$ ${abc?}
abc: parameter null or not set
$ ${abc:?}
abc: parameter null or not set
$ ${abc?"What a crock"}
abc: What a crock
$ ${abc?ls}
abc: ls
$ abc=
$ ${abc?}
$ ${abc?ls}
$ abc=zip
$ ${abc:?}
zip: not found
$ ${abc:?"What a crock, II"}
zip: not found
$ : ${abc:?}
$ : ${abc:?"What now?"}
$ exit
script done on Fri Jan 5 14:43:23 1990
Bash, on the other hand, doesn't seem to handle this. If abc is not
set, the syntax
${abc:?}
will exit the shell, and
${abc:?"Help"} will echo Help and *then* exit the shell. In
neither case should bash exit the current shell. If abc=ls, then bash
behaves correctly, e.g. executes ls, and remains in the current shell.
I verified this behavior in both 1.03 and 1.04 on a Sun-3 running
SunOS 4.0.3
Thanks,
Jeff Barrattchet@cwns1.CWRU.EDU (Chet Ramey) (01/09/90)
In article <9001052019.AA01516@dash.mitre.org> barratt@dash.mitre.org writes: >Brian, > With regard to John Ramsdell's question about parameter >expansion: The syntax > ${param:?[value]} >is supposed to substitute "param" if it is not null, otherwise it >should write "value" to stderr. If value is omitted, then sh writes > param: parameter null or not set It does this when the shell is interactive. When the shell is not interactive, it exits. The POSIX spec said nothing about interactive vs non-interactive behavior (neither does the sh man page, as a matter of fact), so Brian just exited the shell after a bad substitution like that. I `fixed' it to mimic the sh behavior (`do what I do, not what I say'), and that's the code Brian is running now. This is the full description from the System V sh manual: ${parameter:?word} "If `parameter' is set and is non-null, substitute its value; otherwise, print `word' and exit from the shell. If `word' is omitted, the message `parameter null or not set' is printed." Chet Ramey -- Chet Ramey Network Services Group "Help! Help! I'm being Case Western Reserve University repressed!" chet@ins.CWRU.Edu
barratt@DASH.MITRE.ORG (Jeff Barratt) (01/11/90)
Thanks for the clarification, Chet. In fact, the book I mentioned, "UNIX Shell Programming" by Kochan and Wood, does mention that sh won't exit a "login shell". I don't have the system V documentation. The problem was only noticed because I was trying to understand the syntax of the parameter expansions interactively---I don't know whether the sh behavior has any practical virtue, other than maybe the general principle that interactive shells should only exit if asked to. So, I guess that I agree with fixing bash to emulate sh in this case. Jeff Barratt ---------------------- barratt@dash.mitre.org I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered. - The Prisoner