bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: converting array to string by quoting each element for eval


From: Peng Yu
Subject: Re: converting array to string by quoting each element for eval
Date: Wed, 16 Nov 2011 08:05:03 -0600

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 <address@hidden>


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]