bradley@riacs.edu (Brad Christofferson) (02/03/91)
We are having trouble installing CAP to print from a Sun4 workstation to a laserwriter on appletalk. I sent out a previous message about it and have more information. Here is the original question: ============================== Subject: Cap5 papif problem? We are installing Cap on a Sun4 system with a localtalk network connected through a Kinetics AEG. The cap software appears to be operating correctly, we can see all the devices on our local zone with atlook. We can connect to the printer directly using tlw and have printed a test file that way. Anyone seen this one before?: psbanner: geo.arc.nasa.gov:matt Job: hosts.lpd Date: Wed Jan 30 18:05:11 1991 papif: Starting job for matt@geo.arc.nasa.gov at Wed Jan 30 18:05:12 1991 on pri nter Laserwriter II NTX 215:LaserWriter@* filter setup: child exec: Permission denied The transcript software was recently installed. We copied the filter files to a new location in /usr/local/cap and pointed lpr in that direction in the printcap file. Permissions look ok on the filter files for execution and ownership. The problem follows... Papif does an exec of a child process in part of the code. Before that section it looks like there is a debug option. We haven't tried to compile with the debug option set yet but that could be the next step. ======================================================================= We have compiled it with the debug option and now have more information. The log file shows: psbanner: geo.arc.nasa.gov:operator Job: hosts.lpd Date: Fri Feb 1 16:53:42 1 991 papif: Starting job for operator@geo.arc.nasa.gov at Fri Feb 1 16:53:44 1991 on printer Laserwriter II NTX 215:LaserWriter@* papif: bannerfirst yes, bannerlast no, verboselog yes papif: atpresponse timeout = 480 ticks (1/4 second units) papif: status watch lower time limit 10 seconds papif: rflowq = 8 packets, sflowq = 1 packets papif: strip control d's no, map carriage return to line feed no papif: accounting = yes, chargebanner yes, idlestuff yes, structured yes papif: reverse = papif: pstext = /local/tran/transcript/pstext papif: banner file = .banner papif: cap.printers = /etc/cap.printers papif: Forking /local/tran/transcript/pstext in front of current fork papif papif: Forking in front of current fork papif filter setup: child exec: Permission denied We also attempted to recreate the problem and think we came up with something although I am not sure why this is happening. We ran the psif filter script by hand with the -x option to see what exactly was happening. It got down to the end and was running papif and forking off a child process. At that point I think it was waiting for the file input. At least that is what I think lpd would have done. Instead of a file, I typed exec and got the same error message that we have been seeing in the log file. Here is what we did: sh -x /usr/local/cap/psif PATH=/bin:/usr/bin:/usr/ucb + export PATH afile= host= login= indent= length= width= prog=/usr/local/cap/psif + pwd cwd=/var/spool/ps1 + basename /var/spool/ps1 pname=ps1 PSLIBDIR=/local/tran/transcript REVERSE= VERBOSELOG=1 BANNERFIRST=1 BANNERLAST=0 BANNERPRO=/local/tran/transcript/banner.pro PSTEXT=/local/tran/transcript/pstext PSCOMM=/local/tran/transcript/pscomm + export PSLIBDIR VERBOSELOG BANNERFIRST BANNERLAST BANNERPRO REVERSE PSTEXT + test -r ./.options + test 0 != 0 PATH=/local/tran/transcript:/bin:/usr/bin:/usr/ucb + export PATH + basename /usr/local/cap/psif prog=psif comm=/usr/local/cap/papif -P ps1 -p psif -n -h + exec /usr/local/cap/papif -P ps1 -p psif -n -h papif: Starting job for -h@ at Sat Feb 2 13:40:22 1991 on printer Laserwriter I I NTX 215:LaserWriter@* papif: bannerfirst yes, bannerlast no, verboselog yes papif: atpresponse timeout = 480 ticks (1/4 second units) papif: status watch lower time limit 10 seconds papif: rflowq = 8 packets, sflowq = 1 packets papif: strip control d's no, map carriage return to line feed no papif: accounting = yes, chargebanner yes, idlestuff yes, structured yes papif: reverse = papif: pstext = /local/tran/transcript/pstext papif: banner file = .banner papif: cap.printers = /etc/cap.printers papif: Forking <stdin> in front of current fork papif exec papif: Forking behind current fork <stdin> filter setup: child exec: Permission denied papif: Finished job at Sat Feb 2 13:40:30 1991 with status 2 Does anyone have any clues about this? I tried to run trace on an lpr of a file but the lpd just hands off the control to another process and I can't trace what happens next. Methinks the problem is in the CAP software itself. It looks like the other CAP programs all work ok. I can see all the appletalk devices on the localtalk network. Maybe it is the transcript software... Brad Christofferson
wade@hobbes.ucsd.edu (Wade Blomgren) (02/03/91)
In an article, bradley@riacs.edu (Brad Christofferson) writes: > > Anyone seen this one before?: > > psbanner: geo.arc.nasa.gov:matt Job: hosts.lpd Date: ..... > papif: Starting job for matt@geo.arc.nasa.gov at Wed J...... > filter setup: child exec: Permission denied > > [copious debugging information deleted] Yes, I've seen this exact problem before. Basically papif is trying to 'exec' a filter with a name that is the empty string. In (some flavors of) Unix, the empty string is translated by the file system into the current working directory ("."). This empty string in this case is your "REVERSE" filter. The papif program tries to figure out if you want (and can handle) reversal of the pages in the output file by examining the REVERSE environment variable (which unfortunately is in this case the empty string, not a null string, as it is set by the shell script). The program figures that since the reverse variable is not NULL you must want reversal. It tempers this behavior somewhat by checking for the appropriate magic (!%) at the front of the PS file and also respecting the pscomm "-r" (never reverse) flag. It all gets going when the papif program does an "access" call on the (empty) psreverse (REVERSE) string, and gets success, since of course you can access the current directory. Later it tries to "exec" the directory, and you see the somewhat cryptic result: "permission denied". The quick and dirty solution is to add the "-r" flag to the call of $PSCOMM (really papif) in your cap version of the psif filter. The real solution is to fix papif to respect empty reverse strings, not just NULL ones. I meant to submit a bug report for papif at the time but got distracted....sorry about that! Wade Blomgren wade@hobbes.ucsd.edu