Bug 1910415

Summary:	lpstat -h has hidden ordering dependency
Product:	Red Hat Enterprise Linux 8	Reporter:	Mason Loring Bliss <mbliss>
Component:	cups	Assignee:	Richard Lescak <rlescak>
Status:	CLOSED ERRATA	QA Contact:	Petr Dancak <pdancak>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.3	CC:	bmason, pdancak, zdohnal
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.0	Flags:	pm-rhel: mirror+
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	cups-2.2.6-50.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	2091997 (view as bug list)		Environment:
Last Closed:	2022-11-08 10:47:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2091997

Description Mason Loring Bliss 2020-12-23 19:32:33 UTC

Description of problem:

lpstat(1) from cups-client needs -h to specify a host to appear in the 
command line prior to other arguments. There's nothing indicating this in
the docs or help text.


Version-Release number of selected component (if applicable):

Multiple versions. (E.g., we also see this on Debian.)


How reproducible:

Note that the -h is ignored if it follows -r, but honored if it precedes 
-r. In my test case, there is a cupsd running, but it is *not* listening to
port 1234. I'd expect the -h directive to apply regardless of order.


Actual results:

/home/mason$ lpstat -r -h 127.0.0.1:1234
scheduler is running
/home/mason$ lpstat -h 127.0.0.1:1234 -r
scheduler is not running


Expected results:

/home/mason$ lpstat -r -h 127.0.0.1:1234
scheduler is not running
/home/mason$ lpstat -h 127.0.0.1:1234 -r
scheduler is not running

Comment 2 Mason Loring Bliss 2021-01-04 20:28:46 UTC

This was noted internally, so we are the customer. It would be better to 
break the implicit ordering dependency than to simply document it, if we 
have the option to do that.

Ordering behaviour is not set in stone, but there are common opinions:

    https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html

which says:

    "Options may be supplied in any order, or appear multiple times. The
     interpretation is left up to the particular application program."

There are probably examples going both ways, but as I look, what I'm 
generally seeing is that arguments with positioning requirements are 
treated specially, usually without dashes, with ordering for those 
arguments specified in man page and usage. Some examples:

    cp [OPTION]... [-T] SOURCE DEST
    ln [OPTION]... [-T] TARGET LINK_NAME
    ls [OPTION]... [FILE]...
    bzip2 [ -cdfkqstvzVL123456789 ] [ filenames ...  ]
    dig [global-queryopt...] [query...]
    mount [-fnrsvw] [-t fstype] [-o options] device dir

So, we could do it either way, but we were surprised by the positional 
requirement, which means other people have been and will be surprised by it
as well.

Comment 17 errata-xmlrpc 2022-11-08 10:47:47 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (cups bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7716