qz@maxwell.physics.purdue.edu (Qin Zhao) (09/15/89)
Hi, I recently got some problem when I tried to concatenate two files. What I have done is following: There is tow file: file1 and file2 ( I got from somebody else ). I gave command: type file2 >> file1 in order to put file2 at the end of file1. And then I used "dir" to check the size of file1, it was increased by the size of file2. However, when I tried to read the contents of file1, I could only see the original part of file1. I had used several editors, and "type" commands. But when I rewrote file1 using the editor, the size of file1 drops to the original size of file1. I guess that file1 and file2 were created in old version (3.0 ) DOS, and the end-of-file character may be not recognized by the new version ( 3.3) of DOS. But I am not sure how this can happen, and how can I solve this problem. I would be very much appreciated, if somebody can provide some information.
gcook@cps3xx.UUCP (Greg Cook) (09/15/89)
From article <2553@pur-phy>, by qz@maxwell.physics.purdue.edu (Qin Zhao): > Hi, I recently got some problem when I tried to concatenate two files. > What I have done is following: > There is tow file: file1 and file2 ( I got from somebody else ). > I gave command: > type file2 >> file1 > in order to put file2 at the end of file1. And then I used "dir" to check > the size of file1, it was increased by the size of file2. > However, when I tried to read the contents of file1, I could only see the > original part of file1. I had used several editors, and "type" commands. > But when I rewrote file1 using the editor, the size of file1 drops to the > original size of file1. > I guess that file1 and file2 were created in old version (3.0 ) DOS, and > the end-of-file character may be not recognized by the new version ( 3.3) of > DOS. But I am not sure how this can happen, and how can I solve this problem. > I would be very much appreciated, if somebody can provide some information. I think you are on the right track. I know that the type command stops when it encounters an EOF. You did not mention what type of system you have, and I think this is more pronounced on some systems than other(but I could be wron, I often am :-). When you are appending, the EOF at the end of file1 is not erased and type will "type" up to that EOF, and thinking it is done, will ignore the rest. This is also true for some word processors and editors. And what it sounds like is that when you save your file, the appended file was not brought into your editor so it saved only what it read in, file1. WHat you need to do is find a word processor or editor, that ignores the EOF (cntrl-z or ASCII 26) when it reads in your file, and then go through and delete the EOF after file1. I think this can be done in WORD or WORDPERFECT. I don't know about any others. For more information, see "The Help Screen", PC WORLD, Oct. 89. (Interesting that I just read this yesterday, when I got my magazine) BTW, I don't think my previous statement is correct, about this being a problem on some machines and not others. Hope this helps! ========================================================================= Greg Cook All good things come through chemistry! gcook@horus.cem.msu.edu cook@frith.egr.msu.edu
toma@tekgvs.LABS.TEK.COM (Tom Almy) (09/15/89)
In article <2553@pur-phy> qz@maxwell.physics.purdue.edu.UUCP (Qin Zhao) writes: > Hi, I recently got some problem when I tried to concatenate two files. >What I have done is following: > There is tow file: file1 and file2 ( I got from somebody else ). > I gave command: > type file2 >> file1 > in order to put file2 at the end of file1. And then I used "dir" to check >the size of file1, it was increased by the size of file2. >However, when I tried to read the contents of file1, I could only see the >original part of file1. I had used several editors, and "type" commands. >But when I rewrote file1 using the editor, the size of file1 drops to the >original size of file1. While DOS is perfectly capable of knowing file sizes, DOS was originally designed as a copy of CP/M, which had fixed length (128 byte) blocks. In CP/M you would mark the end of an ASCII file with a control-Z character. Because of this, most DOS programs that handle text treat a control-Z character as an end-of-file marker. File1 was undoubtedly created by a program that inserts control-Zs at the end of file (typical for programs that trace their roots back to CP/M). So when you append file2 to the end of file1, file1 has a control-Z character at the end of its original data. The editors and type commands you used simply stopped at the control-Z. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
baird@cod.NOSC.MIL (John M. Baird) (09/15/89)
From article <2553@pur-phy>, by qz@maxwell.physics.purdue.edu (Qin Zhao): > > Hi, I recently got some problem when I tried to concatenate two files. > I gave command: > > type file2 >> file1 > If instead you had tried COPY /A file1+file2 newfile you would have had better luck. file2 did get added to file 1, AFTER one or more existing Ctrl-Zs. COPY /A will not put Ctrl-Zs in the output file, so you should be OK. When you used TYPE to look at the resulting file, it stopped at the first Ctrl-Z. Try using COPY file1 CON /B instead, and the entire file (with the embedded Ctrl-Zs) will be displayed on the console. John Baird, Naval Ocean Systems Center, San Diego, CA
fredb@llama.rtech.UUCP (Fred Buechler) (09/16/89)
In article <2553@pur-phy> qz@maxwell.physics.purdue.edu.UUCP (Qin Zhao) writes: > > Hi, I recently got some problem when I tried to concatenate two files. > >What I have done is following: > There is tow file: file1 and file2 ( I got from somebody else ). > I gave command: > > type file2 >> file1 > > in order to put file2 at the end of file1. And then I used "dir" to check >the size of file1, it was increased by the size of file2. >However, when I tried to read the contents of file1, I could only see the >original part of file1. I had used several editors, and "type" commands. >But when I rewrote file1 using the editor, the size of file1 drops to the >original size of file1. > > I guess that file1 and file2 were created in old version (3.0 ) DOS, and >the end-of-file character may be not recognized by the new version ( 3.3) of >DOS. But I am not sure how this can happen, and how can I solve this problem. >I would be very much appreciated, if somebody can provide some information. The problem is that the end of file mark (^Z) is still at the end of the first file (as well as a second one at the end of the whole file). The way to concatenate files is to use the DOS copy command. There is a special syntax that will concatenate the two files. I don't have the manual handy to look up the specifics now. Good Luck! -- fredb
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (09/16/89)
In article <2553@pur-phy> qz@maxwell.physics.purdue.edu.UUCP (Qin Zhao) writes:
$ There is tow file: file1 and file2 ( I got from somebody else ).
$ I gave command:
$ type file2 >> file1
$ in order to put file2 at the end of file1. And then I used "dir" to check
$the size of file1, it was increased by the size of file2.
$However, when I tried to read the contents of file1, I could only see the
$original part of file1. I had used several editors, and "type" commands.
$But when I rewrote file1 using the editor, the size of file1 drops to the
$original size of file1.
[...]
It sounds to me like the problem here may well be the DOS end-of-file
marker used for text files, which is ^Z (26 or 1AH). It is possible that
the EOF marker in the first file is still present before the start of the
new file,and your editor finds this and considers it to be the end of the
entire file rather than just an odd byte in the file. TYPE will certainly
stop at the first EOF, and many editors may do similarly.
I haven't tried this out; it is just speculation. Indignant "You're way
off" replies to dev/null please.
--
Stephen M. Dunn cs4g6ag@maccs.McMaster.CA
**********************************************************************
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
"VM is like an orgasm: the less you have to fake, the better." - S.C.leonard@bucket.UUCP (Leonard Erickson) (09/16/89)
Text files have a ^Z at the end as an end-of-file marker. This is a hangover from CP/M. Most editors assume that a ^Z is the end of the file. Thus your problem with the editor not seeing the second file *and* also truncating the file. Type file2 >>file1 will *not do what you want. the *proper command is: copy file1+file2 file3 /a this will copy file 1 *and* file 2 to a new file (file3). The /a indicates that these are ascii (as opposed to binary) files. So the ^z will get stripped of of the end of the first file. -- Leonard Erickson ...!tektronix!reed!percival!bucket!leonard CIS: [70465,203] "I'm all in favor of keeping dangerous weapons out of the hands of fools. Let's start with typewriters." -- Solomon Short
2014_5001@uwovax.uwo.ca (09/17/89)
In article <2553@pur-phy>, qz@maxwell.physics.purdue.edu (Qin Zhao) writes: > Hi, I recently got some problem when I tried to concatenate two files. > > What I have done is following: > > I gave command: > type file2 >> file1 > > in order to put file2 at the end of file1. And then I used "dir" to check > the size of file1, it was increased by the size of file2. > However, when I tried to read the contents of file1, I could only see the > original part of file1. I had used several editors, and "type" commands. > But when I rewrote file1 using the editor, the size of file1 drops to the > original size of file1. It likely hold that there is an EOF char at the end of file1. The simple solution is: copy file1+file2 file3 Then, ren file1 *.bk! ren file3 file1 -- Alexander Pruss, at one of: Department of Applied Mathematics, Astronomy, Mathematics, or Physics University of Western Ontario pruss@uwovax.uwo.ca pruss@uwovax.BITNET A5001@nve.uwo.ca
ralf@b.gp.cs.cmu.edu (Ralf Brown) (09/17/89)
In article <1675@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: } }Text files have a ^Z at the end as an end-of-file marker. This is a }hangover from CP/M. Most editors assume that a ^Z is the end of the ^^^^^^^^^^^^ }file. Thus your problem with the editor not seeing the second file That's not my experience. Qedit, Sprint, and PC-Write will merrily read any Ctrl-Zs in the middle of the file without stopping, and BlackBeard 7.39 gave you the option (when a Ctrl-Z is encountered in the middle of the file) of truncating the file there or continuing to read the rest. The fifth editor I have any significant experience with (SpellBinder, copyright 1978/1982) is the only one that ever used ^Z as an EOF marker, and it was crossassembled from CP/M.... (besides, I haven't used it since very early 1986) -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/46 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? |"Humor is laughing at what you haven't got when you ought to What's that?| have it." -- Langston Hughes
wcr@branch.FIDONET.ORG (W.c. Rothanburg) (09/17/89)
In an article of <15 Sep 89 06:21:45 GMT>, qz@maxwell.physics.purdue.edu (Qin Zhao) writes: > Hi, I recently got some problem when I tried to concatenate two files. > >What I have done is following: > > There is tow file: file1 and file2 ( I got from somebody else ). > > I gave command: > > type file2 >> file1 > > in order to put file2 at the end of file1. And then I used "dir" to >check > >the size of file1, it was increased by the size of file2. > >However, when I tried to read the contents of file1, I could only see the > > >original part of file1. I had used several editors, and "type" commands. > >But when I rewrote file1 using the editor, the size of file1 drops to >the > >original size of file1. > > I guess that file1 and file2 were created in old version (3.0 ) DOS, >and > >the end-of-file character may be not recognized by the new version ( 3.3) >of > >DOS. But I am not sure how this can happen, and how can I solve this >problem. > >I would be very much appreciated, if somebody can provide some >information. >' Actually, It did work. DOS normally marks the end of a text (ascii) file with a Ctrl-z. Dos's append '>>' added the output of the type command the the first file, after the Ctrl-z to mark the end of the file. Try: copy file1+file2 file3 This will copy the contents of file1 and file2 to file3. I beleive this will correct the problem you are expirencing. Bill -- --------------------------------------------------------------------+ "Out on a Limb in The Branch Office...." ] ] Fidonet : 1:369/11 The Branch Office. (branch.FIDONET.ORG) ] UUCP : {sun!hoptoad, attctc, <internet>!mthvax}!ankh, ] gatech!uflorida!novavax!branch!wcr ] ] INTERNET: wcr@branch.FIDONET.ORG -or- wcr@f11.n369.z1.FIDONET.ORG ] BBS : +1 305 979-2073 ] 'I was asking for it.....' ] --------------------------------------------------------------------+
ts@chyde.uwasa.fi (Timo Salmi LASK) (09/18/89)
In article <6169@pt.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes: >In article <1675@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: >} >}Text files have a ^Z at the end as an end-of-file marker. This is a >}hangover from CP/M. Most editors assume that a ^Z is the end of the > ^^^^^^^^^^^^ >}file. Thus your problem with the editor not seeing the second file > >That's not my experience. Qedit, Sprint, and PC-Write will merrily read any I quite agree. And furthermore, if ^Z nevertheless becomes a problem, there are filters that get rid of them. I have written a couple myself for this purpose for the public domain. ................................................................... Prof. Timo Salmi (Site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: vakk::salmi Bitnet: salmi@finfun
svirsky@ttidca.TTI.COM (Bill Svirsky) (09/19/89)
In article <2553@pur-phy> qz@maxwell.physics.purdue.edu.UUCP (Qin Zhao) writes:
+ Hi, I recently got some problem when I tried to concatenate two files.
+What I have done is following:
+ There is tow file: file1 and file2 ( I got from somebody else ).
+ I gave command:
+ type file2 >> file1
+ in order to put file2 at the end of file1. And then I used "dir" to check
+the size of file1, it was increased by the size of file2.
+However, when I tried to read the contents of file1, I could only see the
+original part of file1. I had used several editors, and "type" commands.
+But when I rewrote file1 using the editor, the size of file1 drops to the
+original size of file1.
As has been previously mentioned, your editor is stopping at the
imbedded ^Z (EOF) character. Now about concatenating files:
The following is true for Compaq DOS 3.31 and IBM DOS 3.10. I believe it
holds true for any DOS 3+. I'm not sure about DOS 2.
The copy command in DOS makes for interesting reading. It can be used
in many ways. A word of warning up front though; be *very* careful when
copying files and using wildcards. You can stomp on your files.
To simply concatenate text "file2" to text "file1", you can use
1) copy file1+file2
To concatenate text "file1" and text "file2" and put the results into a new
file, "file3", you can use
2) copy file1+file2 file3
If you don't specify a destination file, DOS appends to the 1st file in
the list. Thus, the example 1 can be extended to many more files.
3) copy file1+file2+file3+...
In fact, you can use wildcards, such as
4) copy file1+file*
to concatenate all files that start with "file" and have no extension
to "file1". Unfortunately, DOS doesn't guarantee ascending sequence when
it expands wildcards, it expands wildcards in the order that they show
up in the directory. So, if a DIR displays the files in the following
order:
file3
file1
file2
the example 4 would have the same results as if you entered
5) copy file1+file3+file2
Well, not *exactly* the same results. Example 4 will generate 1 or more
warning messages like
Content of destination lost before copy
What really happens is that DOS expands the command into something like
6) copy file1+file3+file1+file2
Now DOS tries not to copy a file onto itself. But it doesn't compare an
input filename to the destination filename until it is ready to copy
it. So, when it gets to the 2nd "file1", it then checks to make sure
that the destination filename is not "file1". It not only sees that the
destination file is "file1", but it thinks that the original contents of
"file1" have been trashed. So it warns you. In this case DOS is wrong
but, lets say you have files
my.lst
your.lst
our.lst
all of which are near and dear to you. You normally create "our.lst" by
using
7) copy *.lst our.lst
but in this case, you've spent hundred's of hours editing "our.lst" and
just want to concatenate "my.lst" and "your.lst" to it. However, when
you enter the command, your fingers betray you and enter the familiar
command above. As you realize what you did, you think "No need to worry,
MS-DOS won't copy a file onto itself. I'm safe". WROOOONG! DOS copies
"my.lst" and "your.lst" onto "our.lst" before it gets to "our.lst" and
checks to see if it is overwriting a file. It is already too late,
"our.lst" is trashed, so DOS warns you. Crushed by your loss, you swear
off MS-DOS (after swearing at MS-DOS), sell your PC and buy a Mac (-:.
The moral of the story is; be careful using wildcards with copy.
To get serious once again: You can also use wildcards with
concatenation. For instance
8) copy *.h+*.c allsrc
will concatenate all of your ".h" files and all of your ".c" files and
place the results into "allsrc".
A couple of final notes: the "/A" (ASCII) option and "/B" (BINARY)
options apply only to the file immediately preceding the option and to
all subsequent files until the next "/A" or "/B". "/A" is the default
for concatenation, "/B" for normal copying.
I hope this has all been lucid enough. It's getting late and things are
getting fuzzy. I have not covered all of the COPY command, just some of
the high points. You'll have to read the rest yourself.
--
Bill Svirsky, Citicorp+TTI, 3100 Ocean Park Blvd., Santa Monica, CA 90405
Work phone: 213-450-9111 x2597
svirsky@ttidca.tti.com | ...!{csun,psivax,rdlvax,retix}!ttidca!svirsky