Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
can sendfax run from a script not associated w/a tty?
- To: flexfax@sgi.com
- Subject: can sendfax run from a script not associated w/a tty?
- From: Todd Fries <todd@heuris.com>
- Date: Mon, 2 Jun 1997 14:05:11 -0500
This is driving me nuts. I have, with the example from Bill Campbell, a
script that is executed from lpd on a Linux machine ... finds the fax number ..
then calls 'system("/PATH/sendfax -d FAXNUMBER /tmp/.faxjob_PID/FILENAME");'
(captial words are what I use locally) .. .. and I always get the following
error on stderr:
fax_print_filter: 5/2/1997 13:58 Postscript = PS-Adobe-3.0
fax_print_filter: 5/2/1997 13:58 get_fax_no: >FAXNUMBER<
fax_print_filter: 5/2/1997 13:58 Fax number found: FAXNUMBER
fax_print_filter: 5/2/1997 13:58 /var/hylafax/bin/sendfax -d FAXNUMBER /tmp/.faxjob_14221/199752.13:58:49
Error creating cover sheet; command was "/var/hylafax/bin/faxcover -f 'daemon' -n '534-4351' -s 'default' -p '1'"; exit status 0
I thought things were generally successful if they exited with status 0.
Anyway, I have gone to the length as to run an rxvt with a system call from
the fax_print_script .. to make sure the environment IS the environment that
the above sendfax is being run from .. and lo and behold if I type the exact
sendfax commandline above, from the rxvt, it works, but from the script that
spawned the rxvt, it doesn't.
I'm thinking I need to do a source invasion .. anybody have any other
suggestions?
Oh, and by the way, whoever it was that suggested to me that I set
'^session_lockout' on the serial port THANK YOU!
I believe this deserves to go in the FAQ. 'modem is busy' == 'modem is
actually in use, or the serial ports don't allow multiple processes to open
the serial ports simultaneously' .. the gotcha is that debian comes setup by
default to configure all serial ports WITH session_lockout, which is not the
desired setting when faxgetty assumes ONLY uucp locking and opens the modem
for the duration of it's existence!
Thanks much,
--
Todd Fries .. todd@heuris.com