On Tue, 9 Jul 2019 10:48:32 -0400 Chet Ramey <chet.ra...@case.edu> wrote:
> On 7/9/19 6:16 AM, k...@plushkava.net wrote: > > >> Did you have a look at the 'conditional.sh' script too? Looks like the > >> '-N' switch compares only the integer part of the timestamp seconds. > > > > The stat structure supports timestamp fields of nanosecond granularity > > since POSIX.1-2008, so it should work. I tried a simple test case here, and > > the behaviour of -N seems generally broken: > > > > # f=$(mktemp); [[ -N $f ]]; echo $?; touch -m "$f"; [[ -N $f ]]; echo $? > > 0 > > 0 > > > > I expected the value of $? to be non-zero at first, followed by 0 after > > updating the mtime. > > The code just returns (atime <= mtime), and has since 1997. It uses the > st_atime and st_mtime fields. I should update it to use timespecs if > they're available, and (mtime > atime) might work closer to your > expectations. > > After the call to mktemp, the atime and mtime are the same, so the test > returns true. I see. Indeed, it is confusing to me because I would not consider a file whose atime and mtime are equal to have been "modified since it was last read", notwithstanding that the newborn file has not yet been read at all. I think that it would help for the documentation to address this nuance. As for the possibility of using the timespec fields, that would be terrific. > > Using the test command that ships with GNU coreutils (v8.31) exhibits the > same problem: > > > > # f=$(mktemp); command test -N "$f"; echo $?; touch -m "$f"; command test > > -N "$f"; echo $? > > 0 > > 0 > > It might, but that's not what you tested. This runs the builtin test. Ah, how silly of me. I had also tried with the fully qualified path of test before posting, at least. -- Kerin Millar <k...@plushkava.net>
