[comp.unix.i386] BUG in ISC UNIX 2.2

cpcahil@virtech.uucp (Conor P. Cahill) (07/01/90)

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 

jackv@turnkey.tcc.com (Jack F. Vogel) (07/02/90)

In article <1990Jun30.212356.1209@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
>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.
 
Conor, really, I am surprised at you :-}, not reading the release notes on
a new release! I quote from page 12:

	The exec(2) system call has been enhanced to allow script files to
	be interpreted by a shell (or command interpreter) of the writers
	choice. To take advantage of this feature, a script must include
	the line #! interpreter, where interpreter is any command processor,
	such as /bin/csh...

In any case, thanks for the info on the related bug, have you informed ISC
of this other than assuming they track things posted here??

Disclaimer: I speak for myself, not my employer.

-- 
Jack F. Vogel			jackv@locus.com
AIX370 Technical Support	       - or -
Locus Computing Corp.		jackv@turnkey.TCC.COM

cpcahil@virtech.uucp (Conor P. Cahill) (07/03/90)

In article <1990Jul2.155159.664@turnkey.tcc.com> jackv@turnkey.TCC.COM (Jack F. Vogel) writes:
>In article <1990Jun30.212356.1209@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
>>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.
> 
>Conor, really, I am surprised at you :-}, not reading the release notes on
>a new release! I quote from page 12:
>
>	The exec(2) system call has been enhanced to allow script files to
>	be interpreted by a shell (or command interpreter) of the writers
>	choice. To take advantage of this feature, a script must include
>	the line #! interpreter, where interpreter is any command processor,
>	such as /bin/csh...

I did read the release notes when I installed the system.  When I ran into 
the problem I spend an hour or so going through them again and still didn't
find it.  I must of been smoking some rope.

>In any case, thanks for the info on the related bug, have you informed ISC
>of this other than assuming they track things posted here??

No.  I don't have any real mechanism to report the bug (that I know of).



-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

geoff@ism780c.isc.com (Geoffrey Kimbrough) (07/04/90)

In article <1990Jul03.002938.14866@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
[ reports problem with our new #!interpreter support ]
>
>  I don't have any real mechanism to report the bug (that I know of).
	Consider it reported.

-- 
Geoffrey Kimbrough -- Senior System Therapist
INTERACTIVE Systems Corporation -- A Kodak Company
If your machine can't find ism780c, you're not on the net.
"Every morning I read the obituaries, if I'm not listed, I go to work."

wgb@balkan.tnt.COM (William G. Bunton) (07/04/90)

>>>>> In article <44715@ism780c.isc.com>, geoff@ism780c.isc.com (Geoffrey Kimbrough) writes:

> In article <1990Jul03.002938.14866@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
> [ reports problem with our new #!interpreter support ]
>>
>>  I don't have any real mechanism to report the bug (that I know of).
> 	Consider it reported.

Thank you.  Now, when it's fixed, will we all be notified of what "X?"
disk we should request?

Bill
-- 
William G. Bunton                                        wgb@balkan.tnt.com
Tools & Techniques, Inc. Austin, TX        {cs.utexas.edu,uunet}!balkan!wgb

bill@ssbn.WLK.COM (Bill Kennedy) (07/05/90)

:wgb@balkan.tnt.COM (William G. Bunton) writes:
#geoff@ism780c.isc.com (Geoffrey Kimbrough) writes:

#> In article cpcahil@virtech.UUCP (Conor P. Cahill) writes:
#> [ reports problem with our new #!interpreter support ]
#>>
#>>  I don't have any real mechanism to report the bug (that I know of).
#> 	Consider it reported.
:
:Thank you.  Now, when it's fixed, will we all be notified of what "X?"
:disk we should request?
:-- 
:William G. Bunton                                        wgb@balkan.tnt.com
:Tools & Techniques, Inc. Austin, TX        {cs.utexas.edu,uunet}!balkan!wgb

I think that you will have to produce your RESPONSE/ix agreement for
that.  I don't know whether the X? fix will fall under the $675/yr
or $1500+/yr plan but I'm sure that one or the other will do.

Bill raises an interesting point though.  Heretofore, when technical
support was supposedly available we could call someplace and be told
how to get bug fixes.  Not new releases, extensions, or enhancements,
bug fixes.  Now that this is no longer available (unless I misread
Mr. Alcorn's article), how do we find out?  Worse, how does someone
who doesn't read comp.unix.i386 find out?  Does it become part of the
UNIX oral tradition?
-- 
Bill Kennedy  usenet      {texbell,att,cs.utexas.edu,sun!daver}!ssbn!bill
              internet    bill@ssbn.WLK.COM   or attmail!ssbn!bill

support@ism780c.isc.com (Support account) (07/06/90)

In article <1990Jul04.120639.9148@balkan.TNT.COM> wgb@balkan.tnt.COM (William G. Bunton) writes:
>>>  I don't have any real mechanism to report the bug (that I know of).
>> 	Consider it reported.
>
>Thank you.  Now, when it's fixed, will we all be notified of what "X?"
>disk we should request?
>
That is a good suggestion. We'll announce through the
net whenever there is a new fix disk available (and users should be
notified through their distributors as well). It is probably worth
mentioning, to be pedantic, that obviously not all bugs require  fix disks,
that they will generally only be issued for high severity problems.

Thanks again for the suggestion.


...

news@pegasus.com (0000-Usenet News(0000)) (07/08/90)

>
>Bill raises an interesting point though.  Heretofore, when technical
>support was supposedly available we could call someplace and be told
>how to get bug fixes.  Not new releases, extensions, or enhancements,
>bug fixes.  Now that this is no longer available (unless I misread
>Mr. Alcorn's article), how do we find out?  Worse, how does someone
>who doesn't read comp.unix.i386 find out?  Does it become part of the
>UNIX oral tradition?

No.  I think it's part of the newer ISC tradition:

	"Bend over, here comes the update".


1/2 :-)