🚀 go-pugleaf

Submitted-by: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)

In article <17633@cs.utexas.edu>
	peter@ficc.ferranti.com (Peter da Silva) writes:

>Subject: Re: spawn() wars... please... not again...

And you have already lost the war. So, please! not again!

>Leave in the
>fork() call, but allow a more efficient (and, let's face it, easier to
>understand) alternative: spawn().

In the last war, you can't even show a specification of spawn(), because of
its complexity. Every UNIX programmer understand fork() and exec(), but
can't understand spawn() without its specification.

>Leave in the fork() call,

So, you are not trying to eliminate fork().

You should also preserve exec(), because exec() has its own purpose and
several programs are actually using it without fork().

>No. Those are the safe operations between fork() and exec() on UNIX.
>
>POSIX looks like it's going to comprise far more than UNIX.

If fork() and exec() exists in POSIX, many (if POSIX should be useful, all)
operations are safe between fork() and exec().

>Look, I know you don't like spawn(). But in a lot of environments... INCLUDING
>ONES THAT ARE OTHERWISE QUITE CAPABLE OF SUPPORTING A POSIX ABI... it is *not*
>possible to do a safe and efficient implementation of fork().

A lot of? Can you name them?

Anyway, it is the problem of that environment. It should provide safe
and inefficient implementation of fork() and safe and efficient
implementation of system(). If a programmer want to squeeze extra
performance in some case which can not covered by system() (dose such
a case actually exist?), he can do so by not using POSIX there if he
think effeciency is more important than ABI.

>Let's say you define vfork() as "set a flag that all posix calls that deal
>with uid, signals, files, etc... look at, so they just write a "script" of
>actions to take on behalf of the new process".

I can't understand what you are saying. "set a flag"? What?

>> Most (perhaps, more than 90%) of cases where fork/exec is necessary
>> is covered by system(). spawn() is not necessary.
>
>	No, system() and popen() can not, ever, let you pass a set of
>	arguments to a program without diddling by the shell. When you
>	have no way of knowing whether that shell will be sh, csh, ksh,
>	or even rc what can you do to protect yourself?

Read the manual! System() and popen() always use "/bin/sh".

>	Who knows, I can easily imagine DEC setting things up so a user
>	could set his shell to DCL and hose *everything* up.

User's shell has nothing to do with the behaviour of system() nor popen().

>	Using system() in programs like (for example) uucp, mail handlers,
>	and so on is a security hole you can drive a truck through.

Yes, it can be a security hole if used improperly just like many system
calls. I'm sure spawn() can also be a security hole. So what?

						Masataka Ohta

Volume-Number: Volume 22, Number 112

Submitted-by: std-unix-request@uunet.uu.net (John S. Quarterman)

Unfortunately, I'm beginning to hear from readers who are deleting
unread every message in the qfork/spawn discussion.  I have to admit I
tend to agree that there's more heat than light being shown on all
sides of this one.

So, could we please either get back to reasoned technical discussion,
or move on to something else?

John S. Quarterman, moderator, comp.std.unix and std-unix@uunet.uu.net

Volume-Number: Volume 22, Number 113