Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Redirection

Status
Not open for further replies.

Actor

Programmer
Nov 19, 2003
20
US
BACKGROUND

DOS provides for redirection of input/output. A program designed to accept input from the keyboard and output to the screen can be made to accept input from a file and/or output to another file. For example, the following program is written for std in to std out.

Code:
Program fCopy (input,output) ;

Var
       Ch : Char ;

begin
       while not Eof do begin
               Read (Ch) ;
               Write (Ch)
       end
end.

But if you invoke it thus:

fCopy < test.txt

the contents of the file test.txt will be copied to the screen. Likewise:

fCopy < intest.txt > outest.txt

will copy the contents of intest.txt to outest.txt, even creating outest.txt.

PROBLEM

Even though the above example behaves as described my experience has been that some programs I write will not work this way. The redirection gets ignored and the input is from the keyboard and the output is to the screen even though I try to use redirection. What gives? I can't seem to find any technique that determines whether redirection will work with a program or not.
 
This is a DOS function, therefore all I/O must go through the DOS functions. This is not the case if direct display routines are used. For Turbo Pascal, this takes the shape of the inclusion of the CRT unit.
 
None of the programs I have written with the intention of using redirection have used the CRT unit. As I stated, the example program works but others don't. Why some can be redirected and others can't I have no clue.
 
I agree, it ought to work, and shouldn't need crt to do the job. Perhaps you could give an example of a simple program that hasn't worked?
 
Here is a basic filter prototype program I use to create many DOS like filters. They are completely self contained under Quick Pascal & probably under Tpascal.

Just change the name, insert record changing code as indicated and you have filter programs like:

DIR | FILTER1 | SORT
or
FILTER <MYDATAIN.TXT >MYDATAOT.TXT

You need to use string record format to work lije you want and it makes more sense. I use these filters on Windows/XP

PROGRAM FILTER;
Uses CRT, printer;

VAR
DATAFILE : TEXT;
Inrec : String;

BEGIN
Assign( DATAFILE, '' );
Reset(DATAFILE);
ASSIGN(LST, '' );
REWRITE(LST);

WHILE NOT EOF( DATAFILE ) DO
BEGIN
READln(datafile, Inrec);
(* put record change code here*)
Writeln(LST, Inrec );
END;
END.
 
You may want to look below in the stack for the "UPCASE" question where I was having a problem with the upcas function in a filter I was writing to read records and raise all characters to upper case.
 
Here's a new development. It seems that WriteLn causes a line feed only, without any carriage return, i.e., in a series of WriteLn subsequent output begins in the column following the end of the output from the previous WriteLn.

I don't know if the two problems are related or not.

I'm using a Dell running Windows XP and running my programs from the DOS prompt. Could the problem have anything to do with the OS?
 
I doubt it's anything to do with the line-feed only behaviour of writeln. You can, of course, write the carriage return yourself, but most programs interpreting text will interpret 0Dh as a line feed and carriage return.

No, it definitely isn't a problem with the operating system. Plenty of people will tell you that WinXP does not support DOS, but it does; Microsoft aren't that hopeless. WinXP emulates DOS superbly.

Have you any examples where the redirection doesn't work? Just in case something leaps out as not quite right.
 
hex od is return, hex oa is end of record & hex 1a is end of file in Windows text mode.

my program above with writeln generated hex 0d0a at the end of each writeln.

windows and most programs that run on it defaults to 0d0a where as linux defaults with just a 0a.

if i create a file under linux editor or programs and bring it into windows into say notepad, the file looks line one long line on the screen because of the missing od.

under windows i load the file in to simple edit, type a space and then delete it so it looks modified, then save it, it then looks like a windows text file.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top