phil@adam.adelaide.edu.au (Phil Kernick) (11/04/90)
I found the following bug in the CLI execute command: > copy * fubar execute test ^\ > copy * test echo "<" ^\ > execute test < > execute fubar EXECUTE: No K directive execute failed returncode 20 > The bug occurs if an execute script containing a '<' anywhere in it (including inside quotes as above, or inside a comment) is called up from another execute script. A simple workaround this is to include the line: .bra ~ at the top of the offending script (in fact any character can be used in the .bra directive, but then must not occur in the script). Has this bug been fixed in 2.0 (this is using 1.3.2)? Phil. -- Phil Kernick EMail: phil@adam.adelaide.edu.au Departmental Engineer Phone: +618 228 5914 Dept. of Psychology Fax: +618 224 0464 University of Adelaide Mail: GPO Box 498 Adelaide SA 5001
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/05/90)
In <phil.657695687@adam.adelaide.edu.au>, phil@adam.adelaide.edu.au (Phil Kernick) writes: >I found the following bug in the CLI execute command: >> copy * fubar >execute test >^\ >> copy * test >echo "<" >^\ >> execute test >< >> execute fubar >EXECUTE: No K directive >execute failed returncode 20 >> > >The bug occurs if an execute script containing a '<' anywhere in it >(including inside quotes as above, or inside a comment) is called up >from another execute script. A simple workaround this is to include >the line: >.bra ~ >at the top of the offending script (in fact any character can be used >in the .bra directive, but then must not occur in the script). > >Has this bug been fixed in 2.0 (this is using 1.3.2)? > >Phil. Gee, I hope they haven't 'fixed' a perfectly good feature. _Some_ character has to delimit an argument. Having an argument delimitershow up in text, how would you treat it, if you were the execute program? -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
bleys@tronsbox.xei.com (Bill Cavanaugh) (11/05/90)
[ description of NO .K DIRECTIVE problem deleted]
That's not a bug, it really IS a feature. Execute thinks that < and >
are supposed to be used around the value passed to a .key , so when it
encounters your redirection (using < again), it gives you an error.
The .bra and .ket commands were put in to allow you to specify your OWN
character to use with .keys... most people seem to like { and }.
/****************************************************************
* All of the above copyright by the below. *
* Bill Cavanaugh uunet!tronsbox!bleys *
* "A language is a dialect with an army and a navy." *
****************************************************************/phil@adam.adelaide.edu.au (Phil Kernick) (11/06/90)
bleys@tronsbox.xei.com (Bill Cavanaugh) writes: >[ description of NO .K DIRECTIVE problem deleted] >That's not a bug, it really IS a feature. Execute thinks that < and > >are supposed to be used around the value passed to a .key , so when it >encounters your redirection (using < again), it gives you an error. >The .bra and .ket commands were put in to allow you to specify your OWN >character to use with .keys... most people seem to like { and }. #pragma FLAME_ON You guys really don't read the postings before wasting net-bandwidth do you? This is about the 3rd post and I have had about 5 email messages saying exactly the same thing, and you are *all* wrong. Go back and look at the original posting I made, notice that if you call the test script directly from the CLI that it behaves as expected, but if called from another script it crashes, even when the < character is inside a quoted string or comment. The parser has a bug in that it parses *everything*, including quoted strings and comments which it should *not* do. The 1.3 docs say that "if you want to include dot commands then the first line of the script must contain a dot command, otherwise no dot commands are looked for" (paraphrased). If you look at the test script you will see that the first line does *not* have a dot command on it, and hence the parser has *no* reason to look for command substitution. In future, if you are going to post a solution to a problem, first read the original post, and then answer the question. #pragma FLAME_OFF Again, will someone with 2.0 please try what I originally posted and tell me if the bug has been fixed. Phil. -- Phil Kernick EMail: phil@adam.adelaide.edu.au Departmental Engineer Phone: +618 228 5914 Dept. of Psychology Fax: +618 224 0464 University of Adelaide Mail: GPO Box 498 Adelaide SA 5001