> You may safely use getopts (the builtin). Never getopt.
If my understanding is correct, 'getopts' doesn't support the long
format. Hence, it does not satisfy my need and I shall not use it.
--
Regards,
Peng
> And that is enough of this nonsense. I have cited three official manuals
> for you already. Let's move on.
I don't get it. Do you mean both traditional getopt and Debian getopt
are broken. To me it seems that Debian getopt is made to address the
short coming of transitional getopt. Yet you sti
On Wed, Nov 16, 2011 at 08:05:03AM -0600, Peng Yu wrote:
> > **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)
Debian getopt(1) says:
Traditional implementation
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 p
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 contai
> Then why don't you post that?
Please take a look and see if you have a better solution than the
following code without using quotearg.sh.
/tmp/tmp$ ll *
c d:
total 0
-rw-r--r-- 1 pengy wheel 0 2011-11-15 20:18:11 xx
a b:
total 0
-rw-r--r-- 1 pengy wheel 0 2011-11-15 20:18:15 yy
/tmp/tmp$ ../c
On Tue, 15 Nov 2011, Peng Yu wrote:
On Tue, Nov 15, 2011 at 6:43 PM, Chris F.A. Johnson
wrote:
On Tue, 15 Nov 2011, Peng Yu wrote:
In any case, combining a command and its arguments in a single
string is almost always the wrong way to go about it.
Please compare the two scripts and s
On Tue, Nov 15, 2011 at 6:43 PM, Chris F.A. Johnson
wrote:
> On Tue, 15 Nov 2011, Peng Yu wrote:
>
>>> In any case, combining a command and its arguments in a single
>>> string is almost always the wrong way to go about it.
>>
>> Please compare the two scripts and see if the second one makes
On Tue, 15 Nov 2011, Peng Yu wrote:
In any case, combining a command and its arguments in a single
string is almost always the wrong way to go about it.
Please compare the two scripts and see if the second one makes more sense.
/tmp$ cat not_convert_args_to_string.sh
#!/bin/bash
option
> In any case, combining a command and its arguments in a single
> string is almost always the wrong way to go about it.
Please compare the two scripts and see if the second one makes more sense.
/tmp$ cat not_convert_args_to_string.sh
#!/bin/bash
options="$2"
find $1 $options
echo find $1
On Tue, 15 Nov 2011, Peng Yu wrote:
Why not use the array instead of making it into a single string?
$cmd "${args[@]}"
Why are you using eval or quotearg.sh? It sounds as if you are
making the process more complicated than it need be.
For the examples that I gave, probably it is not ne
> Why not use the array instead of making it into a single string?
>
> $cmd "${args[@]}"
>
> Why are you using eval or quotearg.sh? It sounds as if you are
> making the process more complicated than it need be.
For the examples that I gave, probably it is not necessary.
I'm yet to make a co
On Tue, 15 Nov 2011, Peng Yu wrote:
Hi,
I find that I have to make a program quotearg.sh to convert an array
to a string by quoting each element. So that it be used for eval.
I'm not sure if there is a way that I can do eval in bash without
having to use quotearg.sh. If there is no such a way,
13 matches
Mail list logo
