Welcome!

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

SignUp Now!

Reading stdin...

May
855
0
This is such a basic question that I might feel stupid when I get the answer, but in a C/C++ program (my primary language, besides TCC batch programs, is C++) there are multiple ways to read from stdin - several functions that read from stdin implicitly, and stdin in C++ is just a pointer to a C++ "FILE" structure, so it can be used in any function that takes a pointer to a file structure as a parameter (although that's not generally useful). I use stdin and stdout a lot in the programs that I write; that's because I want most of the programs that I write (but by no means all...) to be usable in a sequence of "piped" commands, i.e. "Program1 | Program2 | ... | ProgramN | List", for example. I would like to be able to use TCC "batch" programs as one (or more!) of the programs in the above sequence (rather than writing a C++ program), and while I know how to make a batch file write to stdout (the various forms of the "echo" command), I have no idea whatsoever how to do an analogous thing for stdin, and searching the Take Command/TCC "help system" and this site did not give me any clues. Do I want to do something that quite simply can't be done in a TCC batch file??? (I would be quite surprised if the answer was "yes"; quite simply put, the TCC batch file language provides more "bang for the buck" than any other procedural language that I have ever used, and I have used many different procedural languages because I've been in this business for almost 40 years!)
 
---- Original Message ----
From: mathewsdw
Subject: [Support-t-2801] Reading stdin...
---- End Original Message ----

Type "help pipes" at the TCC command prompt, and it will open your eyes!

Many commands can read data from STDIN (some, e.g., LIST, may need a special option).
--
HTH, Steve
 
Here's one approach:

Code:
@echo off
setlocal
set i=0

do line in @con:
   echo Line %@format[3,%i]: %line
   set i=%@inc[%i]
enddo

endlocal

Note that TCC isn't really a programming language; it's a command shell, and you will get into trouble if the input text contains special characters like percent signs, ampersands, greater-than and less-than signs, and so on. SETDOS can help you work around some such issues. This may also be useful: http://www.unm.edu/~cdye/plugins/safechars.html
 
Here's one approach:

Code:
@echo off
setlocal
set i=0

do line in @con:
   echo Line %@format[3,%i]: %line
   set i=%@inc[%i]
enddo

endlocal
Note that TCC isn't really a programming language; it's a command shell, and you will get into trouble if the input text contains special characters like percent signs, ampersands, greater-than and less-than signs, and so on. SETDOS can help you work around some /such issues. This may also be useful: http://www.unm.edu/~cdye/plugins/safechars.html
Charles, thank you for your response!!! That does (almost!!!!) completely work when the input is coming from a file or a pipe. (Which kind of surprises me, because I would have guessed that "@con:" was an actual device, and therefore could not be replaced by input from a file or the output of a "pipe").

But the reason for the "(almost) completely" qualifier is that it does not, in my opinion, work "completely" in two different ways (one of which I find to just be very strange, the other of which just essentially makes the technique useless!!!!) when the input is coming from one of two other sources, one of which goes to the very heart of its intended use:

To list these two situations:

1. (The just plain "strange" one) If I redirect the input of the command from the .btm file itself, the <cn.btm"><cn.btm") the="">response is:

Line 0: @echo off
...
Line 4: do line in @con:
(after a relatively long wait:)
TCC: Z:\cn.btm [6] Command line too long
Line 6: set i=7
...
Line 9: endlocal

I imagine this is some kind of recursion, but I have to admit I don't completely understand this...

2. Just the command "cn" getting its input from the actual console:

[input something...]
[output same thing]
[input something...]
[output same thing]
...
[input something...]
[output same thing]
Ctrl-Z

Ctrl-Z

...
Ctrl-C

TCC session immediately terminates without notice. (I.E, the TCC window completely disappears.)

This makes this technique somewhat less than useful for the purposes for which I intended to use these .btm files.

</cn.btm")></cn.btm">As far as "TCC isn't really a programming language; it's a command shell" goes, while you are technically correct, it is such a powerful language in general that that distinction is almost (but obviously not completely) irrelevant. (I will note that I have turned a fair number of TCC capabilities into general functions that I can call from a C++ program. Examples are: AddCommas, EXISTS, ExceptionHandling..., GetValidResponse, ResolveDirectoryJunctionOrSymbolicLink, TrueTrueName, WildCardMatch (using TCC syntax), and possibly others that I don't remember...)
<cn.btm"><cn.btm") the="">
And finally, two almost unrelated but again really rather strange things:

The command "Notepad con.btm" yields a new instance of Notepad with a message box that states (and I quote) "The handle is invalid"!

So if after dismissing that "message box" you enter some text into the now "Untitled" Notepad window and then try to save the resulting file to "con.btm", you get still another (even stranger!!!!) message box: con.btm - This file name is reserved for use by Windows. Choose another name and try again.

Further rather "strange" (but no longer really surprising) things along the same line:

ren cn.btm con.btm
Z:\cn.btm -> Z:\con.btm
TCC: (Sys) Cannot create a file when that file already exists.
"Z:\cn.btm"
0 files renamed 1 failed

dir con.btm

Volume in drive Z is RAM disk Serial number is ...
TCC: (Sys) The system cannot find the file specified.
"Z:\con.btm"
0 bytes in 0 files and 0 dirs
193,519,616 bytes free

Well, I guess that's enough for now...
</cn.btm")></cn.btm">
 
---- Original Message ----
From: mathewsdw
Subject: [Support-t-2801] Reading stdin...
---- End Original Message ----

Type "help pipes" at the TCC command prompt, and it will open your eyes!

Many commands can read data from STDIN (some, e.g., LIST, may need a special option).
--
HTH, Steve
Thank you for your response, Steve but I am(/was) quite familiar with the contents of that "help" page and what it contains and the problem is that it (and you) entirely misses the point. I do not want to execute a particular command once for every line in "stdin" (however that would even be defined in this instance, after all, the internal name of an input source used in an "executable object" from outside of that "object" is completely irrelevant to users of that "object"). The difference is that I want my "object" to be able to read lines from a particular source (again, what is called "stdin" in at least some other programming languages in my case) and perform "correlations" between them.
 
To list these two situations:

1. (The just plain "strange" one) If I redirect the input of the command from the .btm file itself, the <cn.btm"><cn.btm") the="">response is:

Line 0: @echo off
...
Line 4: do line in @con:
(after a relatively long wait:)
TCC: Z:\cn.btm [6] Command line too long
Line 6: set i=7
...
Line 9: endlocal

I imagine this is some kind of recursion, but I have to admit I don't completely understand this...

Note that it's gorking on a line containing a percent sign. TCC examines the input line, finds a percent sign, expands the variable... finds a percent sign in the new value, expands it... finds a percent sign in the new value, expands it... finds a percent sign, expands it.... Eventually the line overflows the command-line buffer and everything goes blooey.

SETDOS /X is one (rather clumsy) way of coping with this kind of thing:

Code:
@echo off
setlocal
setdos /x-456
set i=0

do line in @con:
   echo Line %@format[3,%i]: %line
   set i=%@inc[%i]
enddo

endlocal

2. Just the command "cn" getting its input from the actual console:

[input something...]
[output same thing]
[input something...]
[output same thing]
...
[input something...]
[output same thing]
Ctrl-Z

Ctrl-Z

...
Ctrl-C

TCC session immediately terminates without notice. (I.E, the TCC window completely disappears.)

I don't know why it terminates. It probably shouldn't. But I think the way you're supposed to terminate the input is with a blank line, not Ctrl-Z. (Why? Dunno. I think maybe Rex is tired of DOSisms.)

</cn.btm")></cn.btm"><cn.btm"><cn.btm") the="">And finally, two almost unrelated but again really rather strange things:

The command "Notepad con.btm" yields a new instance of Notepad with a message box that states (and I quote) "The handle is invalid"!

Nothing to do with Take Command; that's an illegal filename, pure and simple. So are con.txt, con.foo, nul.bat, nul.cmd, lpt1.dat ....</cn.btm")></cn.btm"> Windows just doesn't permit filenames of this form.
 
CON is a reserved filename in Windows.
So any time you attempt to create a disk file named CON.* Windows
will reject it. This is a Windows-ism that dates back to the MS-DOS
days.

I am not sure what exactly you are trying
to do. What do you mean by, "If I redirect
the input of the command from the .btm file itself"?

There are many times where using the
@CON reference in a TCC command is really useful.
some_command
| for /F %p in(@CON) do something_else %p
or equivilently with inline DO
some_command
| do p in @con (something_else %p)

Many times it's easier to avoid the
pipe altogether
for
/F %d in ('some_command') do something_else %d
or
do
d in /p some_command (something_else %d)

One thing you do have to be careful
of is how to handle the special characters like the redirection chars.
That's where SETDOS /X becomes your best friend.

Some other neat ways to use @CON is
with here-document redirection:
(do var in @con (echo %var = %[%var]))
<< endtext
_4ver
_acstatus
_afswcell
_alt
_ansi
_batch
_batchline
endtext

-Scott

mathewsdw <> wrote on 04/27/2011
05:38:18 PM:


> To list these two situations:
>
> 1. (The just plain "strange" one) If I redirect the input
of the

> command from the .btm file itself, the response is:
>
> Line 0: @echo off
> ...
> Line 4: do line in @con:
> (after a relatively long wait[image removed]
> TCC: Z:\cn.btm [6] Command line too long
> Line 6: set i=7
> ...
> Line 9: endlocal
>
> I imagine this is some kind of recursion, but I have to admit I don't


> completely understand this...
>
> 2. Just the command "cn" getting its input from the actual
console:

>
> [input something...]
> [output same thing]
> [input something...]
> [output same thing]
> ...
> [input something...]
> [output same thing]
> Ctrl-Z
> →
> Ctrl-Z
> →
> ...
> Ctrl-C
>
> TCC session immediately terminates without notice. (I.E, the TCC window


> completely disappears.)
>
> This makes this technique somewhat less than useful for the purposes
> for which I intended to use these .btm files.
>
> As far as "TCC isn't really a programming language; it's a command


> shell" goes, while you are technically correct, it is such a
powerful

> language in general that that distinction is almost (but obviously
not

> completely) irrelevant. (I will note that I have turned a fair
> number of TCC capabilities into general functions that I can call


> from a C++ program. Examples are: AddCommas, EXISTS,
> ExceptionHandling..., GetValidResponse,
> ResolveDirectoryJunctionOrSymbolicLink, TrueTrueName, WildCardMatch


> (using TCC syntax), and possibly others that I don't remember...)


>
> And finally, two almost unrelated but again really rather strange
things:

>
> The command "Notepad con.btm" yields a new instance of Notepad
with

> a message box that states (and I quote) "The handle is invalid"!
>
> So if after dismissing that "message box" you enter some
text into

> the now "Untitled" Notepad window and then try to save the
resulting

> file to "con.btm", you get still another (even stranger!!!!)
message

> box: con.btm - This file name is reserved for use by Windows. Choose
> another name and try again.
>
> Further rather "strange" (but no longer really surprising)
things

> along the same line:
>
> ren cn.btm con.btm
> Z:\cn.btm -> Z:\con.btm
> TCC: (Sys) Cannot create a file when that file already exists.
> "Z:\cn.btm"
> 0 files renamed 1 failed
>
> dir con.btm
>
> Volume in drive Z is RAM disk Serial number is ...
> TCC: (Sys) The system cannot find the file specified.
> "Z:\con.btm"
> 0 bytes in 0 files and 0 dirs
> 193,519,616 bytes free
>
> Well, I guess that's enough for now...
 
> TCC session immediately terminates without notice. (I.E, the TCC window completely disappears.)

You can see that right on the command line:

Code:
v:\> do l in @con ( echo %l )
foo
foo
bar
bar
 (Ctrl-Z)

Ctrl-C
[vanishes]
I would have expected Ctrl-Z to end @CON.
 
On Wed, 27 Apr 2011 20:00:45 -0400, vefatica <> wrote:

|> TCC session immediately *terminates without notice*. (I.E, the TCC window *completely* disappears.)
|
|You can see that right on the command line:
|
|
|Code:
|---------
|v:\> do l in @con ( echo %l )
|foo
|foo
|bar
|bar

That got chopped by vBulletin (sigh!). There should also be a couple of Ctrl-Z
lines (one input, one echoed) and a Ctrl-C line which caused TCC to disappear.
 
> TCC session immediately terminates without notice. (I.E, the TCC window completely disappears.)

You can see that right on the command line:

Code:
v:\> do l in @con ( echo %l )
foo
foo
bar
bar
 (Ctrl-Z)

Ctrl-C
[vanishes]
I would have expected Ctrl-Z to end @CON.

And, an empty line (just [return]) **does** end @CON in the above scenario and returns the prompt. That's not the usual behavior of @CON.
 
Note that it's gorking on a line containing a percent sign. TCC examines the input line, finds a percent sign, expands the variable... finds a percent sign in the new value, expands it... finds a percent sign in the new value, expands it... finds a percent sign, expands it.... Eventually the line overflows the command-line buffer and everything goes blooey.

SETDOS /X is one (rather clumsy) way of coping with this kind of thing: ...

I don't know why it terminates. It probably shouldn't. But I think the way you're supposed to terminate the input is with a blank line, not Ctrl-Z. (Why? Dunno. I think maybe Rex is tired of DOSisms.) ...

Nothing to do with Take Command; that's an illegal filename, pure and simple. So are con.txt, con.foo, nul.bat, nul.cmd, lpt1.dat .... Windows just doesn't permit filenames of this form.
Steve, thanks for the answers. I had kind of figured out that something like that was the problem with the buffer overflow, I just didn't know exactly what (and really didn't care enough to spend a lot of time "investigating" since the knowledge would be "purely academic").

As to terminating with a blank line, that's not documented as far as I can tell, is kind of unexpected and surprising, but it certainly is good to know. (And of course I did test it just to make sure, and of course it works exactly as you claim!)

And as for the "illegal Windows file names" goes, I had never heard of that! (But nothing really surprises me in the pure Windoze environment!!!)
 
---- Original Message ----
From: mathewsdw

| Quote:
| Originally Posted by Steve Fabian
| ---- Original Message ----
| From: mathewsdw
| Subject: [Support-t-2801] Reading stdin...
| ---- End Original Message ----
|
| Type "help pipes" at the TCC command prompt, and it will open your
| eyes!
|
| Many commands can read data from STDIN (some, e.g., LIST, may need a
| special option).

Sorry, you quoted my signature and its separator, and any self-respecting mail client that conforms to the relevant RFCs considers that to be the end of the text to be quoted. Hence your response to my post above, to which I attempt to respond, was deleted. In any event, the languages of command processors (be it bash, Korn-shell, C-shell, Bourne-shell, the original COMMAND.COM of PC-DOS, or the most advanced command processor available in the Windows environment, TCC) are not object oriented, and your importing OO terminology totally obscured the meaning of your response.

I originally responded to my understanding of your OP. It did not actually describe what you want to do, only a lot of shouting that effectively hides any possibility of decrypting your question. After reading it a 3rd time, I think the key phrase is "how to do an analogous thing for stdin". So much of the long post about things unrelated to the question are shouted, but not this phrase! And the answer is still the same - what a process receives from a pipe it can access only through STDIN, which, by its very nature, is a character stream, normally delivered one line at a time. You can accumulate a single character, or all of the output, from the left side of the pipe before processing, or anything in between, e.g., you can read a specific number of lines before starting the real work, corresponding to your avowed purpose 'The difference is that I want my "object" to be able to read lines from a source (again, "stdin" in my case) and perform "correlations" between them'. To me this means reading line by line! You may want to preserve more than one line for a while, and that means processing each line separately, until enough are collected.
--
Steve
 
---- Original Message ----
Sorry, you quoted my signature and its separator, and any self-respecting mail client that conforms to the relevant RFCs considers that to be the end of the text to be quoted. Hence your response to my post above, to which I attempt to respond, was deleted. In any event, the languages of command processors (be it bash, Korn-shell, C-shell, Bourne-shell, the original COMMAND.COM of PC-DOS, or the most advanced command processor available in the Windows environment, TCC) are not object oriented, and your importing OO terminology totally obscured the meaning of your response.

I originally responded to my understanding of your OP. It did not actually describe what you want to do, only a lot of shouting that effectively hides any possibility of decrypting your question. After reading it a 3rd time, I think the key phrase is "how to do an analogous thing for stdin". So much of the long post about things unrelated to the question are shouted, but not this phrase! And the answer is still the same - what a process receives from a pipe it can access only through STDIN, which, by its very nature, is a character stream, normally delivered one line at a time. You can accumulate a single character, or all of the output, from the left side of the pipe before processing, or anything in between, e.g., you can read a specific number of lines before starting the real work, corresponding to your avowed purpose 'The difference is that I want my "object" to be able to read lines from a source (again, "stdin" in my case) and perform "correlations" between them'. To me this means reading line by line! You may want to preserve more than one line for a while, and that means processing each line separately, until enough are collected.
<!--[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]--><!--[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]--><!--[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]--> Steve, I will address your issues on at a time below.


  • I have no clue whatsoever about what you are talking about when you say "Sorry, you quoted my signature and its separator, and any self-respecting mail client that conforms to the relevant RFCs considers that to be the end of the text to be quoted." The simple fact is that I just let this website "do it's thing" when I hit the "quote" button (I’ve never had any reason in the past not to do that), and I did not, and generally do not (other than to possibly delete "lengthy" things that I think are truly irrelevant to the next part of the "discussion" to shorten the length of the whole reply) much mess with the contents of the “quoted” text. I also have never used a “mail client” that had any problem whatsoever with anything like what I can at least try to imagine you are referring to.


  • While, yes, of course, C++ is an object-oriented language, I am not aware of my trying to use object-oriented “features” in any TCC batch file ever I’ve written, partially because I have never had any need for them whatsoever, and mostly because I don’t know what “object oriented” would even mean in a language that totally lacks data structures, and I don’t consider that to be a limitation of TCC’s batch language – they are simply not needed for the kinds of tasks that the language is intended to be suitable for solving. I will also add that I only use the “object-oriented” features of C++ when I believe they are an actual asset to the task that I am trying to accomplish – I absolutely never use them on “general principles”. And how is “stdin” or a reference to a “pointer to a FILE structure” object-oriented? The C language, which is in no way “object-oriented”, had exactly the same things. My point was to make entirely clear, as best I could manage, to what the concept of “stdin” was; and as I believe I have mentioned, the concept of “stdin” (possibly with different names) is available in many different procedural languages. And finally, since I actually did get the answer(s) I was looking for from other people, those people did understand the concept I was trying to ask about. And I’m truly sorry that my presentation of “stdin” to present the concept I was trying to convey (and I have to say, at this moment, I have no clue as to any other way to present that concept) for some reason offended you.


  • I have no idea whatsoever as to what you are referring to in your comment about “only a lot of shouting”. Is that maybe (?) a reference to my use of bold type? Well the simple fact is that I tend to use bold type a lot (and I’ve been trying very hard, and believe me, it’s not easy, even in this sentence, to not use bold type) in all of my e-mail correspondence, as do the people (I will admit, to a somewhat lesser degree) who correspond with me, to emphasize the major points I am trying to present. I’m truly sorry if that offends you, and while I am not using it in this posting, I will make no such guarantees in any future postings that I make (and, again, I find it almost amazing how hard it is for me to not hit that “bold” button in writing this response – if I wasn’t trying to avoid it, I probably would have used it a dozen times or more in this paragraph (and maybe even in this sentence) alone.)


  • “Type "help pipes" at the TCC command prompt, and it will open your eyes!”. I did not see then, and still do not see now, what that has to do with anything. The simple question was not how to “pipe” something (and, as I said in my response, that was not something that I had any questions about), the simple question was how to get a batch file (itself, and not some command in the batch file) to receive that “piped” input so that it can process it further. And, again, there were other people who understood my question well enough because they supplied me with the correct answer.


  • I apologize in advance for the font/font size/spacing between the bullet points in this posting. Because of my handicaps, I really have no choice but to type these things in Microsoft Word first, and I have been unable to find a font that “matches” this website’s default font, nor have I been able to figure out a way to reduce the large amount of white space that separates the bullet points in this response. (I will note that I don't generally have this problem because I usually use "Notepad" to write these things; a "bottom of the line", "straight text" with no formatting whatsoever, text editor so as to avoid this kind of problem. However, Notepad, is, of course, totally unable to deal with "bullet points, which I truly wanted to use in this posting.)
I’m not sure if this is going to “solve” anything, but this is all I have to say on the matter(s).
 
<w:WrapTextWithPunct/> <w:UseAsianBreakRules/>
<w:DontGrowAutofit/>

Those are really rather funny :)
 
I also have never used a “mail client” that had any problem whatsoever with anything like what I can at least try to imagine you are referring to
This is why Steve used the phrase 'any self-respecting mail client'. It has long been a convention that adding a pair of hyphens followed by a space and an end of line indicated that the rest of a post or message was chaff and not part of the meat of the message. Since this forum is used by folk via mail and via the web interface the fact that the forum software doesn't understand that convention is a little unfortunate.

Of course, those of us that have been denizens of 'cyberspace' for long enough also tend to have a big problem with either top or bottom posting of the whole of a message in order to reply to it - dating back to the days when every byte sent and received online had a real monetary cost associated with it. Even now I would argue that it is more polite to only quote a small pertinent piece of the post you are replying to rather than repeating the whole thing verbatim.
 
---- Original Message ----
From: Steve Pitts
...
---- End Original Message ----

Steve,
Thanks for your support! I did not want to go into the topic of your 2nd paragraph, but I wholly concur.
--
Steve
BTW, Sorry, I had posted my last message in support thread 2813 before I received your last post correcting exactly the issue I questioned.
The above statement is one example of an issue which would be correctly stripped by a mail client when quoting the current post.
 
I have no idea whatsoever as to what you are referring to in your comment about “only a lot of shouting”. Is that maybe (?) a reference to my use of bold type?

All caps is generally considered to be the equivalent of shouting. Your use of bold does give a similar effect and strikes me as making your posts harder to read rather than clarifying them.

If you click the "Remove Text Formatting" button (the "A" with the red X through it) at the top left of the formatting buttons, it will (I hope) remove all the formatting and make your posts easier to read. Or, paste first into notepad, then into the forum.

When Steve referred to your use of object-oriented terminology, I believe he was referring to your "the internal name of an input source used in an 'executable object' from outside of that 'object' is completely irrelevant to users of that 'object'). The difference is that I want my 'object' to be able to read lines from a particular source". I did find this statement rather obscure.
 
]I would have expected Ctrl-Z to end @CON.

I can't imagine why -- Ctrl-Z means absolutely nothing to Windows or TCC. It definitely does not mean "end of file".

There is exactly one exception -- in COPY CON: a ^Z signals the end of input. This is *only* for backwards compatibility with COMMAND.COM. And that can probably be retired now.
 
On Fri, 29 Apr 2011 15:46:52 -0400, rconn <> wrote:

|There is exactly one exception -- in COPY CON: a ^Z signals the end of input. This is *only* for backwards compatibility with COMMAND.COM. And that can probably be retired now.

What does signal the end of input ... an empty line?

If I do this: "do l in @con (echo %l)", an empty line ends the DO command
(intended?) and Ctrl-C makes TCC vanish.
 
]
What does signal the end of input ... an empty line?

You're looking for documentation on undocumented features??

The @CON: command line syntax was invented by Charles; the help for DO never mentions anything about this. Insofar as it actually exists, it's intended for piping, not typing something at the command line.

The @FILE input ends when the file (or pipe) ends.

The ^C issue (a termination, not a crash) has been fixed in build 64.
 
On Fri, 29 Apr 2011 16:53:26 -0400, rconn <> wrote:

|You're looking for documentation on undocumented features??
|
|The @CON: command line syntax was invented by Charles; the help for DO never mentions anything about this. Insofar as it actually exists, it's intended for piping, not typing something at the command line.

"FOR ... (@CON:) ..." is documented.

"If you use @CON as the filename, FOR will read from standard input (typically a
redirected input file) or from a pipe."

And apparently an empty line signals the of end of input. That's limiting. ^Z
or ^C seems more appropriate.
 
"FOR ... (@CON:) ..." is documented.

FOR != DO

And apparently an empty line signals the of end of input. That's limiting. ^Z or ^C seems more appropriate.

There is no way I will reintroduce the use of ^Z as EOF. Period. That concept has been obsolete for 15 years.

^C means "throw everything away and return to the prompt".

If you want to use undocumented behavior to perform a useless action, you're going to be stuck with the way it works now. And it will probably change randomly in the future.
 
FOR != DO



There is no way I will reintroduce the use of ^Z as EOF. Period. That concept has been obsolete for 15 years.

^C means "throw everything away and return to the prompt".

If you want to use undocumented behavior to perform a useless action, you're going to be stuck with the way it works now. And it will probably change randomly in the future.

OK, I'm talking about FOR. I don't think

Code:
FOR ... (@CON:) ...
is useless. And its being terminated by an empty line is limiting. If I were manually appending comments to, say, a log file, like

Code:
FOR /F %line IN (@CON:) (ECHO %line >> logfile)
I couldn't put a blank line into the log (without actually typing "^r^n") and I couldn't continue. ^C canceling the whole thing seems ideal.
 
It has long been a convention that adding a pair of hyphens followed by a space and an end of line indicated that the rest of a post or message was chaff and not part of the meat of the message.
Thank you for the information, I'll try to keep that in mind.
 
When Steve referred to your use of object-oriented terminology, I believe he was referring to your "the internal name of an input source used in an 'executable object' from outside of that 'object' is completely irrelevant to users of that 'object'). The difference is that I want my 'object' to be able to read lines from a particular source"
I'm sorry that it was confusing, all I meant by "executable object" was "something that can be executed", as in a program (".exe") or a batch file (and there are others, although they are typically rather rare), and I did not know (and still do not know) of a quicker/easier/more understandable way to quickly express that concept. (And, please forgive me, but I find avoiding the use of "bold text" to be extremely difficult, as in even this very sentence!!!)
 
There is exactly one exception -- in COPY CON: a ^Z signals the end of input. This is *only* for backwards compatibility with COMMAND.COM. And that can probably be retired now.
Rex, I don't any longer know exactly why, I just do know that I have, for a very long time, habitually and without thinking about it, used ^Z to indicate "end of file" in whatever circumstances that made sense. (I can't any longer tell you what those circumstances are/were because it was, as I said, a habit. It may even in some way be UNIX-related because I did use UNIX a lot a long time ago.) And the fact that @con: does not work that way should in no way be taken as a criticism, the problem is not at all that it works the way it does, the problem (if there is one at all) is that I don't see any reference as to how to actually terminate the input to @con: in the documentation (although maybe I'm just missing it). But it really doesn't matter any more now that I have the answer to my question...
 
It's 30-year-old MS-DOS syntax. Microsoft eliminated ^Z as EOF when they released Windows 95.
Rex, please don't take this as a criticism, because it is not. However, I'm not even slightly crazy or off base here, and it probably took me less than 10 minutes to prove it. You see, as I believe I have mentioned here in the past, I write a lot of C++ programs (and it is specifically those C++ programs that I want to be able to replace by TCC batch files in the future, and I also want to make it absolutely crystal clear here that I am not using any C++ facilities that are not available to plain old C programs) that "read" from "stdin" and "write" to "stdout", and these programs are all, without exception, terminated by a ^Z on input because this is the "standard" (maybe "only"?) behavior of the "standard I/O" input functions in the C/C++ run time library, and not anything a all related to the code that I actually write to use those functions. (I will add that ^Z is not ^C for these programs, with ^Z the program is terminated "normally" (i.e., closing files and such things), while ^C terminates the program abnormally.) This is where that "strong" expectation came from.
 
If I were manually appending comments to, say, a log file, like

Code:
FOR /F %line IN (@CON:) (ECHO %line >> logfile)
I couldn't put a blank line into the log (without actually typing "^r^n") and I couldn't continue. ^C canceling the whole thing seems ideal.

I don't think you picked a great example to make your case. Why not:

copy logfile+con:

??

IMO using either DO or FOR to read from the keyboard at the command line will not accomplish anything worthwhile. (Reading from pipes or redirected input files is another story.)
 
Back
Top