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 :-)