phoenix@ms.uky.edu (R'ykandar Korra'ti) (07/25/90)
[Line eater? What line ea
Does anybody know what execute means when it says:
EXECUTE: No K directive
execute failed returncode 20
Obviously, 20 means object not of appropriate type. However, the
EXECUTE binary is just fine, and the startup-sequence it fails to execute
is also just fine. I've been running this startup for some months.
Here's the setup:
Boot from floppy with 1.2 ROMS. Floppy startup-sequence mounts dh0:
(attached via WEDGE; it's a 5.2M partition under the OFS), and executes,
successfully, the file dh0:s/startup-transfer. Startup-transfer makes
several assigns - the necessary assigns to make dh0: my SYS: disk - and
then -
execute dh0:s/startup-sequence
Startup-sequence is my normal startup sequence and is never executed.
HOWEVER: if I type "execute dh0:s/startup-sequence" at the CLI prompt
after the error, it executes just fine. (That's how I got the Amy running
so I could make this call.)
This really, really, pi**es me off. I hate things like this. Any help
would be greatly appreciated; reply via netmail and I'll post a summary if
there is interest...
- R'ykandar.
--
| R'ykandar Korra'ti | Editor: LOW ORBIT Science and Fiction | PLink: Skywise |
| Elfinkind, Unite! | phoenix@ms.uky.edu | phoenix%ms.uky.edu@ukcc.bitnet |
| "Hi! We're evangelical Hari-Krishna pedophiles for LaRouche! Would you like |
| to see some of our fine Amway products?" - TRHMS | CIS 72406,370/LOW ORBIT |robin@sabre.austin.ibm.com (Robin D. Wilson/1000000) (07/25/90)
In article <15697@s.ms.uky.edu> phoenix@ms.uky.edu (R'ykandar Korra'ti) writes: >[Line eater? What line ea > > Does anybody know what execute means when it says: > > EXECUTE: No K directive > execute failed returncode 20 I don't know for sure if this is the same thing,.. but when I had this problem the discussion several weeks ago about the: .bra { .ket } being added to the beginning of the script files where shell redirect is used solved my probs. In other words... if you are executing a shell script that has '<' or '>' in them, you need to redefine the braket characters to '{' and '}' so that the script doesn't confuse them with the shell redirects. I ran into this when I modified several startup scripts that had previously worked, but in the new versions of them, I redirected output to >NIL:. This works for me, your luck may be different. +-----------------------------------------------------------------------------+ |The views expressed herein, are the sole responsibility of the typist at hand| +-----------------------------------------------------------------------------+ |UUCP: cs.utexas.edu!ibmchs!auschs!sabre.austin.ibm.com!robin | |USNail: 701 Canyon Bend Dr. | | Pflugerville, TX 78660 | | Home: (512)251-6889 Work: (512)823-4526 | +-----------------------------------------------------------------------------+
rick@tmiuv0.uucp (07/26/90)
In article <15697@s.ms.uky.edu>, phoenix@ms.uky.edu (R'ykandar Korra'ti) writes: > EXECUTE: No K directive > execute failed returncode 20 > Ah, the dreaded "No K directive". Try putting the following two lines in the offending execute script (this has gotten me too): .bra < .ket > All will be fine. I wish CBM could tell us why the bloody thing does this. I had been using the SAME script on my 1000 for about 3 years, then suddenly this crud happens. So I put those two lines in there (the message indicates that the parameter substitution stuff in the script got munged). The script used to run just fine, thank you. I can't see any changes in the script. In fact, a 1-year old backup of the disk does the SAME THING. And the disks are write protected, so they couldn't have been written on. The 1-year old backup hasn't seen the inside of a drive since I made it. In fact, it's lived inside a magnetically shieleded filing cabinet for that time. So, how about it, CBM? Why does execute just spotaneously decide to do this? Can you give us a clue? Huh? Why? > -- > | R'ykandar Korra'ti | Editor: LOW ORBIT Science and Fiction | PLink: Skywise | > | Elfinkind, Unite! | phoenix@ms.uky.edu | phoenix%ms.uky.edu@ukcc.bitnet | > | "Hi! We're evangelical Hari-Krishna pedophiles for LaRouche! Would you like | > | to see some of our fine Amway products?" - TRHMS | CIS 72406,370/LOW ORBIT | -- ---------------------------------------------------------------------------- [- O] Rick Stevens ? EMail: uunet!zardoz!tmiuv0!rick -or- uunet!zardoz!xyclone!sysop V CIS: 75006,1355 (75006.1355@compuserve.com from Internet) "I'm tellin' ya, Valiant! Da whole ting stinks like yesterday's diapers!" - Baby Herman in "Who Framed Roger Rabbit" ----------------------------------------------------------------------------
a217@mindlink.UUCP (Vincent Lim) (07/27/90)
> In article <3612@tmiuv0.uucp>, rick@tmiuv0.uucp (Rick Stevens) writes: > In article <15697@s.ms.uky.edu>, phoenix@ms.uky.edu (R'ykandar Korra'ti) > writes: > > > EXECUTE: No K directive > > execute failed returncode 20 > > > > Ah, the dreaded "No K directive". Try putting the following two lines in the > offending execute script (this has gotten me too): > > .bra < > .ket > > > All will be fine. I wish CBM could tell us why the bloody thing does this. I'm not CBM but I do have an observation which I'd like to share. I've noticed that if your script performs an Execute and you have no T: directory assigned and no SYS:t directory exists or is not writable then you will get the bogus error message above. What seems to happen is that the new script to be Executed cannot be copied into T: and so the Execute command bombs. I've observed this behaviour on my system and it goes away if you have T: assigned somewhere writable before Executing another script file from within a script file. > --------------------------------------------------------------------- --- > [- O] Rick Stevens > ? EMail: uunet!zardoz!tmiuv0!rick -or- uunet!zardoz!xyclone!sysop > V CIS: 75006,1355 (75006.1355@compuserve.com from Internet) > > "I'm tellin' ya, Valiant! Da whole ting stinks like yesterday's diapers!" > - Baby Herman in "Who Framed Roger Rabbit" > ----------------------------------------------------------------------- -- -- --- //\migaTrek: The First Generation, Captain of CBM-A1000 "Advantage" \X/incent Lim, Librarian for Pacific Northwest Amiga Association Smartmail: vlim@undergrad.cs.ubc.ca a217@mindlink.uucp Dumbmail: ...!uunet!van-bc!rsoft!mindlink!a217
wfh58@leah.Albany.Edu (William F. Hammond) (07/28/90)
In article <2649@mindlink.UUCP> a217@mindlink.UUCP (Vincent Lim) writes: > ... >> > EXECUTE: No K directive >> Ah, the dreaded "No K directive". Try putting the following two lines in >> .bra < >> .ket > > ... >I'm not CBM but I do have an observation which I'd like to share. I've noticed >that if your script performs an Execute and you have no T: directory assigned >and no SYS:t directory exists or is not writable then you will get the bogus My versions of "execute", both standard and ARP, attempt to create a "T" directory in the root above the current directory. (Additionally, ARP's "execute" will assign "T:" to it.) I am unable to provoke a "no K directive" message by eliminating ":T" and "T:". My suspicion is that the message is triggered by the appearance in the script of both the '>' and '<' characters for input/output diversion. Since these are the default "bra" and "ket" characters, "execute" is yelling about the absence of a ".key" at the top of the script. For this most of the time redefining the "bra" and "ket" characters will take care of the problem. ---------------------------------------------------------------------- William F. Hammond Dept. of Mathematics & Statistics 518-442-4625 SUNYA, Albany, NY 12222 wfh58@leah.albany.edu wfh58@albnyvms.bitnet ----------------------------------------------------------------------
rick@tmiuv0.uucp (07/30/90)
In article <3413@leah.Albany.Edu>, wfh58@leah.Albany.Edu (William F. Hammond) writes: > In article <2649@mindlink.UUCP> a217@mindlink.UUCP (Vincent Lim) writes: >> ... >>> > EXECUTE: No K directive >>> Ah, the dreaded "No K directive". Try putting the following two lines in >>> .bra < >>> .ket > >> ... >>I'm not CBM but I do have an observation which I'd like to share. I've noticed >>that if your script performs an Execute and you have no T: directory assigned >>and no SYS:t directory exists or is not writable then you will get the bogus > My versions of "execute", both standard and ARP, attempt to create a "T" > directory in the root above the current directory. (Additionally, ARP's > "execute" will assign "T:" to it.) I am unable to provoke a "no K directive" > message by eliminating ":T" and "T:". > My suspicion is that the message is triggered by the appearance in the > script of both the '>' and '<' characters for input/output diversion. Since > these are the default "bra" and "ket" characters, "execute" is yelling about > the absence of a ".key" at the top of the script. For this most of the time > redefining the "bra" and "ket" characters will take care of the problem. > ---------------------------------------------------------------------- > William F. Hammond Dept. of Mathematics & Statistics > 518-442-4625 SUNYA, Albany, NY 12222 > wfh58@leah.albany.edu wfh58@albnyvms.bitnet > ---------------------------------------------------------------------- I don't mean to include all this stuff, but background is necessary. Bill, that still doesn't explain why the SAME disk that's worked for God- knows-how-long suddenly stops. I've used the same beblistered disk for over a year, and suddenly it stopped working. The disk is fine, no bugaboos on it (it's only used to boot), but she dinna wanna work no more. Strange, eh? I'm sure stumped. ---------------------------------------------------------------------------- [- O] Rick Stevens ? EMail: uunet!zardoz!tmiuv0!rick -or- uunet!zardoz!xyclone!sysop V CIS: 75006,1355 (75006.1355@compuserve.com from Internet) "A fertsneet without a gleekzorp is like a quobble without a fromm (sort of)" ----------------------------------------------------------------------------
bleys@tronsbox.xei.com (Bill Cavanaugh) (08/01/90)
[stuff about .bra and .ket deleted] >Bill, that still doesn't explain why the SAME disk that's worked for God- >knows-how-long suddenly stops. I've used the same beblistered disk for >over a year, and suddenly it stopped working. The disk is fine, no bugaboos >on it (it's only used to boot), but she dinna wanna work no more. Strange, >eh? I'm sure stumped. >---------------------------------------------------------------------------- >[- O] Rick Stevens > ? EMail: uunet!zardoz!tmiuv0!rick -or- uunet!zardoz!xyclone!sysop > V CIS: 75006,1355 (75006.1355@compuserve.com from Internet) > >"A fertsneet without a gleekzorp is like a quobble without a fromm (sort of)" >---------------------------------------------------------------------------- I had the same thing happen, and I traced it down to the fact that I'd changed the ourder of a couple of scripts and programs that were in the startup chain. For some reason, after changing them, conman wasn't in place quick enough to take the input, old faithful con: took it, and got confused. I included the .bra { and .ket } statements and everything has run along smoothly ever since... /******************************************************************** * All of the above copyright by the below. * * Bill Cavanaugh uunet!tronsbox!bleys * * "You can only be young once, but you can be immature forever." * * Larry Anderson * ********************************************************************/