On Sun, Oct 14, 2012 at 02:23:43PM +0200, Nicolas Cellier wrote: > Yes, that's weird. > But I think the inconsistency comes from Unix that insist on having a > terminating LF.
Not so. The line end convention on Unix is consistent with what Igor is expecting to see. But it's just a convention that is generally adopted by programs written for Unix, that's all. The operating system does nothing to enforce it. > > (FileDirectory default fileNamed: 'foo') truncate; nextPut: $a; close. > > $ od -c foo > 0000000 a > 0000001 > > $ wc -l foo > 0 foo > > (FileDirectory default fileNamed: 'foo') truncate; nextPut: $a; lf; close. > > $ od -c foo > 0000000 a \n > 0000002 > > $ wc -l foo > 1 foo > > In the past I had to care of appending a terminal line ending > character to make sure some unix scripts/tools would work. > For example remember that not having a terminal line ending in C > source can lead to a warning or error cdepending on your > compiler/flags... > Unfortunately, we have to admit that common sense in case of line > ending has been a bit perverted by our dear OS providers... Record-oriented file systems are quite common, and are still widely used. If you have an operating system (such as Unix or Windows) without record-oriented files, then common sense would tell you to adopt a line ending convention and use it consistently in all programs that need to read "records". Given that records in a file might be empty or blank, it would also be good common sense to ensure that an empty record at the end of a file should not go missing just because it is at the end of the file. Dave
