1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Reading stdin...

Discussion in 'Support' started by mathewsdw, Apr 27, 2011.

  1. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    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!)
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    ---- 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
     
  3. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,277
    Likes Received:
    38
    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
     
  4. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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">
     
  5. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.
     
  6. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,277
    Likes Received:
    38
    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
    
    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 ....</cn.btm")></cn.btm"> Windows just doesn't permit filenames of this form.
     
  7. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,177
    Likes Received:
    11
    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:


    of the


    console:



    powerful

    not




    things:

    with

    text into

    resulting

    message

    things

     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    > 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.
     
  9. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    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.
     
  10. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    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.
     
  11. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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!!!)
     
  12. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    ---- 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
     
  13. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    <!--[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).
     
  14. Kachupp

    Joined:
    Aug 9, 2009
    Messages:
    133
    Likes Received:
    0
    <w:WrapTextWithPunct/> <w:UseAsianBreakRules/>
    <w:DontGrowAutofit/>

    Those are really rather funny :)
     
  15. Steve Pitts

    Joined:
    Jul 7, 2008
    Messages:
    158
    Likes Received:
    0
    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.
     
  16. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    ---- 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.
     
  17. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    646
    Likes Received:
    1
    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.
     
  18. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    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.
     
  19. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    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.
     
  20. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    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.
     
  21. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    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.
     
  22. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    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.
     
  23. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,277
    Likes Received:
    38
    If I'd known that I was inventing it, I would have picked a better filename.
     
  24. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    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.
     
  25. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    Thank you for the information, I'll try to keep that in mind.
     
  26. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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!!!)
     
  27. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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...
     
  28. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    It's 30-year-old MS-DOS syntax. Microsoft eliminated ^Z as EOF when they released Windows 95.
     
  29. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.
     
  30. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,726
    Likes Received:
    80
    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.)
     

Share This Page