An oddity...

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
I wrote a fairly simple batch file that would capture the output of a command supplied by the user as a parameter and put it into an array. (This is done by directing the output of the command into a temporary file which is then read into an array by a "@FileArray" function. Batch file "CaptureCommandOutput.bat" is attached.) The batch file works as expected if the command parameter is a "Dir" command, for instance. However, there is no output if the command is the "Subst" command (and there are subst'd drives on the system). What is even stranger is that the following error message is output twice (there are three subst'd drives in my test situation):

TCC: (Sys) Z:\CaptureCommandOutput.bat [14] Access is denied.
"Z:\Development"

While I don't really need this functionality for the intended use of this code (the @TrueName function handles subst'd drives just fine, I was just testing), I thought it was worth mentioning. I will note two relevant facts: 1. The output of the "Subst" command is being written to the temporary file just fine. (This is indicated by the "type" command that is in the script for testing purposes.) 2. The lines that are the output from the "Subst" command contain ">"'s (greater-than symbols). Since this is used for STDOUT redirection in DOS\TCMD etc., I can't help but wonder if their presence is what is causing the problem. (I made a file with those characters in it and read it by making "Type GreaterThansFile.txt" (also attached) as the parameter; and it doesn't work properly either, although the specific symptoms are somewhat different than when the parameter is the "Subst" command.) Just reporting what is a probably a minor issue. (Assuming that is what the problem is, it is somewhat strange that a batch file can't handle data that contains specific special characters - and this could be a significan problem in some cases.)
 

Attachments

#2
mathewsdw wrote:
...
|2. The
| lines that are the output from the "Subst" command contain ">"'s
| (greater-than symbols). Since this is used for STDOUT redirection in
| DOS\TCMD etc., I can't help but wonder if their presence is what is
| causing the problem.

It is conceivably the problem if you try to process each line of the
file. Use C. Dye's plugin safechars.dll from
http://www.unm.edu/~cdye/dl/safechars.zip - note that array elements are
accessed using the style @safeexp[arrayname[%offset]].
BTW, I do redirect the output of SUBST to a file, and typing the file
usingthe TYPE command never caused a problem.
--
HTH, Steve
 
#4
WAD. Unless you're using the DWIM parser, there's no way for a batch file to know that sometimes you want '>' or '<' for redirection, and sometimes you don't.

If you're outputting text with embedded special characters, you have to protect them somehow (quoting or SETDOS).
Rex, I'll take you word for it (I had already figured out that that was the case; it's just don't completely understand why that's the case for data which isn't (or shouldn't be, as far as I know) being further interpreted (as command(s)). But I'll think about it a little more deeply...
 
#5
It is conceivably the problem if you try to process each line of the file. ... BTW, I do redirect the output of SUBST to a file, and typing the file using the TYPE command never caused a problem.
--
HTH, Steve
Steve, I don't completely understand your answer. It's not the "TYPE" command that's having the problem, it's reading the output of "TYPE" command into an array. And, if I misunderstand you and that is not the problem you're referring to, I'm running Windows 7 and don't know if the output of the SUBST command contained the character sequence "=>" in previous versions of Windows. And Rex (and you, implicitly) did provide an explanation. I'll try Mr. Dye's plugin as soon as I submit this - since this has been a problem for me (and, evidently, Mr. Dye) in other situations in the past. I prefer my languages to mostly not try to parse the data they are processing on their own. (Rex, that's not a significant criticism ; > ) >, your products are great!)
 
#6
mathewsdw wrote:

| ---Quote (Originally by rconn)---
|| WAD. Unless you're using the DWIM parser, there's no way for a batch
|| file to know that sometimes you want '>' or '<' for redirection, and
|| sometimes you don't.
||
|| If you're outputting text with embedded special characters, you have
|| to protect them somehow (quoting or SETDOS).
| ---End Quote---
|
| Rex, I'll take you word for it (I had already figured out that that
| was the case; it's just don't completely understand why that's the
| case for *data* which isn't (or shouldn't be, as far as I know)
| being further interpreted (as command(s)). But I'll think about it a
| little more deeply...

Unfortunately, due to the origin of the language, there is no "data" in
per se in any of the languages derived from that used by the COMMAND.COM of
the original IBM PCs, only commands. It's the reason for the binary buffer
functions available since V10. Those are the only places where the data is
strictly distinguished from command.
--
Steve