hes@ecsvax.UUCP (Henry Schaffer) (12/13/85)
<>In unix one can redirect output to a file using > or redirect
output to append to an existing file using >> .
E.g., assuming that file "test" has some text in it:
cat test > test2
cat test >> test2
produces two sequential copies of the test file in the test2 file.
This can be verified by looking at test2, e.g., by cat test2.
So I tried to do the same thing in pc-dos 2.10. (I'm guessing that
the same thing will happen in ms-dos - correct me if I'm wrong.)
type test > test2
type test >> test2
test2 ends up the correct size (in the dir listing), but type test2
only gives *one* copy of test. A quick list using debug shows that
appending leaves the end-of-file-marker (^Z, hex 1A) in place and
appends after it. So "type" stops at the first EOF and doesn't ever
show the second copy of "test".
The manual (Chap. 1, p. 6) simply says that the >> "Causes filename
to be opened (created if necessary) and positions the write pointer
at the end of the file so that all output is appended to the file."
It is possible to append files, omitting the intermediate EOFs, by
using the concatenate option of the COPY command. Thus one can
always pipe to a new file, and then append that file as desired by
using COPY. However that is an extra step - and it looks as if the
>> is pretty much useless.
Is there some way to use the >> in the same manner as in unix?
Is this a peculiarity of pc-dos vs. ms-dos? Any sage words of
wisdom would be welcome.
--henry schaffer
P.S. In case anyone is wondering why I care - I just got a copy of
the ms-dos version of UNIX|STAT 5.1, which is a very good package
of statistically oriented unix-style programs. I'm trying to learn
how to use it effectively, and so I am using i/o redirection and
pipes. After seeing how nicely these techniques do work (they do
work even on a floppy diskette system, but much more nicely on a
hard disk system) I've decided that most programs for ms-dos/pc-dos
are really cp/m-style rather than unix-style.dgary@ecsvax.UUCP (D Gary Grady) (12/13/85)
In article <900@ecsvax.UUCP> hes@ecsvax.UUCP (Henry Schaffer) writes: > > type test > test2 > type test >> test2 > >test2 ends up the correct size (in the dir listing), but type test2 >only gives *one* copy of test. A quick list using debug shows that >appending leaves the end-of-file-marker (^Z, hex 1A) in place and >appends after it. So "type" stops at the first EOF and doesn't ever >show the second copy of "test". The practice of marking end-of-file with a ^Z is a #$%^& "feature" of DOS that comes from CP/M, where no directory information was kept on the true length of a file in bytes. Since DOS *does* keep the actual length, it serves no useful purpose to use ^Z. In fact, almost all programs and DOS commands (including TYPE) are quite happy working with files that lack a terminating ^Z. So I blame Henry's problem not on >> but on TYPE (for not ignoring ^Z) and mainly on his text editor, for creating a ^Z to begin with. I'd suggest he consider (1) checking his editor to see if the ^Z can be turned off (as it can with PC-Write, for example), (2) modifying the editor's object code to the same effect, or (3) using a better editor. -- D Gary Grady Duke U Comp Center, Durham, NC 27706 (919) 684-3695 USENET: {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
bet@ecsvax.UUCP (Bennett E. Todd III) (12/14/85)
The problem is not a bug in whatever created junk, but with I/O
redirection and/or the TYPE command; the sequence
TYPE junk >junk2
TYPE junk >>junk2
can only put a ^Z between the copies if either TYPE or >> is appending a
^Z, since TYPE wouldn't have gotten the ^Z out of the source file. It
would be interesting to try to find out exactly what circumstances are
required to demonstrate this bug (the exact nature of the original
"junk" file, and the version of DOS involved) since I just tried to
recreate the problem (under MS-DOS 3.10 from Zenith on a Z-200) and
could not, under any circumstances.
-Bennett
--
"Hypocrisy is the vaseline of social intercourse." (Who said that?)
Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695
UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!betggl@mhuxi.UUCP (LASKARIS) (12/16/85)
Henry Shaffer writes: (condensed) > <>In unix one can redirect output to a file using > or redirect > output to append to an existing file using >> . > E.g., assuming that file "test" has some text in it: > > cat test > test2 > cat test >> test2 > > produces two sequential copies of the test file in the test2 file. > This can be verified by looking at test2, e.g., by cat test2. > So I tried to do the same thing in pc-dos 2.10. He goes on to ask about end-of-file characters (control-Z) in MS-DOS. It is true that the redirection '>>' will append after the EOF character in a DOS file, because MS-DOS (and PC-DOS, as far as I know) uses both the EOF and the byte count (from the directory) to determine the length of a file. Different parts of the operating system disagree as to which to believe. Generally, though, the byte count is usable, and the EOF may be left out of a text file (horrors!) without making trouble for MANY applications. We have one text editor (Edix from Emerging Technologies) which seems to prefer having the EOF character, and another (KEDIT, from Mansfield Software) which seems to rely on the byte count. In the Lattice compiler, for instance, if you use the "level 2" i/o (fopen() et al.) you get an EOF character placed at the end of your file when you fclose() it. However, if you use the "level 1" i/o (open() et al), you get what you put out exactly, i.e., no EOF unless you put it there. In addition, Lattice has a switch that will reverse the fopen() convention so that the EOF character is not put out. (It also changes what Lattice does with newline characters.) The point of all this is that the TYPE command will handle a text file with a correct byte count and NO EOF correctly, and that if you do things this way the '>>' redirection will also work as you expect. You will have to play with your application a bit to make sure that everything else is OK. While I am happy enough with MS-DOS, I find it is full of this kind of silly inconsistency, caught between CP/M and Unix, neither fish nor fowl. For a good laugh, try this: copy \dev\con \dev\prn (text will go to the printer) ^Z David Laurance held captive by LASKARIS, at AT&T International mhuxi!ggl