fmt: clap causes information loss

[BenWiederhake]

$ cat << EOF > test.txt
> do
> not
> format
> these
> words
> =but
> =these
> =words
> =please
> EOF
$ ../gnu/src/fmt -p= test.txt 
do
not
format
these
words
=but these words please
$ cargo run -q fmt -p= test.txt 
do not format these words =but =these =words =please
$

Or in general: GNU parses -p=ANYTHING to be the prefix =ANYTHING, whereas clap parses the same argument as the different string ANYTHING. This cannot be easily recovered, and basically requires parsing the arguments from scratch again.

This also affects many other tools. I think it was already documented somewhere, but I couldn't find it.

I see this as yet another strong argument in favor of #4254.

[tertsdiepraam]

Yep this is one of the cases that almost takes another parser.

[BenWiederhake]

Something very similar happens with env --ignore-signal[=]. According to the manual:

Without SIG, all known signals are included. Multiple signals can be
comma-separated. An empty SIG argument is a no-op.

Empty list ignores nothing:

$ env --ignore-signal= sleep 999 &
[1] 564133
$ ps | grep sleep
 564133 pts/9    00:00:00 sleep
$ kill -s SIGHUP 564133
$ 
[1]+  Hangup                  env --ignore-signal= sleep 999

Providing no argument ignores everything:

$ env --ignore-signal sleep 999 &
[1] 564145
$ ps | grep sleep
 564145 pts/9    00:00:00 sleep
$ kill -s SIGHUP 564145
$ 
$ sleep 1
$ ps | grep sleep # Still alive!
 564145 pts/9    00:00:00 sleep

Found while reviewing #6377.