Commit Graph

24 Commits

Author SHA1 Message Date
Brandon Casey
a6304fa4c2 parse-options: only insert newline in help text if needed
Currently, when parse_options() produces a help message it always emits
a blank line after the usage text to separate it from the options text.
If the option spec does not define any switches, or only defines hidden
switches that will not be displayed, then the help text will end up with
two trailing blank lines instead of one.  Let's defer emitting the blank
line between the usage text and the options text until it is clear that
the options section will not be empty.

Fixes t1502.5, t1502.6.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25 14:35:53 +09:00
Brandon Casey
1a9bf1e176 parse-options: write blank line to correct output stream
When commit 54e6dc7 added translation support to parse-options, an
fprintf was mistakenly replaced by a call to putchar().  Let's use fputc
instead.

Fixes t0040.11, t0040.12, t0040.33, and t1502.8.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25 14:35:52 +09:00
Brandon Casey
c97ee171a6 t0040,t1502: Demonstrate parse_options bugs
When the option spec contains no switches or only hidden switches,
parse_options will emit an extra blank line at the end of help output so
that the help text will end in two blank lines instead of one.

When parse_options produces internal help output after an error has
occurred it will emit blank lines within the usage string to stdout
instead of stderr.

Update t/helper/test-parse-options.c to have a description body in the
usage string to exercise this second bug and mark tests as failing in
t0040.

Add tests to t1502 to demonstrate both of these problems.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-25 14:35:50 +09:00
Brandon Casey
33e75122f4 rev-parse parseopt: interpret any whitespace as start of help text
Currently, rev-parse only interprets a space ' ' character as the
delimiter between the option spec and the help text.  So if a tab
character is placed between the option spec and the help text, it will
be interpreted as part of the long option name or as part of the arg
hint.  If it is interpreted as part of the long option name, then
rev-parse will produce what will be interpreted as multiple arguments
on the command line.

For example, the following option spec (note: there is a <tab> between
"frotz" and "enable"):

    frotz	enable frotzing

will produce the following set expression when --frotz is used:

    set -- --frotz --

instead of this:

    set -- --frotz  enable --

Mark t1502.2 as fixed.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-19 12:13:08 +09:00
Brandon Casey
28a8d0f77a rev-parse parseopt: do not search help text for flag chars
When searching for flag characters in the option spec, we should ensure
the search stays within the bounds of the option spec and does not enter
the help text portion of the spec.  So when we find the boundary white
space marking the start of the help text, let's mark it with a nul
character.  Then when we search for flag characters starting from the
beginning of the string we'll stop at the nul and won't enter the help
text.

Now, the following option spec:

    exclame this does something!

will produce this 'set' expression when --exclame is specified:

    set -- --exclame --

instead of this one:

    set -- --exclame this does something --

Mark t1502.4 and t1502.5 as fixed.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-19 12:13:07 +09:00
Brandon Casey
f221861e49 t1502: demonstrate rev-parse --parseopt option mis-parsing
Since commit 2d893df rev-parse will scan forward from the beginning of
the option string looking for a flag character.  If there are no flag
characters then the scan will spill over into the help text and will
interpret the characters preceding the "flag" as part of the option-spec
i.e. the long option name.

For example, the following option spec:

    exclame this does something!

will produce this 'set' expression when --exclame is specified:

    set -- --exclame this does something --

which will be interpreted as four separate parameters by the shell.  And
will produce a help string that looks like:

    --exclame this does something
                          this does something!

git-rebase.sh has such an option (--autosquash), and so will add extra
parameters to the 'set' expression when --autosquash is used.
git-rebase continues to work correctly though because when it parses the
arguments, it ignores ones that it does not recognize.

Also, rev-parse --parseopt does not currently interpret a tab character
as a delimiter between the option spec and the help text.  If a tab is
used at the end of the option spec, before the help text, and before a
space has been specified, then rev-parse will interpret the tab as part
of the preceding component (either the long name or the arg hint).

For example, the following option spec (note: there is a <tab> between
"frotz" and "enable"):

    frotz	enable frotzing

will produce this 'set' expression when --frotz is specified:

    set -- --frotz  enable --

which will be interpreted as 2 separate arguments by the shell.

git-rebase.sh has one of these too (--keep-empty).  In this case the tab
is immediately followed by spaces so there are no additional parameters
produced on the command line.  The only side-effect is misalignment in
the help text.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-19 12:13:05 +09:00
Ilya Bobyr
2d893dff4c rev-parse --parseopt: allow [*=?!] in argument hints
A line in the input to "rev-parse --parseopt" describes an option by
listing a short and/or long name, optional flags [*=?!], argument hint,
and then whitespace and help string.

We did not allow any of the [*=?!] characters in the argument hints.
The following input

    pair=key=value  equals sign in the hint

used to generate a help line like this:

    --pair=key <value>   equals sign in the hint

and used to expect "pair=key" as the argument name.

That is not very helpful as we generally do not want any of the [*=?!]
characters in the argument names.  But we do want to use at least the
equals sign in the argument hints.

Update the parser to make long argument names stop at the first [*=?!]
character.

Add test case with equals sign in the argument hint and update the test
to perform all the operations in test_expect_success matching the
t/README requirements and allowing commands like

    ./t1502-rev-parse-parseopt.sh --run=1-2

to stop at the test case 2 without any further modification of the test
state area.

Signed-off-by: Ilya Bobyr <ilya.bobyr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-15 10:30:54 -07:00
Junio C Hamano
af465af8de parse-options: detect attempt to add a duplicate short option name
It is easy to overlook an already assigned single-letter option name
and try to use it for a new one.  Help the developer to catch it
before such a mistake escapes the lab.

This retroactively forbids any short option name (which is defined
to be of type "int") outside the ASCII printable range.  We might
want to do one of two things:

 - tighten the type of short_name member to 'char', and further
   update optbug() to protect it against doing "'%c'" on a funny
   value, e.g. negative or above 127.

 - drop the check (even the "duplicate" check) for an option whose
   short_name is either negative or above 255, to allow clever folks
   to take advantage of the fact that such a short_name cannot be
   parsed from the command line and the member can be used to store
   some extra information.

Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-04 11:00:28 -07:00
Junio C Hamano
ce7f8745aa t1502: protect runs of SPs used in the indentation
The expected output from the argument help use runs of SPs to align
the description of each option; a careless use of --whitespace=fix
can turn leading parts of them into appropriate number of HTs.
Prevent such a breakage by prefixing all the expected lines with
leading vertical bars in the original and stripping them with a
small sed script.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-23 17:28:03 -07:00
Ilya Bobyr
9bab5b6061 rev-parse --parseopt: option argument name hints
Built-in commands can specify names for option arguments when usage text
is generated for a command.  sh based commands should be able to do the
same.

Option argument name hint is any text that comes after [*=?!] after the
argument name up to the first whitespace.

Signed-off-by: Ilya Bobyr <ilya.bobyr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-23 17:28:03 -07:00
Nicolas Vigier
f8c872127d rev-parse --parseopt: add the --stuck-long mode
Add the --stuck-long option to output the options in their long form
if available, and with their arguments stuck.

Contrary to the default form (non stuck arguments and short options),
this can be parsed unambiguously when using options with optional
arguments :

 - in the non stuck form, when an option is taking an optional argument
   you cannot know if the next argument is its optional argument, or the
   next option.

 - the long options form allows to differentiate between an empty argument
   '--option=' and an unset argument '--option', which is not possible
   with short options.

Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-31 15:47:41 -07:00
Jiang Xin
9a0013819e Fix tests under GETTEXT_POISON on parseopt
Use the i18n-specific test functions in test scripts for parseopt tests.
This issue was was introduced in v1.7.10.1-488-g54e6d:

    54e6d i18n: parseopt: lookup help and argument translations when showing usage

and been broken under GETTEXT_POISON=YesPlease since.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27 09:26:30 -07:00
Jonathan Nieder
2b5ec01845 t1502 (rev-parse --parseopt): test exit code from "-h"
rev-parse --parseopt exits with code 129 (usage error) when asked
to dump usage with -h on behalf of another command.  Scripts can
take advantage of this to avoid trying to parse usage information
as though it were the regular output from some git command.

Noticed with an &&-chaining tester.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09 15:00:10 -08:00
Junio C Hamano
fcd91f8de2 Merge branch 'maint'
* maint:
  backmerge a few more fixes to 1.7.1.X series
  rev-parse: fix --parse-opt --keep-dashdash --stop-at-non-option
  fix git branch -m in presence of cross devices

Conflicts:
	RelNotes
	builtin/rev-parse.c
2010-07-07 11:18:26 -07:00
Uwe Kleine-König
29981380d0 rev-parse: fix --parse-opt --keep-dashdash --stop-at-non-option
The ?: operator has a lower priority than |, so the implicit associativity
made the 6th argument of parse_options be PARSE_OPT_KEEP_DASHDASH if
keep_dashdash was true discarding PARSE_OPT_STOP_AT_NON_OPTION and
PARSE_OPT_SHELL_EVAL.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-07 11:11:50 -07:00
Thomas Rast
47e9cd28f8 parseopt: wrap rev-parse --parseopt usage for eval consumption
9c7304e (print the usage string on stdout instead of stderr,
2010-05-17) broke rev-parse --parseopt: when run with -h, the usage
notice on stdout ended up in the shell eval.

Wrap the usage in a cat <<\EOF ... EOF block when printing to stdout.
I do not expect any usage lines to ever start with EOF so this
shouldn't be an undue burden.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-13 09:38:14 -07:00
Giuseppe Scrivano
9c7304e3e3 print the usage string on stdout instead of stderr
When -h is used, print usage messages on stdout.  If a command is invoked with
wrong arguments then print the usage messages on stderr.

Signed-off-by: Giuseppe Scrivano <gscrivano@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31 18:06:41 -07:00
Uwe Kleine-König
6e0800ef25 parse-opt: make PARSE_OPT_STOP_AT_NON_OPTION available to git rev-parse
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-13 17:08:37 -07:00
Uwe Kleine-König
824af25ace more tests for git rev-parse --parse-opt
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-13 17:08:21 -07:00
Junio C Hamano
0bd64f82ba Merge branch 'maint'
* maint:
  Extend parse-options test suite
  api-parse-options.txt: Introduce documentation for parse options API
  parse-options.c: fix documentation syntax of optional arguments
  api-builtin.txt: update and fix typo
2008-06-22 18:39:37 -07:00
Michele Ballabio
6422f63321 parse-options.c: fix documentation syntax of optional arguments
When an argument for an option is optional, short options don't need a
space between the option and the argument, and long options need a "=".
Otherwise, arguments are misinterpreted.

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-22 18:14:37 -07:00
Jeff King
44d86e910d avoid whitespace on empty line in automatic usage message
When outputting a usage message with a blank line in the
header, we would output a line with four spaces. Make this
truly a blank line.

This helps us remove trailing whitespace from a test vector.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-14 11:39:16 -07:00
Junio C Hamano
3af828634f tests: do not use implicit "git diff --no-index"
As a general principle, we should not use "git diff" to validate the
results of what git command that is being tested has done.  We would not
know if we are testing the command in question, or locating a bug in the
cute hack of "git diff --no-index".

Rather use test_cmp for that purpose.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 00:01:56 -07:00
Jay Soffian
e103343644 rev-parse: fix potential bus error with --parseopt option spec handling
A non-empty line containing no spaces should be treated by --parseopt as
an option group header, but was causing a bus error. Also added a test
script for rev-parse --parseopt.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-25 21:40:12 -08:00