🚀 go-pugleaf

I seem to have started a couple of minor
greasefires with or without the pexec cookbook.

CASE 1:
	The Mark William's C man page for pexec
	is pretty misleading or wrong. It's
	a user trap and I fell in it.

	Pexec takes four arguments.

	pexec(type, program, arguments, environment)

	arguments is what args are passed to the program;

	Allen Pratt has stated that "arguments"
	is a string and that the first byte has
	to be the size of the string! Of course
	he knows what he is talking about. The MWC man page
	doesn't mention this. It however does give
	a C example. The example works but...

	What the example does it build a string so
	that the first byte in the string is a BLANK,
	hence pexec will think it has a 32 byte
	string. I stumbled over this when I implemented
	a simple shell and used the example for dealing
	with pexec. Why oh why is "cp", which is
	an external program, only getting 32 bytes of
	arguments I asked... Later due to Mr. Pratt
	I experienced a mild form of sudden illumination.

CASE 2:
	The environment argument remains unclarified. The
	MWC man page gives examples basically as follows:

		command = "\\bin\\date.prg"; 
		args = " 200001322400";   /* note the blank :->... */
		pexec(0,command,args,"PATH=\0");

	What happens when we say "PATH=\0"?

	Allen stated that if the environment arg is set to 0L,
	the spawned process "will inherit the parent's environment".

	I tried that and using Mark william's normal shell
	runtime startoff code I ended up with the name
	of the parent process as the "args". !!?? Things
	worked fine with "PATH=\0". This confused
	the runtime startoff code possibly?

				jim binkley
				jrb@amadeus.tek.com
				Portland, Oregon