| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
If we find a partial option name match, we need to keep looking for
ambiguous/conflicting options. However, we need to remember the position
in the candidate argument to find its option-argument later, if there is
one. This fixes e.g. option "foobar" being given as "--fooba=baz".
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
getopt is only specified to modify optopt on error, and some software
apparently infers an error from optopt!=0.
getopt_long is changed analogously. the resulting behavior differs
slightly from the behavior of the GNU implementation of getopt_long,
which keeps an internal shadow copy of optopt and copies it to the
public one on return, but since the GNU implementation also exhibits
this shadow-copy behavior for plain getopt where is is non-conforming,
I think this can reasonably be considered a bug rather than an
intentional behavior that merits mimicing.
|
| | |
|
| |
|
|
|
|
|
| |
as a result of commit e8e4e56a8ce1f3d7e4a027ff5478f2f8ea70c46b,
the later code path for setting optarg to a null pointer is no longer
necessary, and removing it eliminates an indention level and arguably
makes the code more readable.
|
| |
|
|
|
|
|
|
|
|
|
| |
the standard getopt does not touch optarg unless processing an option
with an argument. however, programs using the GNU getopt API, which we
attempt to provide in getopt_long, expect optarg to be a null pointer
after processing an option without an argument.
before argument permutation support was added, such programs typically
detected its absence and used their own replacement getopt_long,
masking the discrepency in behavior.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit b72cd07f176b876aa51864d93aa8101477b1d732 added support for a
this feature in getopt, but it was later broken in the case where
getopt_long is used as a side effect of the changes made in commit
91184c4f16b143107fa9935edebe5d2b20bd70d8, which prevented the
underlying getopt call from seeing the leading '-' or '+' character in
optstring.
this commit changes the logic in the getopt_long core to check for a
leading colon, possibly after the leading '-' or '+', without
depending on the latter having been skipped by the caller. a minor
incorrectness in the return value for one error condition in
getopt_long is also fixed when opterr has been set to zero but
optstring has no leading ':'.
|
| |
|
|
|
|
| |
this is undocumented but possibly expected behavior of GNU
getopt_long, and useful when error message printing has been
suppressed.
|
| |
|
|
|
| |
some related changes are also made to getopt, and the return value of
getopt_long in the case of missing arguments is fixed.
|
| | |
|
| |
|
|
|
|
| |
if argv permutation is used, the option terminator "--" should be
moved before any skipped non-option arguments rather than being left
in the argv tail where the caller will see and interpret it.
|
| |
|
|
|
| |
this is an undocumented feature of GNU getopt_long that the BSD
version also mimics, and is reportedly needed by some programs.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
this is a GNU extension, activated by including '-' as the first
character of the options string, whereby non-option arguments are
processed as if they were arguments to an option character '\1' rather
than ending option processing.
|
| |
|
|
|
|
|
| |
based on proposed patches by Daniel Cegiełka, with minor changes:
- use a weak symbol for optreset so it doesn't clash with namespace
- also reset optpos (position in multi-option arg like -lR)
- also make getopt_long support reset
|
|
|
previously, it was pretty much random which one of these trees a given
function appeared in. they have now been organized into:
src/linux: non-POSIX linux syscalls (possibly shard with other nixen)
src/legacy: various obsolete/legacy functions, mostly wrappers
src/misc: still mostly uncategorized; some misc POSIX, some nonstd
src/crypt: crypt hash functions
further cleanup will be done later.
|
