Is this a restriction I wasn't aware of or something new (that maybe shouldn't be there)?

[mathewsdw]

First, just so there's no mistake, the following is a very simple and somewhat contrived batch file (named "Sample.btm") to illustrate the issue without dealing with a number of side issues that are completely irrelevant.

  @Echo Off
  SetLocal
  Gosub TestIt
  @Echo Everything is %OK
  EndLocal
  Quit 0
:TestIt
  Set OK=
  Set Result=%@Char[1]
  Set Again=Please
  Do While "%OK" == ""
      @Echo %Again hit any key or hit ENTER to just forget it... >CON:
      InKey  /C /X /W5 %%Result
      Set Again=Again, please
      Iff "%Result" == "@28" Then
        Set OK=Not OK!
        Return
      ElseIff "%Result" != "%@Char[1]" Then
        @Echo `` >CON:
        Set OK=OK
      EndIff
  EndDo
  Return

And here are the (annotated) results of running the above batch file:

  Sun  Apr 29, 2012  10:35:24a
 
ISO8601 plugin v1.2.3 loaded.
SafeChars plugin v1.6.4 loaded.
 
TCC  13.04.61  Windows 7 [Version 6.1.7601]
Copyright 2012 JP Software Inc.  All Rights Reserved
Registered to Daniel Mathews
 
[Z:\]:: I will let it time-out three times and then hit a key that's not ENTER...
[Z:\]Sample
Please hit any key or hit ENTER to just forget it...
Again, please hit any key or hit ENTER to just forget it...
Again, please hit any key or hit ENTER to just forget it...
a
Everything is OK
 
[Z:\]:: This time I will let it time-out twice and then hit ENTER...
[Z:\]Sample
Please hit any key or hit ENTER to just forget it...
Again, please hit any key or hit ENTER to just forget it...
TCC: Z:\Sample.btm [23]  Missing GOSUB
Everything is Not OK!
[Z:\]

This issue as you can hopefully readily see is that the "Return" within the "true" clause of the "Iff" statement within the "Do While" generated an error. Is this the way that it is supposed to work? Is this documented if it is? Is so, where? (Yes, it's got an easy workaround. But I'd still like to understand what is going on here.)

And on the subject of "what is going on here?", just out of curiosity what's with the "@28" returned by "InKey" when a carriage-return is hit? The ASCII code of a carriage return is 0x0d (decimal 13) and for a line-feed is 0x0a (decimal 10) and I can't see any relationship between either of those two values and "@28".

- Dan

 

[vefatica]

Quoting the help (RETURN):

"You cannot execute a RETURN from inside a DO loop."

 

[vefatica]

Quoting the help (RETURN):

"You cannot execute a RETURN from inside a DO loop."

P.S. Change the "Return" to "Leave".

 

[mathewsdw]

Thank you, Vince! (Blindness as always.) - Dan

 

[Charles Dye]

And on the subject of "what is going on here?", just out of curiosity what's with the "@28" returned by "InKey" when a carriage-return is hit? The ASCII code of a carriage return is 0x0d (decimal 13) and for a line-feed is 0x0a (decimal 10) and I can't see any relationship between either of those two values and "@28".

That's from the scan code, not the ASCII value, of the Enter key: scan code 0x1C = decimal 28. (Enter does have an associated ASCII character, but that's not true of all keys; for instance, the F1 - F12 keys don't generate ASCII characters.)

 

[mathewsdw]

Thank you, Charles; that explains it. But an "academic" question: Why not use the ASCII code if it's got one? (You know, the brilliance of the people who post answers on this bulletin board astounds me! :))

 

[Charles Dye]

Thank you, Charles; that explains it. But an "academic" question: Why not use the ASCII code if it's got one?

Obviously the character itself would be difficult to use or test against in a batch file. I guess you could use a decimal or hex representation of the ASCII value; but it would be easy to confuse that with the scan code of some other key. (Scan code 0x0D represents the = key, according to the chart I'm looking at.)

(You know, the brilliance of the people who post answers on this bulletin board astounds me! :))

Me too.

 

[mathewsdw]

Honestly, Charles, as an addendum I would have just used the decimal or hex (actually, the hex) value without even thinking about it. - Dan

 

[Steve Fabian]

Dan:
Going back to your OP, in the code why do you redirect the output of ECHO to the same destination as it would go to without redirection? I.e., the commands
echo x
and
echo x > con:
do exactly the same, albeit the second version requires more steps to do it.

 

[mathewsdw]

Steve, I have to admit that I'm a little bit surprised you asked me that because they do not necessarily go to the same "destination". You see, if you use "Echo ABC" in a batch file, and you run the batch file like: "ABatchFile >&BatchFile'sOutputFile.txt", the results of the "Echo" command go to, of course, "ABatchFile'sOuputFile.txt". However, if you use "Echo ABC >&CON:" the results of the "Echo" command go to the console, period, end of sentence; and can not be redirected in any way (at least in the context of the "Echo" command). Since redirection from standard output is my primary means of capturing the output of batch files because I really dislike the whole specify a file name, file open, file write(s) and file close rigamarole in an "ordinary" batch file; it's a lot of crap (previously mentioned KISS rule) that I just don't want to deal with and redirection from standard error is also quite common; when I want to make sure that a message appears on the console and not in some redirected output file, I use that construction; and it does exactly what I want it to do.

So make yourself a 2-line batch file (called "ABatchFile.btm", for instance) than contains nothing but:

@Echo ABC
@Echo DEF >CON:

And run it like this:

ABatchFIle >&ABatchFile.txt

And you will see exactly what I mean. (The simple truth is that I find the existence of the "pseudo-device" "CON:" to be one of TCC's best features!)

- Dan

 

[mathewsdw]

And Vince, I just noticed your "Change the Return to Leave" comment (somehow I had missed it) and I just have one word describing myself: DUH!!!!!

 

[vefatica]

And Vince, I just noticed your "Change the Return to Leave" comment (somehow I had missed it) and I just have one word describing myself: DUH!!!!!

Of course that works in your particular example because there's a RETURN right after the ENDDO.

 

[mathewsdw]

But Vince, that's exactly why it was a "DUH!!!!!"! You see, I've used that many times in the past when there was a significant amount of code after he "EndDo"; and it just plain didn't occur to me to use it when the only thing after the "EndDo" would be a Return! - Dan

 

[JohnQSmith]

Going back to your OP, in the code why do you redirect the output of ECHO to the same destination as it would go to without redirection?

I was going to ask the same question.

However, if you use "Echo ABC >CON:" the results of the "Echo" command go to the console, period, end of sentence, and can not be redirected in any way (at least in the context of the "Echo" command.)

Awesome! I always love learning something new.

 

[mathewsdw]

I just thought I'd like to add (more than a "little bit", I suppose! ) re "specify a file name, file open, file write(s) and file close" that didn't occur to me and is actually somewhat important. There is a very large reason I don't want to go through all of that rigamarole. You see, for me (for other people this may not be the case) due to my semi-blindness and, probably even more importantly, my bad memory (as I have observed in the past and it is the absolute truth I probably couldn't survive on my own rather being institutionalized without TCC) a substantial number, if not the actual majority, of batch files I write (and, previously, C++ programs) are filters of one kind or another. For instance, I have a "filter" to "rearrange" the "columns" of an input file in a way that is specified as a series of parameters on the command line (columns 20 through 29 become columns 1 through 10, 65 through 79 become column 31 through 45, all other columns are just "dropped"; and another that does essentially the same except that the column "ranges" are replaced by "fields" (i.e., "Field 1", "Field 2", ... "Field N"; where the "fields" are separated by a list of characters selected by the user as parameters to the command (not only just "similar" to the "@Field" function, it uses the "@Field" function internally. I will also not that this command will allow me to "equalize" the lengths of the "fields"; i.e., the second "field" is always 35 characters, blank-padded or truncated on the right as necessary. This is primarily so the output of this batch file can be piped into the standard Windows/DOS "Sort" command); or an "advanced Find" command where only lines that match a (possible series of) patterns are output (similar to regular expressions, of course, but I don't actually use TCC's "regular expressions" because A: Given my bad memory and exposure to a large number of regular expression "languages" in my past history, trying to come up with the proper "regular expression" without thinking about it too much is more effort than I want to make; and B: The kinds of patterns I am typically "looking" for can be readily specified by a much-simplified "regular-expression" syntax that I invented for the purposes for which I use this particular batch file; yes, my "regular expressions" are not nearly as "powerful" as "full" regular expressions, but they are also all I need 95% of the time (I can, if necessary, use "real" "regular expressions if I must. I will also note that some of this stuff was written in C++ before I decided to try to use TCC's batch-file language as close to 100% of the time as I could manage). I also have a fair number of fixed "filters" that were written specifically for one particular task. A good for-example of this is the series of the batch files that I wrote that log on to my bank's website, downloads the transactions, and "merges" the "new" transactions into the running list of transactions that I keep in a fixed-column format. (I will note here that since I also can't write I don't even own a physical check book so there is no check register; I do 100% of my financial transactions either on the web (much preferred) or on the telephone (a distant second) or in person (only when that's actually easier than trying to do it on the telephone), so doing this is much faster and easier (and guaranteed to be more accurate!) than typing this stuff into a text file, for example. And I think you can also see how that batch file could be replaced by (and actually started out as) a series of batch files that rearrange the columns and only retain the records that I am interested in. So, as I indicated previously, since these batch files depend on piping and redirection to be useful, being able to bypass standard output and standard error and write directly to the console is somewhat essential.) (BTW, I had previously figured out a way to do effectively do that in a C++ program, but it was, put simply, a pain in the rear.)

And the primary reason I bring this up is because I think it's quite possible that other people could achieve very good and flexible results by thinking in terms of "filters" of one kind or another.

- Dan

 

[mathewsdw]

A correction: I got to thinking, how did I do that in C++? And my bad memory, not too shockingly here, played a roll. The "pain in the rear" comment was re the way I used to do things in C++ before the I "discovered" the right way to do things in C++ before I switched almost entirely to TCC batch files. So the (very easy!) way to handle this is is to simply use "CON:", of course, as a file name when opening a file in C++, and I would assume other languages. You see, "CON:" is actually a standard Windows "device" (at least after TCC is installed and I have no way to verify if that's the case) and is not peculiar to TCC; cmd.exe also recognizes it and it has the same meaning in cmd.exe as it does in TCC. So "CON:" is a valid "file name"; that is, it can be opened and both read and written by any standard Windows program written in any language that has the ability to "open" files. (However, it can not be opened for concurrent read and write using the same "file handle", although it can be simultaneously opened for both read and for write using two different “file handles”.)

 

[samintz]

I think it was back in the MS-DOS days, but the character devices - e.g. con, nul, prn, etc. - were special reserved names. So a file named nul.txt was the same as nul. I vaguely recall issues with apps like BASIC being able to create badly named files which were impossible for the command prompt (i.e. 4NT) to delete.

But it was possible, IIRC, to do something like:

type mytextfile.txt | 4nt /c con.btm

which allowed 4NT to execute text from stdin as if it were a batch file.