Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: net.micro.atari16
Subject: Re: uuencode's input file
Message-ID: <1130@hoptoad.uucp>
Date: Wed, 24-Sep-86 17:53:12 EDT
Article-I.D.: hoptoad.1130
Posted: Wed Sep 24 17:53:12 1986
Date-Received: Wed, 24-Sep-86 22:26:59 EDT
References: <8609121915.AA27613@mitre-bedford.ARPA>
Organization: Nebula Consultants in San Francisco
Lines: 29

In article <8609121915.AA27613@mitre-bedford.ARPA>, jhs@MITRE-BEDFORD.ARPA writes:
> I was giving myself fits trying to uuencode a file on the VAX...
>                               uuencode apparently takes the first argument
> to be that string and assumes that you meant to type in your binary file at
> the keyboard.  (Sounds like a silly assumption to me, but I didn't write
> uuencode.)

Uuencode is assuming that you know about standard input and output.
Since you used standard output redirection, (the > sign), it sounds
like a reasonable assumption.  This lets you pipe things to uuencode,
for example.
 
> To uuencode into a local file, I found the following syntax to be necessary
> (or at any rate sufficient, which is sufficient!):
> 
> 	uuencode inputfilename anystring >output filename

You could also use:

	uuencode anystring <input >output

I agree that uuencode's command line leaves something to be desired.
It would've been better to make the "destination string" be an option
(eg  uuencode -d deststring input >output).  I just thought I'd remind
people that "programs that default to reading from the keyboard" are
really "programs that default to reading standard input" -- a good thing.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa
		     May the Source be with you!