I'm not so much concerned with this one particular situation, I'm more concerned with similar things happening in the future. And it is basically totally besides the point as to what I was trying to do and why I was trying to do it when I encountered this problem (suffice it to say that it was yet another effort in my attempt to replace writing C++ programs by writing batch files whenever possible). So I was able to completely "isolate" the problem into an input file and create a batch file that behaved I think it's safe to say very badly when reading said file and echoing it out to the console. So here is the complete contents of the file "Line701.txt":
And here is a very simple batch file that reads that file and echos its output to the console:
And here are the results of executing that batch file:
Just to be clear about what you are seeing sbove, running that batch file opens a new TCC session within the existing TCC session, complains about a "command" named "Software", and then stops. At that point I execute an "exit" command, and the batch file continue on to completion.
I'm quite sure that the problem is because the line contains an ampersand ("&"). And I can, I'm quite sure, take however much time it takes to find and rename every file and directory on my system that has an ampersand in it to replace the ampersand by the word "and", for instance. But I really find that to be a somewhat less-than-satisfactory "solution".
So I can, as per somebody else's suggestion on this bulletin board, change the line "Set Line=%@FileRead[%Handle]" to "Set Line="%@FileRead[%Handle]"" (i. e., surround the @FileRead function by double quotes). And that does work to a degree in the sense that the "problem" no longer occurs, but the output lines are, unfortunately, surrounded by double quotes, which I absolutely do not want. And replacing the "@SafeEcho %Line" by "@SafeEcho %@UnQuote[%Line]" not too surprisingly just causes the problem to re-occur. "SafeLine" is not able to handle the ampersand, either.
And so I tried another of Charles Dye's SafeChars capabilities to "work around" this issue, but to no avail. Specifically, I put a "UnSafe /D:^&" at the top of the batch file, and a "UnSafe /R" line at the bottom. (Note the caret ("^") preceding the ampersand.) This did no good whatsoever. (Clearly SafeChars can not handle ampersands at the present time, period, which kind of surprises me particularly since "SafeChars" has the "%_AMP: (safe ampersand) character. Is this because I'm using ASCII and not UNICODE?)
And, finally, replacing "Set Line=%@FileRead[%Handle]" by "Set Line=%@Replace[^&,ampersand,%@FileRead[%Handle]]" does also "work around" the problem, but at the "cost" of mangling the file or directory name.
So is this the "end of the line" and I'm just plain "out of luck"? I hope that that is not the case, but I kind of suspect that it is...
HTML:
JPSoft Take Command & TCC Software Development Kit
Code:
@Echo Off
Set Handle=%@FileOpen[Line701.txt,r,t]
Set Line=%@FileRead[%Handle]
@SafeEcho %Line
Echo %@FileClose[%Handle] >NUL:
@Echo Done!
HTML:
Fri Oct 7, 2011 12:33:02a
[Z:\]TestIt
TCC 12.11.74 Windows 7 [Version 6.1.7601]
Copyright 2011 Rex Conn & JP Software Inc. All Rights Reserved
Registered to Daniel Mathews
TCC: Unknown command "Software"
[Z:\]exit
JPSoft Take Command
Done!
[Z:\]
I'm quite sure that the problem is because the line contains an ampersand ("&"). And I can, I'm quite sure, take however much time it takes to find and rename every file and directory on my system that has an ampersand in it to replace the ampersand by the word "and", for instance. But I really find that to be a somewhat less-than-satisfactory "solution".
So I can, as per somebody else's suggestion on this bulletin board, change the line "Set Line=%@FileRead[%Handle]" to "Set Line="%@FileRead[%Handle]"" (i. e., surround the @FileRead function by double quotes). And that does work to a degree in the sense that the "problem" no longer occurs, but the output lines are, unfortunately, surrounded by double quotes, which I absolutely do not want. And replacing the "@SafeEcho %Line" by "@SafeEcho %@UnQuote[%Line]" not too surprisingly just causes the problem to re-occur. "SafeLine" is not able to handle the ampersand, either.
And so I tried another of Charles Dye's SafeChars capabilities to "work around" this issue, but to no avail. Specifically, I put a "UnSafe /D:^&" at the top of the batch file, and a "UnSafe /R" line at the bottom. (Note the caret ("^") preceding the ampersand.) This did no good whatsoever. (Clearly SafeChars can not handle ampersands at the present time, period, which kind of surprises me particularly since "SafeChars" has the "%_AMP: (safe ampersand) character. Is this because I'm using ASCII and not UNICODE?)
And, finally, replacing "Set Line=%@FileRead[%Handle]" by "Set Line=%@Replace[^&,ampersand,%@FileRead[%Handle]]" does also "work around" the problem, but at the "cost" of mangling the file or directory name.
So is this the "end of the line" and I'm just plain "out of luck"? I hope that that is not the case, but I kind of suspect that it is...