[cups.general] How to alias existing CUPS printerstogetadditionalpaper tray capability?

[Michael Talbot-Wilson]

On Sun, 26 Mar 2006, Michael Sweet wrote:
> Michael Talbot-Wilson wrote:
>>
>> I don't follow your logic.  Or rhetoric.
>
> UNIX, like most operating systems, uses the slash character to
> define a hierarchy of files and directories.  CUPS uses the slash
> character to define a hierarchy of printers and instances.

Okay.  To you the slash is the metaphor for all classification under
Unix.  I get it.  But when there is only a single level rather than a
non-trivial tree...?

> We chose this character because it seemed natural and obvious to
> anyone familiar with files and directories, and it is consistent
> with many name services (such as those employed in Solaris, Linux,
> MacOS X, Windows, etc.) for identifying resources that are related
> in a tree-like way.

The slash is familiar to anyone dealing with files and directories
.... for dealing with files and directories.

> In short, any other character would have been inconsistent with
> the rest of the computing world.

It is a decision.  That is all.  It is not the only one possible.
There is no need to try to prove sacred necessity.  You are not
providing a tree hierarchy to be traversed to a leaf.  You are only
providing the possibility of selecting an alternative collection of
lpoptions.

> (And, FWIW, this discussion is completely academic, as we will
> *not* be changing things...)

Noted.  Let's be academic.

>>> What is unusual is that dvips makes assumptions about the printer
>>> name, like it can be used as a filename (lpr even allows spaces in
>>> alias names!)

Dvips has been around a long time, it's how one prints under Linux, and
CUPS is for printing.  Despite your apparent disdain for what Rokicki
or whoever did in dvips you could have been tolerant enough or simple
enough to ensure that instances would interoperate with it.

It is a _valid_ assumption that a printer name can be used as a
filename until you come along and, on dubious reasoning, create a
totally unnecessary incompatibility.

>> Why are spaces in alias names a problem?
>
> Because without quoting, manipulating filenames with spaces from
> the shell is a pain in the ass.  Doing so from shell scripts is
> doubly hard because you have to be careful about re-quoting these
> filenames whenever you use them, and common shell looping mechanisms
> to not work with them.

I agree totally with all this, but why is it functionally a problem?
It works.  Slashes in file names do not work.

>>>> Perhaps one can s|/|^|g throughout the source tree.
>>> 
>>> Yeah, replace a safe character with a special shell character...
>> 
>> What shell do you use?  For bash it is a _default_ histchar.
>
> Um, yes.  It has a special meaning.  Thus, "special character".

Only in a particular context.  It is not a problem in a file name.  In
a dozen years of using bash I've never encountered it.  Granted I am a
pretty unsophisticated user who has done almost no shell scripting.

> "/" is the only character that is commonly used to indicate a
> hierarchy in UNIX.  ":" is a close second and is used by several

You beg the question by insisting on seeing it as hierarchy.  That is
a choice.  Get this: a printer instance is not a hierarchy.

> ...
> You might notice that I listed every non-alphanumeric character
> from a US keyboard...  Our choices are quite limited.

Commas are used in file names by RCS, the plus sign is used in
directory names by mgetty+sendfax.  As I mentioned, "^" is usable.
Both "{" and "}" are usable singly.  They can all be used in Unix file
names without escaping.  That they are also used for other things like
addition or regular expressions or even path expressions is immaterial
if there is not in a practical sense a clash of functions reasonably
foreseeable or encountered in development.

Your choices are slightly limited because some characters are
interpreted by the shell in relevant contexts, including "<", ">", "/"
and "&".  The strange thing is that it is one of these that you
decided to use.

By the way, thanks for the good work in all other respects.  It's
appreciated.  We can still use multiple queues with one printer.

Instances are in principle a nice idea.  But your unalterable decision
makes them unusable for probably the large majority of Linux users who
are not using something like Open Office to print, those who use what
comes in the Linux distribution, or who want better documents than
anything but TeX can produce.

So I suggest that the section on instances in the CUPS Software Users
Manual needs to be removed and instances consigned to history.