[cups.general] Passing extra information fromenvironmenttobackend?

[Kurt Pfeifle]

Erik Forsberg wrote:
>>>> One could also store the "myoption=whatever" setting in one of
>>>>
>>>>   /etc/cups/lpoptions
>>>>   ~/.cups/lpoptions
>>>>
>>>> (depending on: is the setting user-specific or not?) and rely on it
>>>> being picked up by the lp/lpr commands automatically.
>>> Interesting, but will not solve the problem - I might have explained
>>> badly, but as the same user may have several sessions, on the same
>>> machine, and I want to distingush between sessions in my backend,
>> BTW, what do you mean with *MY* backend?
> 
>> If it is a custom backend, over whose code you have full control,
> 
> It is.
> 
>> you
>> can make it read a commandline option that is passed via the print
>> command. Say "my_session_id=username at session_number". Your backend
>> just needs to evaluate what it sees as $5 (if backend is a shell
>> script) or more generally, argv[5]
> 
> Sure. The problem is that I can't expect my users to pass this
> commandline options when they print, 

OK, I agree it is not feasible to expect most users to set a com-
mandline option for printing... --- but how do you expect them to s
et the environment variable instead ?!?!?

(If you say, "I don't -- it will be done automatically for them!"
I'll reply, "OK -- a similar automatism you could use to automati-
cally set the option into each ~/.cups/lpoptions file at the start
of the session." And they won't even notice it, and all sane GUI
print dialogs do take that file into account anyway: kprinter,
gtklp, xpp,....)

> especially not since most print
> jobs will be generated by software that uses libcups to print, 

Which software do you have in mind? Is that some custom software as
well?

> not the
> 'lp' or 'lpr' commands. Neither KDE's printer library, Gnome's printer
> library nor Openoffice run 'lp' or 'lpr' to submit their print jobs -

KDEPrint (as of KDE3) runs its own helper utility called "cupsdoprint";
and it *does* take into account what is set in ~/.cups/lpoptions (it
does take into account a few additional, KDE-specific options in addi-
tion....).

> they all call functions inside libcups to do that. 
> 
> At least in my understanding, please correct me if I'm wrong. 

I don't know about the new Gnome printing library. But with KDE's
kprinter you were wrong. With xpp and gtklp it would work the way
I suggest too...

> There is very little use of commandline printing in this kind of
> environment. 

As I said, all GUI tools I'm familiar with do take into account
the .lpoptions settings. (Well, they most likely do this because
*libcups* does it for them, and they do not even need their own
code to stick that functionality into themselves)

>> That's what Johannes already pointed out.
>>
>>> setting lpoptions in ~/.cups/lpoptions will not help, as these will
>>> be used by all sessions.
>>>
>>> If there were an environment variable for lpoptions being picked up
>>> by libcups, that would help, because this variable could be set
>>> differently in different sessions. 
>> Why does it *need* to be an env var, why can't it be a commandline
>> option?
> 
> See above. An environment variable read by libcups could be set at
> start of session. 

So you're still in a persistent "state of denial" where you want to
ignore that libcups does take into account settings in ~/.cups/lpoptions,
and instead still insist on stuffing the same feature into an env var?

If you can set an env var at the start of a session, you surely also
can set an .lpoptions param, and rely on libcups to pick it up and
pass it downstream...

:-)

> All started programs would then inherit it, allowing
> libcups to read it regardless of application submitting the print job.

:-)

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany