jason@ziebmef.uucp (Jason Gould) (01/07/89)
Hi there. I keep on getting these very aggrivating errors in 1.3's
Execute command. Whenever I try to Execute a script in the middle of a
script currently being executed, I always get an error message that says
"EXECUTE: No K directive" and the script fails.
I also got the same message when I once added another alias into
s:Shell-Startup, but it returned to normal as soon as I took it out.
I would really appreciate it if someone would be kind enough to explain
to me why this happens, and what "No K directive" really means.
Thanks in advance.
--
Jason Gould uunet!utgpu!{ontmoh!moore,ncrcan}!ziebmef!jason
jason@ziebmef.UUCP ENVOY 100: JASON.Gsirius@well.UUCP (Mike Stilson) (01/10/89)
In article <1989Jan6.183818.19500@ziebmef.uucp> jason@ziebmef.uucp (Jason Gould) writes: >Execute command. Whenever I try to Execute a script in the middle of a >script currently being executed, I always get an error message that says >"EXECUTE: No K directive" and the script fails. I believe this error comes about when you send an argument to the script file that it wasn't expecting. I got that same error, and for a workaround I put '.key fubar' as the first line in the second script file. Don't know what it is passing, however, when I did 'echo <fubar>' it didn't print anything out (that I could see, anyhow). >Jason Gould -- ____ / / / Amiga 1000 | Mike "Sirius" Stilson - Sirius Software / / / The Machine | 1312 Universal Rd. Penn Hills, PA 15235 ____ / / / That Made It | (412) 793-1242 \ \ \/ / / Possible! | \ \/ / / -- | UUCP: sirius@well.UUCP \/_/_/ First! | or: {sun,uunet!portal}!cup.portal.com!sirius
rap@ardent.UUCP (Rob Peck) (01/11/89)
In article <10291@well.UUCP>, sirius@well.UUCP (Mike Stilson) writes: > In article <1989Jan6.183818.19500@ziebmef.uucp> jason@ziebmef.uucp (Jason Gould) writes: > >Execute command. Whenever I try to Execute a script in the middle of a > >script currently being executed, I always get an error message that says > >"EXECUTE: No K directive" and the script fails. > > I believe this error comes about when you send an argument to the script > file that it wasn't expecting. I got that same error, and for a workaround > I put '.key fubar' as the first line in the second script file. Don't > know what it is passing, however, when I did 'echo <fubar>' it didn't print > anything out (that I could see, anyhow). I encountered this myself yesterday. It seems to be related to the use of the bracket characters in the second file. If there are any brackets used in that second file, then EXECUTE seems to want to have been warned that there was a possibility of parameter substitution. When it encounters a string that includes "<anything>", it seems to use that message to say "Hey, you didnt tell me I was expected to substitute anything!!!". The workaround suggested works fine (for me too). Null parameter passing results in null-string substitution and avoids the error. What ->I<- discovered besides this yesterday is that environment variables don't get expanded inside the quotes of an ECHO command: 1> SETENV item some-string 1> ED ram:test ECHO "Gonna print the value of item:" GETENV item ECHO "Now from inside the string, item is: $item" ECHO "Now checking normal use of environ var." IF "some-string" EQ $item ECHO "Value of item is: some-string" ELSE ECHO "Value of item not as expected" ENDIF 1> EXECUTE ram:test Gonna print the value of item: some-string Now from inside the string, item is: $item Now checking normal use of environ var. Value of item is: some-string Unfortunately, I have NOT checked whether IF "some-string" EQ "$item" works or not. HMMMMM. Rob Peck
cjp@antique.UUCP (Charles Poirier) (01/11/89)
It sounds like Execute is interpreting a pair of IO redirection
commands as a single keyword substitution command, as in
Run <nil:> nil: whatever
Didn't someone claim that the decision to overload < and > was
deliberate? Fooey. There are lots of ugly ASCII characters you
could've used for parameter substitution that no sane person would put
in a filename. Chalk up another wart.
--
Charles Poirier (decvax,ucbvax,mcnc,attmail)!vax135!cjp
"Docking complete... Docking complete... Docking complete..."andy@cbmvax.UUCP (Andy Finkel) (01/11/89)
In article <2497@antique.UUCP> vax135!cjp (Charles Poirier) writes: >It sounds like Execute is interpreting a pair of IO redirection >commands as a single keyword substitution command, as in > Run <nil:> nil: whatever >Didn't someone claim that the decision to overload < and > was >deliberate? Fooey. There are lots of ugly ASCII characters you >could've used for parameter substitution that no sane person would put >in a filename. Chalk up another wart. Nope; what I stated was that the decision to *leave it the way it was* was deliberate. The decision was made long ago. For 1.3 I thought about changing it, and found that it couldn't be done in a nice manner... if the <> became only redirection characters suddenly, what about all those scripts that were using the <> as variable delimiters ? It would become possible for those files to suddenly start creating lots of funny little files where variable substitution used to take place. So I left it alone. (BTW, if I'd been able to make the change, I'd have leaned towards using the { and } as the default variable delimiters...and I think that the curly braces are among the prettiest ASCII characters. :-) The only character I've never seen in a filename is the / :-) :-) -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Possibly this is a new usage of the word 'compatible' with which I was previously unfamiliar" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) (01/13/89)
In article <2497@antique.UUCP> vax135!cjp (Charles Poirier) writes: >It sounds like Execute is interpreting a pair of IO redirection >commands as a single keyword substitution command, as in > Run <nil:> nil: whatever In article <5661@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >Nope; what I stated was that the decision to *leave it the way it was* >was deliberate. How come nobody has mentioned .BRA and .KET yet? It should be standard practice to use them if your script does redirection. [BTW, .BRA and .KET reassign the < and > characters when used to enclose variables. The name is obviously taken from physicists' parlance. I wonder whether it influenced the seclection of characters: <x| is ``bra'' and |y> is ``ket'' with this terminology.] -- It is the man not the method that Nath solves the problem. vkr@osupyr.mast.ohio-state.edu -Poincare. (614)-366-9341
rap@ardent.UUCP (Rob Peck) (01/14/89)
In article <1180@osupyr.mast.ohio-state.edu>, vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) writes: > > How come nobody has mentioned .BRA and .KET yet? It should be standard > practice to use them if your script does redirection. > > [BTW, .BRA and .KET reassign the < and > characters when used to enclose > variables. The name is obviously taken from physicists' parlance. I wonder.. I chose to explain the choice of the words this way, and nobody has come forward thusfar to say that my own interpretation of history is incorrect... (From memory...cause the book is not nearby)... .BRA is used to redefine the lefthand character that is used to enclose variables for EXECUTE scripts, and .KET is used to redefine the righthand character used for enclosing variables for EXECUTE scripts. If you notice, when you combine these two names together, they form the word "BRAKET" which is close enough (for me at least) to remind me that the characters that these commands redefine form a 'bracket' that encloses a variable. Maybe I am wrong, but it seemed to be a good memory device that I could give to a new user who was trying to learn what script commands were all about. Rob Peck
cjp@antique.UUCP (Charles Poirier) (01/20/89)
In article <5661@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: <In article <2497@antique.UUCP> vax135!cjp (Charles Poirier) writes: <>Didn't someone claim that the decision to overload < and > was deliberate? <Nope; what I stated was that the decision to *leave it the way it was* <was deliberate.... <It would become possible for those files to suddenly start creating <lots of funny little files where variable substitution used to take place. mumble grumble ... Ok, good point. -- Charles Poirier (decvax,ucbvax,mcnc,attmail)!vax135!cjp "Docking complete... Docking complete... Docking complete..."