Obsolete + form for long arguments

[epa]

The form +foo instead of --foo has been obsolete for thirty years. Perhaps it's time to remove it?

Or if it's still too soon to do that, at least provide a way for applications to turn it off. For me at least, it does trip me up that any argument beginning with the + character gets treated as a long option.

[sciurius]

You can set environment variable POSIXLY_CORRECT to a true value, or

use Getopt::Long qw(:config prefix_pattern=--? );

[epa]

Thanks. Perhaps that prefix_pattern setting should be mentioned in the documentation at the point where it says the + form is strongly deprecated.

I still believe the better approach would be to disable + by default, but callers could add it back in using prefix_pattern.

[sciurius]

I'm not shure what will happen if this behaviour would be changed. Besides, you're the first one to mention this in 30+ years time...

[n1vux]

first … in 30+ years

this came up with the use of ack which takes a Perl RE or literal (fgrepish) match string, as well as filenames &/or paths as positional (non-flagged) arguments whereby ack -Q +1 (-Q for Quote, to suppress RE nature, so this is fgrepish not RE) seems a very reasonable request, and ack -Q -- +1 seems inelegant as a workaround, as it uses POSIX -- to mask non-POSIX +LongFlag interpretation. Myself I'd use ack '[+]1' but given 30+ years deprecation / POSIX standardization, for the first to just work is a reasonable ask. IDK if it's worth fixing from our side on Ack either, one request in 20 years is only slightly more frequent than 1 in 30.

re suggested code fix, which I'm willing to at least try and maybe Andy will go for,

use Getopt::Long qw(:config prefix_pattern=--? );

Is the syntax above correct or did it more likely get mangled by markdown? Looks suspect to me!

xref https://github.com/beyondgrep/ack3/issues/378

[epa]

The above syntax is correct, I believe.

% perl -E 'use Getopt::Long; GetOptions("foo"); say "foo=$opt_foo"; say "arg=$_" foreach @ARGV' +foo
foo=1
% perl -E 'use Getopt::Long qw(:config prefix_pattern=--? ); GetOptions("foo"); say "foo=$opt_foo"; say "arg=$_" foreach @ARGV' +foo
foo=
arg=+foo

In the particular case of ack, the above change isn't enough, because ack uses Getopt::Long in some more complicated way. I did have a go but couldn't work out where I needed to change things. (It probably involves calling Getopt::Long::Configure("prefix_pattern=--?") at the right moment.)

[n1vux]

:eyes: Ahh.
(I don't recall ever seeing an RE protected by qw() before, my Mk 1 eyeballs did not parse it correctly the first time.)

Yes, and alas the POSIXLY_CORRECT runs afoul of the complicated usage also. (Somehow it invalidates our definition --type-add which is required for defaults processing.)

[sciurius]

Ah ack! Great tool. I would use it if it were able to invoke an editor at the location of each match. I have a vague recollection that I've asked for this feature somewhen in 2012 but got no for an answer, so I wrote App::File::Grepper :).

Anyway -- yes, POSIXLY_CORRECT has more effects than just removing + from the prefix, but setting prefix_pattern to --? should effectively do just that.

[petdance]

I would use it if it were able to invoke an editor at the location of each match.

If you're a vim user, then ack.vim may be of interest.