#46 6.4.2 `batch*` evaluated one command per line

[Batch Job 1]

batch* evaluated one command per line

What happened. A file given to batch*, or to the -f2 command line option that calls it, ran only the first command on each line. The rest were discarded, with nothing reported.

(deffunction say (?x) (printout t "got " ?x crlf))
(say one) (say two) (say three)
(say four)

printed got one and got four.

Why it is a fix and not a preference. The Basic Programming Guide says of batch* that it "evaluates the series of commands stored in the file" and "evaluates all of the commands in the specified file before returning". It evaluated some of them.

Plain batch behaves the same way, and that is left alone: batch works by replacing standard input, so it is line-oriented by construction, and the guide says of the -f option that "a carriage return must be at the end of the command". Only batch* promises to evaluate all of them.

Where it came from. CompleteCommand in commline.c reports a complete command only on reaching a newline:

case '\n' :
case '\r' :
  if (error) return(-1);
  if (moreThanZero && (depth == 0)) return 1;

So BatchStar in fileutil.c gathers a whole line before routing it. RouteCommand then parses one form with Function2Parse, closes the string source, and evaluates that one — so everything after the first form in the gathered text is dropped. Neither function is wrong on its own; together they lose commands.

The change. A new FirstCommandLength in commline.c reports how many characters make up the first complete command in a string, using the same lexical rules as CompleteCommand — DoString for quotes and DoComment for comments, so a parenthesis inside either does not change the nesting depth. BatchStar routes each command in turn rather than the gathered text as a whole.

It sits in commline.c because that is where the lexical rules and their helpers already live; the helpers are static, and duplicating them elsewhere is how two copies of a scanner come to disagree.

What was checked. A parenthesis inside a string, a parenthesis inside a comment, a deffunction and a deftemplate spanning several lines, two asserts on one line, a command after each of those, and unbalanced parentheses.

The reason to care about this one: the shape that triggers it is a plain nested read loop, the shape that evades it is a bind on the line above, and nothing in the diagnostic points at either.

Present in 7.0? Not checked.