Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!allegra!oliveb!Glacier!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.bugs.4bsd
Subject: Re: ftp won't always glob
Message-ID: <2977@sun.uucp>
Date: Sun, 10-Nov-85 16:47:08 EST
Article-I.D.: sun.2977
Posted: Sun Nov 10 16:47:08 1985
Date-Received: Wed, 13-Nov-85 08:23:23 EST
References: <919@bbncc5.UUCP>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 33

> Description:
> 	When processing '!' shell escapes, Ftp globs meta characters 
> 	on its own and does an execvp() instead of handing the command
> 	to a shell. If you give '!' more than one argument, you get 
> 	garbage out. If you give it one arg, the glob still doesn't work.
> 	
> Fix:
> 	I think Guy Harris mentioned this about 7 months ago, but
> 	fixed it by removing the feature and always forking a shell.
> 	I you would rather make it work, here's how.

Why should "ftp" duplicate the actions of the shell?  Other UNIX programs
handle shell escapes by doing an "sh -c" (except "ed", which uses the old
"-t" crock), because that way they don't have to know anything about how the
shell works.  I don't think shell escapes are used enough to make the
performance considerations of bypassing "sh" important.

Also note that to really make shell escapes work right, you also have to
recognize input/output redirection, pipelines, etc., etc. - none of which
"ftp"'s built-in code does.

I suspect the reason "ftp" does its own command parsing is that it's a
halfassed piece of code; note all the bug reports that have been posted.
(And, as the Good Book says, "There's bigger deals to come!"; you may notice
a blank line produced after a command finishes when you use "ftp" on Suns.
This is because, instead of returning from the command loop after executing
a command, it jumps back by doing "longjmp(<whatever>, 0)", and Sun's
"longjmp" converts a second argument of 0 into a second argument of 1, as
the S5 "longjmp" does - thus, the caller of the command loop thinks it got
an error.  I'll fix it to work sanely at some point; there are also some
other bugs found by somebody else here.)

	Guy Harris