Path: utzoo!utgpu!water!watmath!uunet!ukma!ukecc!edward
From: edward@engr.uky.edu (Edward C. Bennett)
Newsgroups: unix-pc.general
Subject: Re: File Transfer Programs
Message-ID: <2326@ukecc.engr.uky.edu>
Date: 16 May 88 18:34:56 GMT
References: <2311@ukecc.engr.uky.edu> <1209@mtunb.ATT.COM>
Reply-To: edward@engr.uky.edu (Edward C. Bennett)
Followup-To: unix-pc.general
Organization: Univ. of KY Engineering Computing Center
Lines: 24

In article <1209@mtunb.ATT.COM> rag@mtunb.UUCP (was-Richard Grant) writes:
]In article <2311@ukecc.engr.uky.edu> edward@engr.uky.edu (Edward C. Bennett) writes:
]>There is a file /usr/bin/umodem that I assume contains the UMODEM code.
]>Based on that, I assume the ATE forks off a umodem process and connects
]>stdin and stdout to it.
]
]Sorry, but it doesn't work that way.  umodem is in /usr/bin so that
]it can be executed from the shell when called by another machine.
](Consider using the ATE on another UNIX PC and calling your UNIX PC.)
]The umodem protocol is compiled into the ATE without hooks to provide
]other protocols.

Unless our machines are vastly different, things work the way I
described. You are correct about UMODEM being in /usr/bin. I suppose
that it could be called by a remote user. I don't know. I haven't tried
that. But you're wrong about the ATE. I'm able to put my own program
in place of /usr/bin/umodem, tell the ATE to do a UMODEM transfer and
watch my program run. If UMODEM is builtin, why call /usr/bin/umodem?

-- 
Edward C. Bennett				DOMAIN: edward@engr.uky.edu
(606) 257-4938				UUCP: {cbosgd|uunet}!ukma!ukecc!edward
"Goodnight M.A."				BITNET: edward%ukecc.uucp@ukma
	"He's become a growling, snarling mass of white-hot canine terror"