screen-ls: no output is shown in the presence of unrecognized option '-a'

[salewski]

$ screen-ls --version
screen-ls 0.3.4  (built: 2019-01-26 12:26:56)

Copyright (C) 2013, 2016, 2017, 2019 Alan D. Salewski <[email protected]>
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Alan D. Salewski.

I accidentally ran:

    $ screen-ls -la

instead of:

    $ screen-ls -lp

and was surprised that no output was emitted (neither the pretty-printed output of screen -ls that I was expecting, nor an error message), and the exit status ($?) was 0 (zero).

Suspecting it might be related to having "bundled" the two single-char options (-l and -a) as -la, I tried it again as follows, with the options separated, and got the same result:

    $ screen-ls -l -a

The documentation in screen-ls(1) says:

Any options not recognized by "screen-ls" will be passed through to
screen(1).

It is not clear that that is happening in this instance, however, since the output that would otherwise be expected from just screen-ls -l is not displayed. Also, it is not an "options ordering" problem, as the behavior of both of the following are also identical to what is described above:

   $ screen-ls -al

   $ screen-ls -a -l

FWIW, GNU screen itself gives different output for screen -ls -a than it does for screen -a -ls (the order of the options). For the former, I see a "No Sockets found in /run/screen/..." type of message. For the latter I see the unparsed output that I would expect from screen -ls.

The GNU screen command's -ls option takes an optional match parameter. Is the above behavior I'm seeing from screen-ls a bug in screen-ls itself? Or is it being interpretted as the match parameter by GNU screen? And if it is the latter, is it a bug in GNU screen that -a after -ls is interpretted as a match rather than as just another command line option?