input string beginning with "-" parsed as option about libqrencode

[mdemoss]

Maybe all that can be done is to document the --

After giving it some thought, trying to do what coreutils echo and some others do (echo "-n-" works and echo "-n" does not) is a little inconsistent so documenting really may be best.

[PhilterPaper]

On many systems' command line input, -x and --xyz, whether or not within single or double quotes, will be interpreted as command line options. --test is no different from "--test", it will see -- and try to treat it as an option. If you put the text within quotation marks (double quotes), you can often escape the string and tell the command line or script interpreter not to use it as a command line option: "\--test". Inconvenient, but a possible workaround.

[charmander]

If you put the text within quotation marks (double quotes), you can often escape the string and tell the command line or script interpreter not to use it as a command line option: "\--test".

@PhilterPaper That’s not how it works either – the program will just see the string \--test with a literal backslash (since \- isn’t a meaningful double-quoted escape sequence) and produce the wrong output.

The -- end-of-options marker is the correct solution, and is a well-established standard.

[PhilterPaper]

That's why I added the caveat often when talking about command line strings with a leading "-". It's going to be handled by the application, not by the OS, and it may or may not see the "escape". As an example of where this does work, see "grep" (at least, the Windows implementation). grep -S "--test--" filepattern will complain about an illegal option, but grep -S "\--test--" filepattern works correctly. It's something the OP might give a try just to see if it works for them.

A formal end-of-options marker, if implemented, would be the proper way to do it (and is not a "workaround").