Hi,

I'm using bash and ksh93 compatible derivatives.

In a recent getopts experience, I found myself spending far too much
time on this little problem. I hope someone can help...

So here's the deal.

I want to build have a command line interface that accepts either zero,
one, or many parameters of the same type. Assume the script sends
e-mails to a recipient list. I tried to write the code to handle this, but it
did not work:

commandname -r "user1@tld user2@tld user3@tld"

This did not work because the getopts seemed to parse strings using
space as delimiter regardless of the existence of the surrounding double
or single quotes. This resulted in OPTARGS containing only the first
element of the list. (e.g. user1@tld)

So, I changed the UI to be such that any number (0, 1, or more) of the
-r options can be on the command line.

commandname -r user1@tld -r user2@tld -r user3@tld

Now, my getopts loop has this form:

It successfully grabs every single occurrence of the -r option from the
command line. I created the variable, STRING_LIST, to "accumulate" the
strings.

Is there a better way to do this style of zero, one, or more options of
the same type?

Is there a better way to build a list that does not create anomalies such
as a space character at the beginning or end. (My example above has a
single space character as the 1st character of STRING_LIST, due to fact
it is an empty variable the first time it is referenced on the RHS of
the = sign.)

#####

BTW, I am unable change tools or languages so if you want to suggest
that I use Perl or Ruby or even Java, then please include a example code
(for others to see) otherwise why bother acting like a smarty pants if
you can't display a nice example?

With Bash v2 and v3 I get:
Since quoted inconsistently parts of "-b" and "-c" is completely gone from the output.

Hmmm... I wonder what I was doing incorrectly, then?
I will investigate again and get back to this thread.

Thank you!

PS: thx for the nifty way to test options too!

I found my bug. I was mucking up command line data before getopts
even had a chance to get a whack at it! Do'h! <Sheepishly> It was
caused by something I was not showing. Ugh.

My "main" was calling a function "process_command_line()" where this
getopts work was being performed. I was calling it this way:

process_command_line $@

I really thought I was doing it correctly by using $@ instead of $*.
Though, not entirely. Evidently, that variable needs to be double quoted,
to get the expected behavior. Like this:

process_command_line "$@"

I wonder why that is? What was I breaking?

Thanks for the feedback! I'm glad I got straightened out now so that I
could avoid writing additional (and unnecessary) code to work around
my bug.

Hmmm... This makes me wonder if %SOME_LARGE_PERCENTAGE% of
the existing code base in the world is a workaround for what the
programmer did not understand.

Cheers

The easiest way is make one function "old" style, one "new" style, 'set -vx', then compare output.


I don't know the answer to that, but one example I can think of was KDE vs QT. In the past the KDE team did a lot of odd tweakage instead of using QT to its fullest. That changed though. Even if a programmer understands it all there's bound to be hundreds of ways to do something "better" (more efficient, more performant). Wrt scripting reading static guides like the ABS (again), reading fora like these and other peoples scripts helps, the rest is experimenting and "just" gaining experience. And as F/OSS shows, if things can be improved they will be.