Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker!spdcc!merk!alliant!linus!philabs!phri!marob!daveh
From: daveh@marob.masa.com (Dave Hammond)
Newsgroups: comp.unix.xenix
Subject: Re: xmodem transfers
Keywords: xmodem cu
Message-ID: <25C8BF74.44F@marob.masa.com>
Date: 1 Feb 90 23:00:02 GMT
References: <25bd1e45:527comp.unix.xenix@vpnet.UUCP> <1990Jan26.162447.3894@chi <25c28971:527.2comp.unix.xenix;1@vpnet.UUCP>
Reply-To: daveh@marob.masa.com (Dave Hammond)
Organization: ESCC,  New York City
Lines: 23

In article <25c28971:527.2comp.unix.xenix;1@vpnet.UUCP> hb@vpnet.UUCP writes:
|	                         Actually both copies of cu are
|still there while running a remote command. I've done some more
|exploration on this using umodem. This program has anoption which
|allows it to open the (modem) tty device to perform the transfer
|when it runs on the local system. However, when I run it, the open
|fails on an access violation (EACCES). 

|To try and solve the problem, I have used chown to make uucp the
|the owner of both /dev/tty2A and umodem. I have also used 
|"chmod g-l /dev/tty2A" which, as near as I can tell, might cause
|cu to not lock the device. These have not solved the problem.

I am surprised that, thus far, noone has mentioned 'rz' (rx, rb, ...),
which can be passed a "-1" flag specifying that standard output be used
for the transfer.  The initial help screen mentions that this option is
for use under 'cu'.  Since rz uses standard io, this obviates the need
to directly access a tty line, and the problems mentioned above.

--
Dave Hammond
daveh@marob.masa.com
uunet!masa.com!marob!daveh