Weird things in csh (and kernel?) -- certainly!

[Maarten Litmaath]

In article <716 at yabbie.rmit.oz> rcodi at yabbie.rmit.oz (Ian Donaldson) writes:
\In article <1193 at ark.cs.vu.nl>, maart at cs.vu.nl (Maarten Litmaath) writes:
\> 	% a.out < a.out
\> 	a.out: Text file busy.
\
\You didn't say which system.

4.1BSD!

\Yep, its a kernel bug in some pre 4.[23]bsd systems.  Exec processing
\only checks for open files rather than files open for writing when
\determining if the file is busy.
\
\Its also a -big- security bug in such systems that leave most system binaries
\publicly readable.  The workaround is to -not- make such binaries publicly
\readable.  Simple.

You're completely right.

\...
\> 	% ./echo > echo
\
\	First clobbers "./echo" then csh tries to execute it with stdout
\	sent to it.  execv() fails because the kernel sees an empty file, 
\	so csh tries to execute it as a script.
\
\	Since a new csh is started up to execute it, it reads your ".cshrc"
\	and executes that first.

Normally a Bourne shell is started up (default for shell scripts), but
- as Ronald Khoo mentioned in a reply I got - if the file size is zero,
csh appears to execute the shell mentioned in the internal variable
"shell":

	% : > gnome
	% chmod 755 gnome
	% set shell=hobgoblin
	% gnome
	hobgoblin: No such file or directory
	% echo '' > gnome
	% ls -l gnome
	-rwxr-xr-x 1 3754          1 Mar  5 15:23 gnome
	% gnome
	%

\	A great puzzle!

Thanks! :-)
-- 
Which of Santa Claus and God          |Maarten Litmaath @ Free U Amsterdam:
             is more likely to exist? |maart at cs.vu.nl, mcvax!botter!ark!maart