From: Brian E. <be...@me...> - 2005-11-25 10:20:18
|
Hi, on my system g77 does not read the last line of file if it is not ended by a line break. Can that be changed? -- Brian (remove the sport for mail) http://www.et.web.mek.dtu.dk/Staff/be/be.html http://www.rugbyklubben-speed.dk |
From: Keith M. <kei...@to...> - 2005-11-25 11:55:08
|
Brian Elmegaard wrote: > on my system g77 does not read the last line of file if it > is not ended by a line break. Can that be changed? Short answer: "No". Unlike `C', which uses a semicolon, FORTRAN uses the line break as its statement terminator. If you have a statement in your source file, which lacks this terminator, then that statement is invalid -- it violates the language specification. BTW, C also requires that source files be properly terminated with a line break; this is also declared in the language spec. However, GCC is somewhat tolerant here, issuing only a warning for the malformed file. (It can do this, because the line break is not required as a statement terminator). You should use an editor which does the job properly in the first place; my personal choice is vim (or gvim). Regards, Keith. |
From: Brian E. <be...@me...> - 2005-11-25 12:25:44
|
Keith MARSHALL <kei...@to...> writes: > as its statement terminator. If you have a statement in your > source file, which lacks this terminator, then that statement > is invalid -- it violates the language specification. Thanks, for the answer, but it is not the fortran files that are the problem (sorry for the confusing subject). It is when a program compiled with g77 reads text files I have the problem. > You should use an editor which does the job properly in the > first place; my personal choice is vim (or gvim). I do. I have tried to save the files with dos, unix, and mac-line breaks in emacs. -- Brian (remove the sport for mail) http://www.et.web.mek.dtu.dk/Staff/be/be.html http://www.rugbyklubben-speed.dk |
From: Keith M. <kei...@to...> - 2005-11-25 14:23:58
|
Brian Elmegaard wrote, quoting me: [concerning FORTRAN file structure] >> as its statement terminator. If you have a statement in your >> source file, which lacks this terminator, then that statement >> is invalid -- it violates the language specification. > > Thanks, for the answer, but it is not the fortran files that are > the problem (sorry for the confusing subject). It is when a > program compiled with g77 reads text files I have the problem. Hmm. Yes that is a different question from your original one, at least as I interpreted it :-) Unless you're using a fixed record length, random access data model, FORTRAN uses a line buffered model for input/output, right? That means every input record *must* be a *line* of text, and a line of text requires a line break to mark its end. (Try to WRITE a line of output, as a terminal prompt say, without a following line break, using *pure* FORTRAN-77; you can't do it, without resorting to vendor specific, non-standard language extensions. Similarly, a READ requires a newline character, to tell the I/O subsystem that the input record is complete). >> You should use an editor which does the job properly in the >> first place; my personal choice is vim (or gvim). > > I do. I have tried to save the files with dos, unix, and mac-line > breaks in emacs. Have you tried inspecting those files with `od'? Are you *really* sure that the last line is improperly terminated? Is it possible that there is a bug in your program, causing it to quit prematurly, having read the last input line, but not otherwise processed it? If you are really sure the last line of input is missing its line break terminator, then read on... When vim is used to edit text files, it treats them as a collection of lines of text, each one terminated by a line break. When such a file is written out to disk, vim guarantees that this terminator will be preserved on every line, including the last. Surely emacs should be able to do likewise? If not, perhaps you need to ensure that the edit buffer includes one additional empty line at the end, when you write it out; (and by empty, I mean *really* empty -- not even white space present). Regards, Keith. |
From: Brian E. <be...@me...> - 2005-11-26 08:14:19
|
Keith MARSHALL <kei...@to...> writes: > sure that the last line is improperly terminated? Is it possible > that there is a bug in your program, causing it to quit prematurly, > having read the last input line, but not otherwise processed it? Thanks for this. In fact I am not sure right now. What is causing the trouble is the end option to read: read(8,'(120(a))',end=2) line If there is not a line break it ends without processing the last line. At least Salford ftn95 does not do this. Which is the standard way? > will be preserved on every line, including the last. Surely emacs > should be able to do likewise? If not, perhaps you need to ensure > that the edit buffer includes one additional empty line at the end, > when you write it out; (and by empty, I mean *really* empty -- not > even white space present). I think this would need to be my last resort. A file written in notepad gives the same trouble. -- Brian (remove the sport for mail) http://www.et.web.mek.dtu.dk/Staff/be/be.html http://www.rugbyklubben-speed.dk |
From: C. <Fra...@en...> - 2005-11-26 14:19:03
|
> What is causing the trouble is the end option to read: > read(8,'(120(a))',end=2) line > If there is not a line break it ends without processing the last > line. > > At least Salford ftn95 does not do this. > > Which is the standard way? g77 is wrong in that example. Intel and Sun compilers, as well as gfortran and g95, give the same answer: character*5 line open(10,file="truc") read(10,'(A)',end=2) line print *, line stop 2 stop 1 end where file "truc" contains "12345" (no line terminator). $ g77 g77.f && ./a.out STOP 1 statement executed $ gfortran g77.f && ./a.out 12345 $ g95 g77.f && ./a.out 12345 $ ifort g77.f && ./a.out 12345 $ f90 g77.f && ./a.out 12345 I don't think it's worth reporting, because g77 is not actively maintained any more (while gcc-3.4.x is still supported, all effort about Fortran is going into the new gfortran, see below). Note that from version 4.0.0, the GCC includes a new Fortran 95 compiler, named gfortran. While gfortran is still under development, it is already quite good for F77 features. Binaries for most common platforms, including MinGW, are available from http://gcc.gnu.org/wiki/GFortran . FX |
From: Brian E. <be...@me...> - 2005-11-27 10:07:52
|
François-Xavier Coudert <Fra...@en...> writes: > Note that from version 4.0.0, the GCC includes a new Fortran 95 > compiler, named gfortran. While gfortran is still under development, > it is already quite good for F77 features. Binaries for most common > platforms, including MinGW, are available from > http://gcc.gnu.org/wiki/GFortran . Thanks, I will change to gfortran then. But, I have been waiting for gcc 4 under mingw. -- Brian (remove the sport for mail) http://www.et.web.mek.dtu.dk/Staff/be/be.html http://www.rugbyklubben-speed.dk |
From: Keith M. <kei...@us...> - 2005-11-27 13:43:22
|
On Saturday 26 November 2005 2:18 pm, François-Xavier Coudert wrote: > > What is causing the trouble is the end option to read: > > read(8,'(120(a))',end=2) line > > If there is not a line break it ends without processing the last > > line. > > > > At least Salford ftn95 does not do this. > > > > Which is the standard way? > > g77 is wrong in that example. Intel and Sun compilers, as well as > gfortran and g95, give the same answer: Does ANSI X3.9-1978 explicitly state how this situation should be handled? Unless g77 explicitly violates this standard, then you cannot say that it is "wrong"; it simply has a different, but equally legitimate implementation, even if the implementation provided by those other compilers seems to be more reasonable. Consider that FORTRAN-77 was standardised in an era when the majority of file systems stored data in disk blocks of fixed size. FORTRAN implemented a line oriented I/O model, with variable length "line" records, overlayed on this block structured disk I/O model. It is extremely unlikely that the line oriented records read, or written by a FORTRAN program would exactly fit a whole number of disk blocks. Thus, when the underlying OS level read of a data file loads the last *physical* disk block of the file into memory, it is most likely that there will be random garbage following the EOL marker on the last *logical* line of the file; if that last logical line of input lacks a proper EOL mark, the FORTRAN I/O may legitimately discard it, as part of this random garbage. You may then argue that such file systems would normally provide an EOF mark, to mark the logical end of data. This is true, but then consider that the EOF mark employed in CP/M, and copied in the original MS-DOS v1.0, was the three byte sequence `<CR><LF><SUB>', (SUB being the ASCII substitute code, often represented as Ctrl-Z). If FORTRAN is to find such an EOF mark, then it follows that the last line of the file *must* include an EOL mark, (which would be `<CR><LF>' in the MS-DOS/Win32 arena), for the block structured file to have a valid EOF mark following this last line of input. Your input file has an invalid last line -- end of story. Editors which produce text files with such invalid final records are broken, IMHO. Regards, Keith. |
From: Keith M. <kei...@us...> - 2005-11-26 14:38:11
|
On Saturday 26 November 2005 8:11 am, Brian Elmegaard wrote: > Keith MARSHALL <kei...@to...> writes: > > sure that the last line is improperly terminated? Is it possible > > that there is a bug in your program, causing it to quit prematurly, > > having read the last input line, but not otherwise processed it? > > Thanks for this. In fact I am not sure right now. > What is causing the trouble is the end option to read: > read(8,'(120(a))',end=2) line > If there is not a line break it ends without processing the last > line. Ok. There doesn't appear to be anything wrong with that. To confirm your observations, I've run this test case on my GNU/Linux box. <file class="g77-program" name="junk.f"> program junk character*120 line open (8, file='junk.in') 1 read (8, '(a)', end=2) line write (*, *) line go to 1 2 stop end </file> <file class="data" name="junk.in" creator="vim"> junk.dat Data file for testing g77 executable junk.exe This is the last regularly terminated line! </file> <output command="echo -n >>junk.in 'This line is unterminated!'" </output> <output command="od -c junk.in"> 0000000 j u n k . i n \n D a t a f i l 0000020 e f o r t e s t i n g g 7 0000040 7 e x e c u t a b l e j u n 0000060 k . e x e \n T h i s i s t h 0000100 e l a s t r e g u l a r l y 0000120 t e r m i n a t e d l i n e 0000140 ! \n T h i s l i n e i s u 0000160 n t e r m i n a t e d ! 0000174 </output> <output command="g77 -o junk.exe junk.f"> </output> <output command="./junk.exe"> junk.in Data file for testing g77 executable junk.exe This is the last regularly terminated line! </output> which confirms that your observed behaviour is standard for g77 programs -- i.e. the final unterminated line of input is swallowed by the I/O subsystem, without being passed to the user program. If I now load the junk.in file into vim, I see the status line message: `"junk.in" [noeol] 4L, 124C', which warns me that the file lacks line termination integrity on its final line. Simply writing the file out again yields the new status line message: `"junk.in" 4L, 125C written', and the defect is corrected. <output command="od -c junk.in"> 0000000 j u n k . i n \n D a t a f i l 0000020 e f o r t e s t i n g g 7 0000040 7 e x e c u t a b l e j u n 0000060 k . e x e \n T h i s i s t h 0000100 e l a s t r e g u l a r l y 0000120 t e r m i n a t e d l i n e 0000140 ! \n T h i s l i n e i s u 0000160 n t e r m i n a t e d ! \n 0000175 </output> <output command="./junk.exe"> junk.in Data file for testing g77 executable junk.exe This is the last regularly terminated line! This line is unterminated! </output> > At least Salford ftn95 does not do this. > > Which is the standard way? It's likely to be one of those areas in which the language specification is vague, allowing implementors to handle it as they see fit; (I don't have a copy of the standard document, to check). Nevertheless, flushing residual data from the I/O buffer to the user program would seem to be the most logical approach. If you believe this is a bug, you could try reporting it to the g77 maintainers, via the standard GCC bug reporting system at http://gcc.gnu.org/bugs.html > > will be preserved on every line, including the last. Surely emacs > > should be able to do likewise? If not, perhaps you need to ensure > > that the edit buffer includes one additional empty line at the end, > > when you write it out; (and by empty, I mean *really* empty -- not > > even white space present). > > I think this would need to be my last resort. A file written in > notepad gives the same trouble. I wouldn't give notepad any credence, as an editor for program files, or even for preparing program input data files :-) I've dabbled with emacs occasionally, but I don't really like it much -- I guess I'm just too much of a diehard vi fan -- and I'm not really familiar with it's many foibles; I would have thought however, that you could configure it to properly terminate the last line of files. Regards, Keith. |
From: Brian E. <be...@me...> - 2005-11-27 10:10:14
|
Keith Marshall <kei...@us...> writes: > http://gcc.gnu.org/bugs.html I will consider this. > I wouldn't give notepad any credence, as an editor for program > files, or even for preparing program input data files :-) No, but mingw is a native windows compiler. The simplest editor available on windows is notepad. > however, that you could configure it to properly terminate the last > line of files. Probably. -- Brian (remove the sport for mail) http://www.et.web.mek.dtu.dk/Staff/be/be.html http://www.rugbyklubben-speed.dk |
From: C. <Fra...@en...> - 2005-11-27 15:31:00
|
> Does ANSI X3.9-1978 explicitly state how this situation should be > handled? Unless g77 explicitly violates this standard, then you cannot > say that it is "wrong"; it simply has a different, but equally > legitimate implementation, even if the implementation provided by those > other compilers seems to be more reasonable. Well, I can say it is wrong if I think this is not the behaviour the community would like it to have. That's why I did not say "non standard-conforming", but "wrong". "wrong" includes quality-of-implementation considerations, which seems clearly not in favour of the current g77 behaviour. ;-) -- FX |
From: Michael G. <mg...@te...> - 2005-11-27 17:44:47
|
> > Does ANSI X3.9-1978 explicitly state how this situation should be > > handled? Unless g77 explicitly violates this standard, then you cannot > > say that it is "wrong"; it simply has a different, but equally > > legitimate implementation, even if the implementation provided by those > > other compilers seems to be more reasonable. >=20 > Well, I can say it is wrong if I think this is not the behaviour the > community would like it to have. That's why I did not say "non > standard-conforming", but "wrong". "wrong" includes > quality-of-implementation considerations, which seems clearly not in > favour of the current g77 behaviour. ;-) I don't think it is clever in a social sense to use the word "wrong" if all you mean to say is "it does not behave as the casual user might expect it to". I for that am constantly annoyed by the wrong (as in non standard-conforming) behavior of various text editors that omit the final newline from text files. In fact if we wouldn't have these (IMO broken) text editors then most casual users would never ever realize the difference in implementation between g77 and e.g. presumably gfortran (I don't know gfortran but am judging from other comments in this thread). So effectively you ask for g77 to change implementation to solve a problem created by (again: IMO broken) text editors. "Wrong" definitely seems the wrong (as in false, not correct) word... ;-) Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Duncan M. <mi...@mu...> - 2005-11-27 21:15:53
|
On 11/27/2005 12:44 PM, Michael Gerdau wrote: >>>Does ANSI X3.9-1978 explicitly state how this situation should be >>>handled? Unless g77 explicitly violates this standard, then you cannot >>>say that it is "wrong"; it simply has a different, but equally >>>legitimate implementation, even if the implementation provided by those >>>other compilers seems to be more reasonable. >> >>Well, I can say it is wrong if I think this is not the behaviour the >>community would like it to have. That's why I did not say "non >>standard-conforming", but "wrong". "wrong" includes >>quality-of-implementation considerations, which seems clearly not in >>favour of the current g77 behaviour. ;-) > > > I don't think it is clever in a social sense to use the word > "wrong" if all you mean to say is "it does not behave as the > casual user might expect it to". > > I for that am constantly annoyed by the wrong (as in non > standard-conforming) behavior of various text editors that > omit the final newline from text files. Which standard are you talking about? There is no standard for text editors. Duncan Murdoch > > In fact if we wouldn't have these (IMO broken) text editors then > most casual users would never ever realize the difference in > implementation between g77 and e.g. presumably gfortran (I don't > know gfortran but am judging from other comments in this thread). > > So effectively you ask for g77 to change implementation to solve > a problem created by (again: IMO broken) text editors. > > "Wrong" definitely seems the wrong (as in false, not correct) > word... ;-) > > Best, > Michael |
From: Michael G. <mg...@te...> - 2005-11-27 22:37:22
|
> Which standard are you talking about? There is no standard for text=20 > editors. I was talking about text files. But it seems I have to take back some of my earlier claim. While there are indeed a couple of definitions of text files floating around, not all definitions I found explicitly require a text file to have it's last line terminated (I'm only refering to those "definitions" that also introduce the concept of lines). I a way the requirement to have the last line being terminated be a CR/CRLF (or whatever is the line terminator) can be derived from the definition that a line is a sequence of characters followed be a line terminator (paraphrased). Therefor the last line in a file is not a line unless properly terminated (but many sources also suggest to be lenient here). In particular in a line (or record) oriented environment a "proper" line requires being terminated/delimited by a CR/CRLF. Whatever: Much to my surprise I have not been able to find anything that would qualify as a definition of text file in the strict sense of the word definition. =46WIW there are a couple of compilers out there that do indeed issue a warning when processing a sourcefile whose last line is not properly terminated but that is conjectural evidence at best. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: amores p. <lif...@ho...> - 2005-11-28 15:46:55
|
> > > > I for that am constantly annoyed by the wrong (as in non > > standard-conforming) behavior of various text editors that > > omit the final newline from text files. > >Which standard are you talking about? There is no standard for text >editors. > I'm curious about this too -- I never heard of a standard for either text editors or text files, but, someone is talking about such a standard, so I'd be curious to be educated in this matter. |
From: Ralf W. <Ral...@gm...> - 2005-11-29 16:51:08
|
* amores perros wrote on Mon, Nov 28, 2005 at 04:46:37PM CET: > > > >Which standard are you talking about? There is no standard for text > >editors. > > I'm curious about this too -- I never heard of a standard for > either text editors or text files, but, someone is talking about such > a standard, so I'd be curious to be educated in this matter. FWIW, don't ask me about applicability of this standard in this situation, but the Single Unix Specification defines a Text File as | A file that contains characters organized into one or more lines. | The lines do not contain NUL characters and none can exceed LINE_MAX | bytes in length, including the <newline> [...] It also adds that | [..] many utilities only produce predictable or meaningful output when | operating on text files. A Line is | A sequence of zero or more non-<newline>s plus a terminating | <newline>. A Newline Character (<newline>) is | A character [...] designated by '\n' in the C language. It is | unspecified whether this character is the exact sequence transmitted | to an output device by the system to accomplish the movement to the | next line. I'm pretty sure POSIX has similar definitions, but is equally (un)applicable to MinGW. SUSv3 is readable or downloadable here: http://www.opengroup.org/ And yes, an empty file (i.e., one with zero characters) is not a text file in this sense, as far as I can see. With different utilites, it's usually noted whether they are supposed to work on non-text files. E.g., the 'c99' command works on text files. No, none of this applies to Fortran, nor to non-POSIX, it's merely to counter the notion of 'text file' not being a defined term in some circumstances. Hope that helps at least a little bit, Ralf |
From: amores p. <lif...@ho...> - 2005-11-29 23:49:06
|
>From: Ralf Wildenhues >To: mingw-users >Subject: Re: [Mingw-users] Re: Reading files with g77 >Date: Tue, 29 Nov 2005 08:50:38 +0100 > >* amores perros wrote on Mon, Nov 28, 2005 at 04:46:37PM CET: > > > > > >Which standard are you talking about? There is no standard for text > > >editors. > > (My question:) > > I'm curious about this too -- I never heard of a standard for > > either text editors or text files, but, someone is talking about such > > a standard, so I'd be curious to be educated in this matter. > >FWIW, don't ask me about applicability of this standard in this >situation, but the Single Unix Specification defines a Text File as ... Ah, I'm not familiar with Single Unix Specification. So, does this codify a convention which has existed on Unix so long that it is ancestral to most other operating systems? (I've never heard of that convention, but that hardly proves anything :)) Did this convention go to any other places from its (I presume) birthplace on unix? I assume that because mingw is an attempt to port unix utilities to Windows, that unix conventions are relevant -- surely there is various traffic & discussion about unix conventional directories & line terminations in general in mingw development :) (and thank you for the answer about SUS and the pointer for further info, which I need to check out.) Cordially, Perry |
From: Benjamin R. <b.r...@tu...> - 2005-12-03 16:28:30
|
Hi Perry, all, "amores perros" writes: > So, does this codify a convention which has existed on Unix so long > that it is ancestral to most other operating systems? It codifies the behaviour of the traditional C runtime library. As most programs are written in C or in a language that is itself written in C, this is the convention of a lot of programs, at least if you care about portability. benny |
From: Brian E. <be...@me...> - 2005-11-28 09:18:15
|
Michael Gerdau <mg...@te...> writes: > In fact if we wouldn't have these (IMO broken) text editors then Just learned that emacs is not broken. require-final-newline's value is nil Documentation: *Value of t says silently ensure a file ends in a newline when it is saved. Non-nil but not t says ask user whether to add a newline when there isn't one. nil means don't add newlines. -- Brian (remove the sport for mail) http://www.et.web.mek.dtu.dk/Staff/be/be.html http://www.rugbyklubben-speed.dk |
From: Tuomo L. <dj...@mb...> - 2005-11-25 14:29:52
|
Keith MARSHALL wrote: >>on my system g77 does not read the last line of file if it >>is not ended by a line break. Can that be changed? ... > You should use an editor which does the job properly in the > first place; my personal choice is vim (or gvim). Another, admittedly worse than using a proper editor or fixing the one you use, way to tackle that problem is to have an empty "line" at the end of your source code. Provided that your editor doesn't do trimming, the effect should be exactly the same as when using a proper editor without that extra line. I wonder, though, why is it that so many editors, contrary to the obvious interpretation, think end-of-line as in-between-lines. Curious as I am, I would like to hear proper argumentation from people who think that is how it should be handled. -- Tuomo ... Have an adequate day |
From: Duncan M. <mi...@mu...> - 2005-11-25 14:47:58
|
On 11/25/2005 9:29 AM, Tuomo Latto wrote: > Keith MARSHALL wrote: >>>on my system g77 does not read the last line of file if it >>>is not ended by a line break. Can that be changed? > ... >> You should use an editor which does the job properly in the >> first place; my personal choice is vim (or gvim). > > Another, admittedly worse than using a proper editor or fixing > the one you use, way to tackle that problem is to have an empty > "line" at the end of your source code. > Provided that your editor doesn't do trimming, the effect should > be exactly the same as when using a proper editor without > that extra line. > > I wonder, though, why is it that so many editors, contrary to the > obvious interpretation, think end-of-line as in-between-lines. > Curious as I am, I would like to hear proper argumentation from > people who think that is how it should be handled. The names of the end of line characters in the ASCII set are "Carriage Return" and "Line Feed", not "End of line" or "In between lines". Interpreting those literally, both should be required to advance to the beginning of the next line (as in the DOS/Windows style, unlike the Unix LF-only style). At the end of a file, it should be optional whether to advance to the next line or not. It is clear that the current line has ended (because the file did), but it should be up to the person who wrote the file to decide whether to follow that by an advance to the beginning of the next line, i.e. a terminating end of line should be optional. Interpreting CR/LF or LF or EOF as EOL is a logical decision, part of whatever interpreter is acting on the file. It's not a natural part of storing text in a file. If some interpreter (e.g. a C compiler or a Fortran run-time) wants to say that EOL must be LF, then that's fine, but it would be a lot more sensible to say that any of the three markers could serve as EOL, unless there's a specific interpretation for the other possibilities. Duncan Murdoch |
From: Keith M. <kei...@to...> - 2005-11-25 15:31:59
|
Duncan Murdoch wrote: > Interpreting CR/LF or LF or EOF as EOL is a logical decision, > part of whatever interpreter is acting on the file. It's not > a natural part of storing text in a file. If some interpreter > (e.g. a C compiler or a Fortran run-time) wants to say that EOL > must be LF, then that's fine, but it would be a lot more sensible > to say that any of the three markers could serve as EOL, unless > there's a specific interpretation for the other possibilities. Granted, this argument does appear logical. But, consider... <file name="file-a" content="text/last-line-no-EOL"> This is file-a .... This is the last line of file-a </file> <file name="file-b" content="text"> This is file-b ... file-b: end of file </file> Now, invoke `cat file-a file-b', and you will see <output> This is file-a .... This is the last line of file-aThis is file-b ... file-b: end of file </output> Not, I would suggest, what you would expect, nor hope to achieve. Imagine the havoc that could ensue, if `file-a' were a C++ header, ending in a `//' comment line, and its #include were immediately followed by another #include line, (or maybe worse, a #if), in the including source. Regards, Keith. |
From: amores p. <lif...@ho...> - 2005-11-25 16:51:30
|
>From: Keith MARSHALL >To: mingw-users >Subject: Re: [Mingw-users] Reading files with g77 >Date: Fri, 25 Nov 2005 15:08:26 +0000 > > >Granted, this argument does appear logical. But, consider... > ><file name="file-a" content="text/last-line-no-EOL"> >This is file-a >.... >This is the last line of file-a ></file> > ><file name="file-b" content="text"> >This is file-b >... >file-b: end of file ></file> > >Now, invoke `cat file-a file-b', and you will see > ><output> >This is file-a >.... >This is the last line of file-aThis is file-b >... >file-b: end of file ></output> > >Not, I would suggest, what you would expect, nor hope to achieve. >Imagine the havoc that could ensue, if `file-a' were a C++ header, >ending in a `//' comment line, and its #include were immediately >followed by another #include line, (or maybe worse, a #if), in the >including source. > I've been bitten by this when I ran a script of mine, which pulls a bunch of SQL scripts from a revision control system, stored in individual files, and concatenates them all to submit in a single call. Some of the files did not end in line terminations of whatever appropriate kind, and so the first line in the next file got pulled into the end of a preceding line, causing syntax errors. Cordially, Perry |