universal-ctags
main: Introduce "--" as option terminator
Close #1883.
To pass a file name started from "-" to the ctags command easier, this change introduces "--" as option terminator in the command line processing.
$ cat ./-i
#!/bin/sh
function bar
{
:
}
$ ../../ctags -G -o - -i
ctags: No files specified. Try "ctags --help".
$ ../../ctags -G -o - ./-i
bar ./-i /^function bar$/;" f
$ ../../ctags -G -o - -- -i
bar -i /^function bar$/;" f
Signed-off-by: Masatake YAMATO [email protected]
Coverage decreased (-0.004%) to 84.864% when pulling 7dd5e311ce9913ca72ef298e98b8846a756e65a2 on masatake:introduce-option-terminator into b1621cff05f25545416f6dc9c90f735cc1e19a96 on universal-ctags:master.
.... Removing Tmain/nameless-long-option.d test case is not a good idea. I will revert it partially.
How do you append a change to this pull request? Very interesting technique.
"--" is not only for "-L -" option. "--" can be used anywhere on a command line.
I'm calling "--" "option terminator". Do you have any better name for it?
Bisected. It seems that I knew this commit breaks compatiblity.
[jet@localhost]~/var/ctags-bisect% git bisect bad
f6e092455959f66aa2c43bbaf7591dbe4c77008b is the first bad commit
commit f6e092455959f66aa2c43bbaf7591dbe4c77008b
Author: Masatake YAMATO <[email protected]>
Date: Wed Jul 1 23:25:56 2015 +0900
Don't allow putting --list-kinds like options after input file names in command line
Background:
$ ctags -o - main.c --list-kinds
Both the result of parsing main.c and the list of kinds go to stdout.
A tool consuming output may be confused.
As far as reading option.c ctags doesn't allow such dangerous order of
option specification.
A boolean, NonOptionEncountered becomes true when the command line parser handles
an input file name initially.
checkOptionOrder checks the order for short options.
initOnly field of parametricOption and booleanOption structures provides
the way to declare an order sensitive long options.
These facilities were just ignored.
I am afraid this behavior was introduced by me when working on optlib.
However, exuberant ctags shipped as part of Fedora also ignores the order.
This patch fixes the facilities.
This breaks the compatibility between exuberant ctags in semantics of command line
interpretation.
Signed-off-by: Masatake YAMATO <[email protected]>
:040000 040000 76eae8864a177c8d4c298d8a2048039f4fc2c652 489d56c834550552e5ef7f6c980367fd72e226bf M main
What I should do first may be updating man/ctags-incompatibilities.7.rst.in.
How do you append a change to this pull request?
If the "allow maintainers to change branch" or similar checkbox is checked, others (with write permissions for the repo) can push there, too.
Sorry for the lack of feedback from me - just tried it again, when rg --files would include - in a project, used with rg --files | --links=no -L -. This PR works there, but from quickly looking at the code that might be handled as an option.
And printf '-' | ./ctags --links=no -L - still fails with "ctags: Unknown option: -".
@masatake san,
What I should do first may be updating man/ctags-incompatibilities.7.rst.in.
I've sent PR #2859 for this issue (#1889).
If you merge the fix of -- option, we can close #596, #1883, and #1884.
@hirooih, thank you. Your change reduces the complexities behind this pull request.
After merging #2859, I can think about this issue without worrying about the incompatibilities.
I will disallow passing an option via -L - option. In many places, I have assumed the values for options like --kinds-<LANG>=... are never changed during parsing files.
I will rework this item.