#1 >> to a file named by a variable doesn't work

[Lowell Boggs, Jr.]

User Scott C reports:

However, I have noticed at least one issue that I just can't believe was intended, namely how I can't find a way to redirect output to append to a file via the well known ">> FILENAME" at the end of a command that prints to stdout, at least not working when FILENAME itself is saved as a variable, e.g. "ls >> $OUTPUT_FILENAME"

When I try using that, instead of outputting to the filename saved in the "$OUTPUT_FILENAME" variable, it instead outputs to the literal word "$OUTPUT_FILENAME" instead.I discovered that this problem doesn't come up when simply using a single greater-than symbol ">" to do this, which wouldn't be a problem except that I require that my output append to instead of overwriting the output file.

This makes it all the likelier that my inability to use the conventional append format is a bug.FWIW, I was at least able to come up with a somewhat kludge of a workaround by using "tee.exe" from UnxUtils by using "COMMAND | tee -a FILENAME > /dev/null" but I'd still much prefer doing that all internally via pure Brash.exe instead of having to use more external commands than necessary.

[Lowell Boggs, Jr.]

Looks like a bug. I'm looking into it.

[Lowell Boggs, Jr.]

I'm seeing something a little different on my Windows 10 box. When I do this:

file=fred

echo stuff >>$file

I see nothing in file file named fred, but I do see a file named '$file' which now contains stuff.

The results may be different on Windows 7. I won't be able to test that for a while.

This is of course a bug.

Strangely,

echo stuff >$file

Does work. Hopefuly that should make it easier to narrow down.

[Lowell Boggs, Jr.]

cxx/brash/BrashRedirection.cxx has a function that is not correctly expanded the string expression that defines the file name. it is seeing ">>$varname" as a single string literal, not as an expression consisting of ">>" and "$varname".

The parser is found in the cxx/scriptLanguage/include/cxxtls/stringexpressionparser.h.

It needs to be modified so that the >>$var syntax is split into two expression nodes.

[Lowell Boggs, Jr.]

The fix for this problem is already available in version 1.2.16