robert@rabbit1.UUCP (02/17/87)
Don't know if anyone's brought this up before, but the getopt command seems to
have a bit of a problem. It doesn't "re-quote" arguments, so they get broken
up incorrectly when parsed by the shell.
Example: getopt x: -x "a test"
produces: -x a test --
instead of: -x "a test" --
Resulting in: Instead of:
$1=-x $1=-x
$2=a $2=a test
$3=test $3=--
$4=--
Even "sh" itself recognizes this problem, and provides re-quoting via "$@" .
Since writing one's own getopt program is trivial on a system with the getopt
call, this is more of a major annoyance than a problem. So, my questions:
1) Any portable workarounds (I can't think of any)?
2) Have any of the standards groups thought of proposing that this be fixed?
--
Robert Oliver
Rabbit Software Corp. (215) 647-0440
7 Great Valley Parkway East ...!ihnp4!{cbmvax,cuuxb}!hutch!robert
Malvern, PA 19355 ...!psuvax!burdvax!hutch!robertgwyn@brl-smoke.UUCP (02/18/87)
In article <274@rabbit1.UUCP> robert@rabbit1.UUCP (Robert L. Oliver) writes: >... the getopt command seems to have a bit of a problem. >It doesn't "re-quote" arguments, so they get broken up incorrectly >when parsed by the shell. Yes, the "getopt" utility cannot be made to work right in Bourne shell scripts. That is why it has been replaced with a "getopts" shell built-in in SVR3. IEEE 1003.2 expects to adopt "getopts", not "getopt" (assuming I get the shell specification written in time).