On Tue, Nov 15, 2011 at 07:46:14PM -0600, Peng Yu wrote:
> No. My real example use getopt.
**NEVER** use getopt(1). It is broken. It cannot be made to work
correctly. Its entire design is flawed.
HP-UX getopt(1) says:
WARNINGS
getopt option arguments must not be null strings nor contain embedded
blanks.
OpenBSD getopt(1) says:
BUGS
...
Arguments containing whitespace or embedded shell metacharacters
generally will not survive intact; this looks easy to fix but isn't.
You may safely use getopts (the builtin). Never getopt.
> If I have each option in a separate
> argument, I need to know all the possible arguments to find, which is
> not a viable route.
*Why* do you "need to know" them? What does that sentence even mean?
Is it because you have some NON-FIND OPTIONS after those? Then why not
use the same trick that find(1) itself uses? Use a sentinel argument
to indicate the end of the find-ish arguments. ';' would be nicely
traditional.
Better still would be to rearrange the invocation so that the arbitrary
number of find-ish arguments are all at the end.
> How to pass the option "-type f -name '*'" correctly?
As four individual arguments, of course!
./myscript . -type f -name '*'
> /tmp$ ./not_convert_args_to_string.sh . "-type f -name '*'"
^^^ NOT THAT.
Please reread everything Chris said to you, because it all looked correct
to me.
If you *truly* need to serialize an array into a string and then retrieve
it back into an array later, there are ways to do this, but you have not
actually demonstrated a reason *why* you would ever need such a thing.
All you've shown so far is a constantly mutating vagueness in which you
keep trolling for some way to come up with a question which will convince
someone to tell you how to do something you shouldn't be doing.
