• Please review our updated Terms and Rules here

DOS Batch files & STDIN

Chuck(G) said:
...The big difference between DOS and Unix in implementation, however is the issue of "piping" the output of one program to the input of another. DOS, being single-tasking writes the output of a "piped" program to a file and waits until the originating program has completed before passing the contents of the file to the receiving program. In Unix, the linkup is real-time; that is, both programs are loaded in memory and the output of one is passed to the input of the other as it happens.
Click to expand...
As far as I can see that's the problem with what Mike wants to do.
Using <> in my original reply was of course confusing; what I meant was:
ECHO [Insert text to send here] | FTP
But there are (at least) two problems:
- ECHO can't send multiple lines; this could be solved by using a more flexible replacement for ECHO
- You would have to somehow send a CTL-Z or terminate the batch file in order to actually send the text in question 'down the pipe' to the FTP program (which would of course actually have to get its input from stdin instead of bypassing it as many programs do).
 
Last edited:
Well, multiple lines can be sent by using the >> operator with a temp file as a target.
However, the control-Z is a different problem.

Here's how I solved it, donkey's years ago--I wrote a utility called ECO that accepted escaped control codes. So you can ECO \026 to send a control-Z.
 

Attachments

  • eco.zip
    306 bytes · Views: 1
MikeS said:
ECHO [Insert text to send here] | FTP
But there are (at least) two problems:
- ECHO can't send multiple lines; this could be solved by using a more flexible replacement for ECHO
- You would have to somehow send a CTL-Z or terminate the batch file in order to actually send the text in question 'down the pipe' to the FTP program (which would of course actually have to get its input from stdin instead of bypassing it as many programs do).
Click to expand...
In a UNIX shell this would commonly be done by a so called 'here script'. Such a concept doesn't exist in COMMAND.COM, but as i sketched futhter up in the thread, something similar could be implemented.
 
BAT files are a form of scripting for COMMAND.COM. That scripting language just is not expressive enough ...

I was looking for something that did not require external programs to run based on my Unix example. DOS just does not have the capability to do it unassisted.
 
What is wrong with extending the capabilities of the scripting language by external programs? This is a very common practice in DOS as well as in UNIX. Actually many DOS batch files are a combination of internal and external commands and from the syntactical point of view there is no difference.
 
wiwa64 said:
What is wrong with extending the capabilities of the scripting language by external programs? This is a very common practice in DOS as well as in UNIX. Actually many DOS batch files are a combination of internal and external commands and from the syntactical point of view there is no difference.
Click to expand...

Because I asked for standard DOS and I didn't want to assume the presence of a third party utility? (Or have to distribute it.)

I'm more than capable of writing such a utility. But I was interested in finding out if DOS could do it without assistance first. There is no point in re-inventing the wheel continuously.


Mike
 
There is at least one cute way to do this using only the standard DOS command syntax that involves creating a self-unpacking .COM file using ECHO commands, then executing it. But I'm sure that you'd probably count that as an "external" command.
 
Chuck(G) said:
Well, multiple lines can be sent by using the >> operator with a temp file as a target.
Click to expand...
If Mike would let us use a temp file there'd be no problem.
There is at least one cute way to do this using only the standard DOS command syntax that involves creating a self-unpacking .COM file using ECHO commands, then executing it. But I'm sure that you'd probably count that as an "external" command.
Click to expand...
Again, then you might as well just do the usual and create a temporary file to use as stdin as John suggested back in post #5, but Mike doesn't want to do it the easy way for some reason... ;-)
 
I did wind up using a temporary file. But the query was to see if the Unix way of doing it without the temporary file could be emulated in DOS. And the answer is'no' unless you use extra utilities.
 
mbbrutman said:
I did wind up using a temporary file. But the query was to see if the Unix way of doing it without the temporary file could be emulated in DOS. And the answer is'no' unless you use extra utilities.
Click to expand...
I think we got that; hence the smiley.

But you're just looking at it the wrong way: to emulate the UNIX way without using an extra utility DOS uses a temporary file.
;-)

(Note: another smiley)
 
Chuck(G) said:
Well, you'll always use a temporary file if you use redirection, so it's a wash either way.

ECHO HOWDY, MIKE! >FOOF

generates a temporary file.
Click to expand...
Point taken; I should have said "without explicitly creating a temporary file".

Something to keep in mind if you're executing on write-protected or read-only media.
 
MikeS said:
I think we got that; hence the smiley.

But you're just looking at it the wrong way: to emulate the UNIX way without using an extra utility DOS uses a temporary file.
;-)

(Note: another smiley)
Click to expand...

I don't personally care if DOS is using a temporary file to approximate the same behavior - it is a single tasking operating system. But I am going to assume that when DOS uses that technique that it uses a funky filename that it chooses so that it is unique and does not clobber an existing file on the disk. (In early versions of DOS I've interrupted something like a "more" command running to see the temporary file, and it usually started with a few $$$s.)

If you are forced to do it with your own temporary file then you do not have a way to guarantee a unique filename. I don't think there is any facility in the DOS BAT file handling that will give you a guaranteed unique name. If you pick something obscure enough you will not cause any damage, but it's just easier to do it with separate input and BAT files and not worry about it.
 
Excuse my amateurish and thus possibly out-to-lunch contribution to this thread. I've just been fooling with a batch file which needs user input, and found that setting something as an environmental variable instead of a temp file shows some promise. I haven't quit gotten there yet, but perhaps keener minds can make that work.
 
The original DOS I was using was IBM PC DOS 5.02, and at the time I was testing/developing my FTP client.

Either way, this has turned from just a question of automation to a brain teaser. Which is pretty good for a thread that was woken up after a 3 year nap.


Mike
 
mbbrutman said:
... this has turned from just a question of automation to a brain teaser. Which is pretty good for a thread that was woken up after a 3 year nap.

Mike
Click to expand...
Well, it reminded me of some DOS .BAT limitations that I'd forgotten about, and digging around on the web I found some relevant tricks that I wouldn't have thought of; interesting.
 
Chuck(G) said:
Ole, remember that we're talking MS-DOS (probably 2.0+) and no external programs. That's pretty primitive.
Click to expand...

Yes, I'm quoting you a lot tonight (I think this is the third time in 24 hours XD), but I have a DOS version-agnostic batch file I use for restore purposes, and I can set environment variables in that just fine using DOS 2.1... I don't think I understand the original question that Mike posted. Why not use environment variables to store strings to be used as input to another program within a batch file?
 
cr1901 said:
... Why not use environment variables to store strings to be used as input to another program within a batch file?
Click to expand...
Well, strictly speaking it's not completely self-contained as he specified; practically speaking, by the time you've dealt with varying number of lines, end of line characters, etc. a simple text file sounds a lot simpler.

But if it's variable then in a read-only environment it might be more practical.
 
You must log in or register to reply here.
Back
Top