Path: utzoo!attcan!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.i386
Subject: BUG in ISC UNIX 2.2
Keywords: bug, exec, isc, unix, 386/ix
Message-ID: <1990Jun30.212356.1209@virtech.uucp>
Date: 30 Jun 90 21:23:56 GMT
Organization: Virtual Technologies Inc.
Lines: 46

Although I can't find it documented anywhere, ISC has apparently added
support for exec(2) interpretation of the "#!interpreter" line at 
the begining of a script file.  This works pretty well until you give
it a name that is longer than 18 bytes.

For example:

	A file containing:

		#!/usr/bin/perl
		{perl script stuff}

	will work correctly.

HOWEVER,

	The same file, with the first line changed as follows:
	
		#!/usr/local/bin/perl
		{perl scrip stuff }

	will lock up.  (By lock up, I mean it executes a kernel sleep at
	a priority so high that it can't be interrupted!).  And this is
	only part of the problem.  When it locks up, it still has the 
	directory locked and therefore any access to the directory will
	also lock up.

	The only way to get the directory is to re-boot the system.

This only happens when the file actually exists (i.e if the line 
has /usr/local/bin/perly which does't exist, I would get an error 
message that "program" wasn't found where program is the name of the
script file, not the interpreter).

When I discovered this, I tested it with a copy of /bin/sh (copying it
to:
		/usr/local/bin/sh		which worked
		/usr/local/bin/shi		which worked
		/usr/local/bin/shit		which locked up

So I know that it is not a problm with any PD software.
		
-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170