Thread (1 message) 1 message, 1 author, 2022-12-19

Re: [PATCH] tests: make 'test_oid' print trailing newline

From: Junio C Hamano <hidden>
Date: 2022-12-19 23:58:59

Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
@@ -826,7 +827,7 @@ test_expect_success 'test_oid can look up data for SHA-1' '
 	grep "^00*\$" actual &&
...
I also vaguely recall (although probably nobody worries about such a
platform anymore) that POSIX utilities left themselves room to not work
on things that weren't \n-terminated.
[jc: totally irrelevant curiosity-hunt]

I think you have in mind the combination of these.

 * "3.195 Incomplete Line" defines an incomple line as "A sequence
   of one or more non-<newline> characters at the end of the file."

 * "3.403 Text File" defines a text file to be "A file that contains
   characters organized into zero or more lines. ... many utilities
   only produce predictable or meaningful output when operating on
   text files".

 * "INPUT FILES" section of "grep" for example says "The input files
   shall be text files".

It may look unclear if "an incomplete line" is supposed to be a
"line", and if it is not, then the output from "test_oid zero" we
are grepping in in the above snippet is not a "text file".

The "INPUT FILES" section of "sort" states something interesting.

    The input files shall be text files, except that the sort
    utility shall add a <newline> to the end of a file ending with
    an incomplete last line.

Why is this interesting?  Because it smells like it is clarifying
whether it makes file a text to end in an incomplete line, but it
does not do any such thing ;-)  You can read it in two ways:

 * You must feed text files to "sort", but if you did feed a file
   that ends with an incomplete line, the utility adds <newline> at
   the end, which makes it a text, so the inputs to the utilities
   all becomes "text".

   Under this reading, you can as an exception feed a non-text file
   to the utility, as long as its non-text-ness is limited to ending
   with an incomplete line.  So, a file that ends with an incomplete
   line is *not* text.

 * You must feed text files to "sort", and an text file that ends
   with an incomplete line gains terminating <newline> at the end of
   that last line, so a hit on that line will be shown, terminated
   with <newline>, just like a hit on any other line.

   Under this reading, a text file may or may not end with an
   incomplete line, so a file that ends with an incomplete line is
   text.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html

So I dunno.

In any case, I think it is a good practice to avoid having to worry
about how the standard utilities would behave by making sure our
lines are complete.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help