Output from interface script

[Luis Toro]

I recently migrated an application from a server running 10.20 to 11.i. This application evidently uses "lp" to process a file via a customized interface script (instead of printing it) which is not working as it should. Since its a shell script, I added a "set -xv" statement to troubleshoot, however I don't know where the output is going. I've checked /var/adm/lp/log and lpana.log.

[Leif Halvarsson_2]

Hi,
Which device file is used for this printer, I suppose the output is going to the devicefile.

[Luis Toro]

Hi Leif,

It is not going to any device file. Here is the sequence of events from the app:
- user requests a report email to himself
- the app issues an "lp" with the destination of "Mail" and the "printfile" is the report data.
- the report gets emailed to the users exchange account
I took a look at the "Mail" interface script, and it taking the options passed to it (by lp I imagine) and using the options (ie. userid) to email the report (instead of printing it). It is creates a temporary mail file, with "To:", "From:" and "Subject:" headers that it gets by parsing the printfile. This used to work and I don't see why it shouldn't. Thats why I'm hoping I can get verbose shell info (ie., set -xv) to figure out the problem.

Thanks

[Leif Halvarsson_2]

Hi,
Perhaps I misunderstand you. Is there a printer configured in the printer spooler for this job (and the processing is done in the printer interface script). If there is a such printer it always must have a devic file. You can use SAM to view the devicefiles for your printers.

I have done some special printer interface scripts myself, similar to yours. In my case I used /dev/null as device file. Nothing was sent to this file, the script done some other processing with the data but there has to be a device file for the printer. And, as I think, the debug information is perhaps going to the device file.

[Luis Toro]

Leif,

Checked in SAM, under Printers
and Plotters, and didn't see any line item for a device file. However, that does make sense. How can I change that file ?

Thanks

[Andreas Voss]

Hi,

could it be the case that the script is ok but sendmail doesn't send out the email ?
Check with

mailq

if there are emails in the mail queue that were not delivered.

Regards

[W.C. Epperson · Accepted solution]

A generally useful technique when using "set -x" to debug background scripts is to do a "exec 2>/tmp/stderr$$" just before (or after) the set -x. This will redirect the "set -x" to a separate file for each iteration, where each file name ends in the pid of the script process. Careful that you watch out for space/size issues while debugging!

[Luis Toro]

Thanks W.C.
Thats what I was looking for.
Still curious as to where exactly "lp" sends stderr (/dev/null ???), and if I can change that, in lieu of modifying the interface script. In any event I see that the "parsing" of the report is not happening as it used to, due to a change in the format (application problem of course).
Thanks to all. I will assign points accordingly.

[Frank Slootweg]

> Still curious as to where exactly "lp" sends stderr
> (/dev/null ???), and if I can change that, in lieu of
> modifying the interface script.

It is not lp(1), but lpsched(1M) which redirects stderr (and stdout). It redirects both to the device file which was used when creating the printer ("-v" option of lpadmin(1M)), i.e. possibly/probably /dev/null in your case.

For details see the "Models" section in the lpadmin(1M) manual page