NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: lib/48881: /etc/hosts file parsing broken (since Aug 2013)



The following reply was made to PR lib/48881; it has been noted by GNATS.

From: "Greg A. Woods" <woods%planix.ca@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: lib/48881: /etc/hosts file parsing broken (since Aug 2013)
Date: Fri, 13 Jun 2014 20:05:16 -0700

 At Fri, 13 Jun 2014 23:10:01 +0000 (UTC), Robert Elz 
<kre%munnari.OZ.AU@localhost> wr=
 ote:
 Subject: Re: lib/48881: /etc/hosts file parsing broken (since Aug 2013)
 >=20
 >  Apart from your QP encoded patch being totally mangled by gnats,
 
 Yes, gnats should probably given a helping hand to get it to try to
 catch up with the now decades-old use of MIME.
 
 >  That should not be "fixed" - unix lines are terminated by newlines, a "l=
 ine"
 >  that has no terminating newline is not a line at all, and should be
 >  ignored in places like that - in particular, one way (aside from using
 >  brain dead editors) to get such a state, is to write the file back to
 >  a full filesystem, the file will be truncated at the end of the last free
 >  available block, almost certainly in the middle of a line - using that b=
 roken
 >  line as if it were valid data would be a mistake.
 
 I understand what you are saying, and for the most part I agree with
 you, but I think there are worse problems caused by not parsing the text
 after the last newline in files that don't end in a newline.
 
 ed and vi will both quietly open such files and show that last "line"
 and also happily quit without asking to save the file (though they will
 also both silently add a final newline if any part of the file is
 changed and it is saved).  (I think maybe they should both warn that the
 file was read without a final newline and ask to save the file on quit
 even if no changes were made by the user.)
 
 less, more, grep, awk, and probably most other tools one might use to
 examine text files will all happily read the text after the final
 newline and parse or show it as a true "line" of text in the file.
 
 About the only way a more naive admin will discover a problem with a
 missing final newline is to hexdump the file, or maybe they might cat or
 tail the file and notice the next shell prompt doesn't appear at the
 beginning of the line after the end of the file's contents.
 
 --=20
                                                Greg A. Woods
                                                Planix, Inc.
 
 <woods%planix.com@localhost>       +1 250 762-7675        
http://www.planix.com/
 


Home | Main Index | Thread Index | Old Index