summaryrefslogtreecommitdiff
path: root/t/t1502-rev-parse-parseopt.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-09-25parse-options: only insert newline in help text if neededLibravatar Brandon Casey1-2/+2
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-25parse-options: write blank line to correct output streamLibravatar Brandon Casey1-1/+1
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-25t0040,t1502: Demonstrate parse_options bugsLibravatar Brandon Casey1-0/+100
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-19rev-parse parseopt: interpret any whitespace as start of help textLibravatar Brandon Casey1-1/+1
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-19rev-parse parseopt: do not search help text for flag charsLibravatar Brandon Casey1-2/+2
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-19t1502: demonstrate rev-parse --parseopt option mis-parsingLibravatar Brandon Casey1-6/+12
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>
2015-07-15rev-parse --parseopt: allow [*=?!] in argument hintsLibravatar Ilya Bobyr1-39/+60
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>
2014-09-04parse-options: detect attempt to add a duplicate short option nameLibravatar Junio C Hamano1-2/+2
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-03-23t1502: protect runs of SPs used in the indentationLibravatar Junio C Hamano1-56/+56
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-23rev-parse --parseopt: option argument name hintsLibravatar Ilya Bobyr1-0/+20
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>
2013-10-31rev-parse --parseopt: add the --stuck-long modeLibravatar Nicolas Vigier1-3/+39
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>
2012-08-27Fix tests under GETTEXT_POISON on parseoptLibravatar Jiang Xin1-1/+1
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>
2010-11-09t1502 (rev-parse --parseopt): test exit code from "-h"Libravatar Jonathan Nieder1-1/+1
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-07-07Merge branch 'maint'Libravatar Junio C Hamano1-0/+18
* 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-07rev-parse: fix --parse-opt --keep-dashdash --stop-at-non-optionLibravatar Uwe Kleine-König1-0/+18
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-06-13parseopt: wrap rev-parse --parseopt usage for eval consumptionLibravatar Thomas Rast1-1/+3
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-05-31print the usage string on stdout instead of stderrLibravatar Giuseppe Scrivano1-3/+3
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>
2009-06-13parse-opt: make PARSE_OPT_STOP_AT_NON_OPTION available to git rev-parseLibravatar Uwe Kleine-König1-0/+5
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-13more tests for git rev-parse --parse-optLibravatar Uwe Kleine-König1-2/+36
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-22Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* 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-22parse-options.c: fix documentation syntax of optional argumentsLibravatar Michele Ballabio1-1/+1
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-14avoid whitespace on empty line in automatic usage messageLibravatar Jeff King1-1/+1
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-05-24tests: do not use implicit "git diff --no-index"Libravatar Junio C Hamano1-1/+1
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-02-25rev-parse: fix potential bus error with --parseopt option spec handlingLibravatar Jay Soffian1-0/+43
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>