Bug in the command parser?
Jason Quinn wrote on Sep 04, 2008
I noticed the following:
In general, semi-colons at the end of statements like "dir;" throw a syntax error. Oddly enough, if you put a space after a command like ";dir ; " the behavior changes and no error is thrown but trying "dir;" or "dir ;" or "dir ; " or "dir; " again throws an error.
It seems that semi-colons only work reliably when sandwiched between two commands. The parser, I think (unless there's some detail I'm not considering), should always interpret a semi-colon as part of the preceding statement (with allowances for an empty statement). I've tried building test cases with more complex multi-statements like "dir ;; dir;; ;dir ; dir" and the parser seems robust when the semi-colons are after the first command and before the last. So it seems to me like there's "one-off" style problems with the parser for the first and last commands in a multi-statement.
Jason
ecl> ;dir;
ecl> dir
**: ^
ERROR: syntax error
ecl>
In general, semi-colons at the end of statements like "dir;" throw a syntax error. Oddly enough, if you put a space after a command like ";dir ; " the behavior changes and no error is thrown but trying "dir;" or "dir ;" or "dir ; " or "dir; " again throws an error.
It seems that semi-colons only work reliably when sandwiched between two commands. The parser, I think (unless there's some detail I'm not considering), should always interpret a semi-colon as part of the preceding statement (with allowances for an empty statement). I've tried building test cases with more complex multi-statements like "dir ;; dir;; ;dir ; dir" and the parser seems robust when the semi-colons are after the first command and before the last. So it seems to me like there's "one-off" style problems with the parser for the first and last commands in a multi-statement.
Jason
Mike Fitzpatrick wrote on Sep 04, 2008
Hi Jason,
Sorry for the slow reply. I agree there is a problem here and a quick look suggests it has to do with the way the command-line is parsed interactively. In the CL grammar the ';' is an end-of-stmt however the line doesn't get executed until the newline is seen. For some reason, this commandline is being parsed differently than if the same statements were in a procedure script (I think because of the begin-end block but it's a guess).
I'll put it on the list but unless you convince me otherwise I don't see this as a critical problem just yet. Thanks for the report.
Cheers,
-Mike
Sorry for the slow reply. I agree there is a problem here and a quick look suggests it has to do with the way the command-line is parsed interactively. In the CL grammar the ';' is an end-of-stmt however the line doesn't get executed until the newline is seen. For some reason, this commandline is being parsed differently than if the same statements were in a procedure script (I think because of the begin-end block but it's a guess).
I'll put it on the list but unless you convince me otherwise I don't see this as a critical problem just yet. Thanks for the report.
Cheers,
-Mike
Jason Quinn wrote on Sep 04, 2008
There appears to be a string parsing bug in print and printf such that a string literal cannot start with a right parenthesis.
If there are characters after the quoted right parenthesis, it queries to set a value to a variable.
Besides the bug discussed above, the printf help file would also benefit from these minor changes:
Jason
ecl> print(")")
ERROR: ambiguous parameter `' within `<searchpath>'
called as: `print ())'
ecl>If there are characters after the quoted right parenthesis, it queries to set a value to a variable.
ecl> print(") ")
: ecl> print(")jason")
jason: ecl> string crom
ecl> crom=")Cimmerian God"
ecl> print(crom)
ERROR: parameter `Cimmerian God' not found
ecl> Besides the bug discussed above, the printf help file would also benefit from these minor changes:
- *The format specification should be "%W.DCN" or maybe "%[W][.D]C[N]" is better yet and not just "%w.dCn" if it is to match the rest of the help file (cf. scan help).
*Example #2 should probably not use a VAX example anymore ;-)
*Example #5 The second subexample, has a incorrect slash probably left over from an edit (highlighted red). However the line is fixed, the shown example's output should match the true output exactly.
cl> printf ("RA = %h DEC = %m\Exptime = %8.2f\n",ra,dec,etime)
*At the top, in the NAME and USAGE sections, the three functions should be in the same order. Probably print, printf, fprint makes the most sense.
*fprint is the most foreign idea and should have its own example perhaps with the "bug" text moved there.
*reword the param description to avoid "Fprint" with a capital "F"... perhaps "The fprint command deposits the output string into the value field of this parameter."
*"string" should be added to the see also list.
Jason
Mike Fitzpatrick wrote on Sep 04, 2008
Hi Jason,
The ')' at the beginning of a string is used for parameter indirection, e.g. to redirect a tasks parameter value from the equivalent package parameter. Unfortunately even the output of a function like print() is treated internally as a result parameter, and so the indirection thing kicks in even for literal strings.
In any case, I've fixed this for the next release so that literal strings like ")" and ") test" will be handled correctly, and for strings like ")test" you can escape the paren (e.g. "\)test") to bypass the indirection handling.
As for the help page suggestions, I've made those changes as well.
Thanks,
-Mike
There appears to be a string parsing bug in print and printf such that a string literal cannot start with a right parenthesis.
The ')' at the beginning of a string is used for parameter indirection, e.g. to redirect a tasks parameter value from the equivalent package parameter. Unfortunately even the output of a function like print() is treated internally as a result parameter, and so the indirection thing kicks in even for literal strings.
In any case, I've fixed this for the next release so that literal strings like ")" and ") test" will be handled correctly, and for strings like ")test" you can escape the paren (e.g. "\)test") to bypass the indirection handling.
As for the help page suggestions, I've made those changes as well.
Thanks,
-Mike
Last post on Sep 04, 2008