> 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
Hi,
I have the following problem:
(Environment or regular) variable FOO contains the path of existing directory
"/foo". When I have a file "/foo/bar" in that directory and when I press TAB
in the following commandline ('|' denoting the cursor position)
$ cat $FOO/b|
bash expands the comman
