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

[Greg Wooledge]

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.