1

This question and this question point out that generally the standard is to end text files with newline characters to meet the POSIX standard, and this is something expected with GNU tools and other POSIX compliant tools.

However, as a C# developer, I know that tools that work with csproj files generally don't include a terminating newline character. I've also seen tools that remove the terminating newline from json and xml files. I think it makes sense to avoid including a newline at the end of text files if the common tools that work with the files would just end up removing them again.

So, what are some types of text files that shouldn't end with newline characters due to tooling?

Aaron Franke
  • 955
  • 5
    A file that don't end with a newline is simply not a text file in the POSIX sense. It's a stream of bytes. Tools that can work with a stream of bytes should be able to use these. Refer to the tool's manual. – Kusalananda Mar 21 '20 at 23:14
  • 2
    Programs that remove trailing newlines from textfiles seem to be broken. I would avoid such programs. – schily Mar 22 '20 at 13:02

2 Answers2

2

Though not exactly a text file, a symbolic link is effectively a tiny file containing a piece of text (often fitting into the inode itself, so no data blocks need to be allocated to the file).

A symbolic link can end with a newline, but under the most common circumstances it shouldn't.

Another type of file that should not (well, cannot) end with a newline is the empty file.

In UNIX, a text file is either empty, or contains one or more possibly empty lines, each of which is terminated by a newline. If the last line isn't terminated by a newline, the file isn't a proper text file.

The empty file contains no bytes at all; the moment you add a newline, you have changed its "type" from empty to non-empty.

Kaz
  • 8,273
-3

a text file used as input for search terms processed by grep -f must not end with newline (** in text editor) otherwise that would match everything

you can try for yourself on this example
grep not finding all instances of gene

screenshot

Edit: please note question is about collecting examples where "text files shouldn't end with newline characters due to tooling." Although my first statement does not apply in general it is a perfectly example for such "type of text file" (text editor created file) and therefore valid in context of question, because that is what everyone experience when using a text editor.

It doesn't meant as broad statement regarding \n newline character on file system level but as example for corner case from a normal user's perspective

thx @Kusalananda @ilkkachu for clarifying in real that is two \n\n newline characters (although one is silently added by text editor and therefore invisible)

alecxs
  • 564
  • 2
    no, that's wrong. First of all, the pattern file can contain multiple patterns, on distinct lines, so it must be able to deal with newlines. Second, the standard actually demands that they are terminated with newlines: "-f pattern_file Read one or more patterns from the file named by the pathname pattern_file. Patterns in pattern_file shall be terminated by a ." And, umm, I'm not sure how the linked question shows that newlines don't work? – ilkkachu Jan 18 '21 at 00:53
  • @ilkkachu please try it. i can post a screenshot if you don't believe it matters. yes the file contain multiple patterns, and if the file is terminated (or contain) any newlines ^$ grep will treat it as zero length pattern which will match every line – alecxs Jan 18 '21 at 04:05
  • 2
    A newline is not the same as an empty line. You get an empty line if you have two consecutive newline characters (or if the file starts with a newline character). – Kusalananda Jan 18 '21 at 05:42
  • @Kusalananda thx will check this again i just copy&pasted example in some text file, it might happend i accidentially terminated with \n\n – alecxs Jan 18 '21 at 07:34
  • @alecxs, I did try. printf '15\n^7[12]\n' > patterns.txt; seq 100 | grep -f patterns.txt prints 15, 71, 72. If you add another newline, creating an empty line, then it matches all input lines, like Kusalananda said. FWIW, GNU grep doesn't care if the pattern file is missing a newline. – ilkkachu Jan 18 '21 at 12:33
  • @ilkkachu me too. tried again now, this time i did not copy&paste but typed every line manually. result was if i finish with newline grep matches every line, only if i remove all trailing newlines grep works as desired (with linked example) https://i.stack.imgur.com/0PnUZ.png https://i.stack.imgur.com/8DmJe.png (i marked text with ctrl + a on both screenshots) – alecxs Jan 18 '21 at 13:06
  • @alecxs, check with something like od -c file1 what the file contains. If your editor always adds the final newline, but doesn't show an empty line after it, then you might have accidentally added an extra line. That's actually exactly what vi does. – ilkkachu Jan 18 '21 at 21:28
  • @ilkkachu right. hexdump shows 0a 0a. although it's not accidentally added - furthermore i can't remove both of them at all – alecxs Jan 18 '21 at 22:14