Hi Greg,
> **NEVER** use getopt(1). It is broken. It cannot be made to work
> correctly. Its entire design is flawed.
I don't see these warnings in my systems (macports and ubuntu) (This
is version of getopt on macports and ubuntu is free, I don't see there
is a reason that getopt can not be ported to the two systems that you
mentioned). All I see that is relevant is the following. I don't think
that just because that it has a BUGS section in the manpage, it can be
called broken. man bash also has BUGS section, is bash considered as
broken?
BUGS
getopt(3) can parse long options with optional arguments that
are given an empty optional argument (but can not do this for short
options). This getopt(1) treats
optional arguments that are empty as if they were not present.
The syntax if you do not want any short option variables at all
is not very intuitive (you have to set them explicitely to the empty
string).
AUTHOR
Frodo Looijaard <fr...@frodo.looijaard.name>
Note that it doesn't mean that I am resistant to getopts. It is just
that I don't think that your logic is valid. But I will read more
about getopts to see if it is necessary to convert from getopt to
getopts.
> ./myscript . -type f -name '*'
To support your claim, tell me what myscript would be if the commands
./myscript 'a b' 'c d' -type f -name '*"
./myscript 'a b' -type f -name '*"
actually do
find 'a b' 'a d' -maxdepth 1 -type f -name '*"
find 'a b' -maxdepth 1 -type f -name '*"
--
Regards,
Peng
