Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

What can I do to "word around" this problem?

May
855
0
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":
HTML:
JPSoft Take Command & TCC Software Development Kit
And here is a very simple batch file that reads that file and echos its output to the console:
Code:
@Echo Off
Set Handle=%@FileOpen[Line701.txt,r,t]
Set Line=%@FileRead[%Handle]
@SafeEcho %Line
Echo %@FileClose[%Handle] >NUL:
@Echo Done!
And here are the results of executing that batch file:
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:\]
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...
 
So here is the complete contents of the file "Line701.txt":

HTML:
JPSoft Take Command & TCC Software Development Kit

And here is a very simple batch file that reads that file and echos its output to the console:

Code:
@Echo Off
Set Handle=%@FileOpen[Line701.txt,r,t]
Set Line=%@FileRead[%Handle]
@SafeEcho %Line
Echo %@FileClose[%Handle] >NUL:
@Echo Done!

You want to use @SAFEREAD instead of @FILEREAD.
 
You want to use @SAFEREAD instead of @FILEREAD.
Charles, you are of course, correct, but the included batch file was just a made-up "sample" to "illustrate" the problem completely out of the context in which it was occurring (a much-longer batch file). But your suggestion did trigger my (bad as usual) memory about the existence of your "@SafeExp" function, which I haven't actually tried yet but I am 99.9% sure will "fix" the problem. (Said with a bit of humor, if you had named it "@SafeExpr" instead of "@SafeExp", I would have remembered it/what it does even with my bad memory!) But thank you again!!!! Your SafeChars was a major enhancement to TCC.

=============================================================

Charles, I don't understand this at all, but "@SafeExp" absolutely did not work! Same "symptoms" as before, a "new" TCC sub-session is started that I have to "exit" out of. More than anything else, the question is why not?

=============================================================

Well, the above did not work because I was trying to do the "@SafeExp" in place, i.e.:

Set Array[%Index]=%@SafeExp[%Array[%Index]]

However, just for the heck of it I tried:

Set NewArray[%Index]=%@SafeExp[%Array[%Index]]

and that did, in fact, work. I have no clue as to why the "in-place" version did not work, but I don't really care. Thank you again, Charles!
 
You've already recently been told of the necessity of quoting:
Set Line="%@FileRead[%Handle]"
Thank you for your response, but as I thought I indicated in my original posting, quotes around the data were absolutely not an acceptable solution to "work around" the problem (in fact, it would have been the absolutely worst of all of the ways I could think of).

However, Charles Dye suggested a "work around" using his SafeChars "plugin", and while that did not work in the most "straightforward" way, after applying a rather-simple modification to his suggestion I got it to work. I thank Charles for his plugin very much, it provides a virtually complete work-around for the only significant "limitation" that I am aware the TCC batch-file language has. I highly recommend installing and using his plugin!!!
 
Well, the above did not work because I was trying to do the "@SafeExp" in place, i.e.:

Set Array[%Index]=%@SafeExp[%Array[%Index]]

Try leaving off the first percent sign in @SAFEEXP's argument:

Code:
Set Array[%Index]=%@SafeExp[Array[%Index]]

This way, TCC does not expand the variable before my function sees it.
 
Thank you for your response, but as I thought I indicated in my original posting, quotes around the data were absolutely not an acceptable solution to "work around" the problem (in fact, it would have been the absolutely worst of all of the ways I could think of).

Is there any reason why you read only the first line of my two-line response? Just read it again and you'll see that you don't need a plugin to "work around" non-existing problems.
 
Is there any reason why you read only the first line of my two-line response? Just read it again and you'll see that you don't need a plugin to "work around" non-existing problems.
The first question is "why do you think I read only the first line of your response?" Here is the complete response that you are referring to:
You've already recently been told of the necessity of quoting:
Set Line="%@FileRead[%Handle]"
And the second line, the one you evidently think I missed, is, of course, to just put the "@FileRead" function in double quotes.

<!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:PunctuationKerning/> <w:ValidateAgainstSchemas/> <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid> <w:IgnoreMixedContent>false</w:IgnoreMixedContent> <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText> <w:Compatibility> <w:BreakWrappedTables/> <w:SnapToGridInCell/> <w:WrapTextWithPunct/> <w:UseAsianBreakRules/> <w:DontGrowAutofit/> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--><!--[if gte mso 9]><xml> <w:LatentStyles DefLockedState="false" LatentStyleCount="156"> </w:LatentStyles> </xml><![endif]--><!--[if gte mso 10]> <style> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;} </style> <![endif]--> I have to admit, my friend, that I really don't understand why you don't understand why this is (or maybe was is a better word) a significant problem for me; you see you completely missed not one but two important points (and I will amply document both points below). The first point, which is just really irritating in the sense that I would have to alter my many years of "habits" is that putting the input line in double quotes alters the final results of many of the string-manipulation functions (@Len, @Left, @Right, @Instr, @Index, possibly others; these functions treat double quotes basically the same way as any other "valid" character - and that means, in particular, that I would also have to use yet another function to "strip off" the double quote at the beginning of the returned data if I was using the "@Left" function, for instance) that are used to "parse" the input line. The second point, which is where the complete unacceptability to me comes in, is that the only way that I am aware of to actually successfully "Echo" (not "SafeEcho", thankfully) the data to standard output is to again wrap the data in double quotes on output, and the double quotes therefore appear in the output; and, again, this was the part that I found totally unacceptable for my purposes. Now the "second" problem can be totally avoided by using the "SafeEcho" command to output the data, but if I'm going to use that function, why wouldn't I also use the "@SafeLine" and "@SafeRead" and "@SafeExp" functions to completely avoid all of the problem(s) in the first place?

And to illustrate these points, below is a very trivial batch file which completely demonstrates the above.
Code:
  @Echo Off
  SetLocal
  Gosub ShowThem ABCDEF
  @Echo ``
  Gosub ShowThem "ABCDEF"
  @Echo ``
  Gosub ShowThem "A & F"
  EndLocal
  Quit 0
  :ShowThem [String]
     @Echo                       %%String: %String
     @Echo            %%@UnQuote[%%String]: %@UnQuote[%String]
     @Echo                %%@Len[%%String]: %@Len[%String]
     @Echo             %%@Left[1,%%String]: %@Left[1,%String]
     @Echo            %%@Right[1,%%String]: %@Right[1,%String]
     @Echo          %%@Instr[1,2,%%String]: %@Instr[1,2,%String]
     @Echo          %%@Index[%%String,C,1]: %@Index[%String,C,1]
     Return
And here is the output of said batch file:
HTML:
                        %String: ABCDEF
             %@UnQuote[%String]: ABCDEF
                 %@Len[%String]: 6
              %@Left[1,%String]: A
             %@Right[1,%String]: F
           %@Instr[1,2,%String]: BC
           %@Index[%String,C,1]: 2
   
                        %String: "ABCDEF"
             %@UnQuote[%String]: ABCDEF
                 %@Len[%String]: 8
              %@Left[1,%String]: "
             %@Right[1,%String]: "
           %@Instr[1,2,%String]: AB
           %@Index[%String,C,1]: 3
   
                        %String: "A & BCDEF"
             %@UnQuote[%String]: A
  TCC: Z:\QuoteTest.btm [12]  Unknown command "F"
                 %@Len[%String]: 7
              %@Left[1,%String]: "
             %@Right[1,%String]: "
           %@Instr[1,2,%String]: A
           %@Index[%String,C,1]: 6
Please take note of "TCC: Z:\QuoteTest.btm [12] Unknown command "F""!

Again, the double quotes on the output data are not acceptable, and they are, as far as I know, unavoidable without using the SafeChars plugin.

Now I will be the first to admit that there is another alternative. And that is simply to open an output file and write the output to that with the @FileWrite function. I won't show the (very simple) code here because, simply put, that works in that it does, in fact, completely avoid the issue altogether. However, both my strong bias and particular needs in the situation at hand is that I want to be able to pipe the outputs of my batch files to other commands, and I know of no way to do that when writing the output to a file. (I know that something referred to as “named pipes” exist; but I don’t really know what they are or how they would apply in this case, and I have absolutely no reason to care.)

And that is because the “SafeChars” plugin both exists and meets my needs perfectly, Therefore I, of course, have no need to “investigate” named pipes any further.
 

Similar threads

Back
Top