Comparing the time of a symlink
Clash Royale CLAN TAG#URR8PPP
I want to check whether link lnkfile
is older than a regular reference file reffile
.
The bash test
builtin dereferences links, so test lnkfile -ot reffile
compares the target of lnkfile
, not the link itself.
Is there a way to make the test
builtin not follow symlinks? Otherwise, how can I compare the time of a symlink?
bash shell-script symlink timestamps
add a comment |
I want to check whether link lnkfile
is older than a regular reference file reffile
.
The bash test
builtin dereferences links, so test lnkfile -ot reffile
compares the target of lnkfile
, not the link itself.
Is there a way to make the test
builtin not follow symlinks? Otherwise, how can I compare the time of a symlink?
bash shell-script symlink timestamps
add a comment |
I want to check whether link lnkfile
is older than a regular reference file reffile
.
The bash test
builtin dereferences links, so test lnkfile -ot reffile
compares the target of lnkfile
, not the link itself.
Is there a way to make the test
builtin not follow symlinks? Otherwise, how can I compare the time of a symlink?
bash shell-script symlink timestamps
I want to check whether link lnkfile
is older than a regular reference file reffile
.
The bash test
builtin dereferences links, so test lnkfile -ot reffile
compares the target of lnkfile
, not the link itself.
Is there a way to make the test
builtin not follow symlinks? Otherwise, how can I compare the time of a symlink?
bash shell-script symlink timestamps
bash shell-script symlink timestamps
edited Jan 21 at 23:12
Jeff Schaller
41.1k1056131
41.1k1056131
asked Jan 21 at 22:02
L. LevrelL. Levrel
1,322413
1,322413
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
I don't think there is a way with test
, but you could use find
.
test "$(find reffile -prune -newer lnkfile)" && command
Here, find
returns output if lnkfile
is older than reffile
. test
without an option is equivalent to test -n
. This is true if the length of the string is nonzero. Hence, if there is output from find
, command
is executed.
In the comments, I was asked to make a comparison of this solution vs. stat
. Firstly, I find the stat
approach perfectly fine.
I did a benchmark to compare. I repeated the test a few times, alternating, and got similar results.
$ time (for i in 1..1000; do test "$(stat --format=%Z a)" -lt "$(stat --format=%Z b)" && echo foo > /dev/null ; done)
================
CPU 101%
CPU 104%
user 1.264
system 0.942
total 2.108
$ time (for i in 1..1000; do test "$(find b -newer a)" && echo foo > /dev/null ; done)
================
CPU 104%
user 0.693
system 0.526
total 1.164
I looks like find
is almost twice as fast, perhaps because it's a single process rather than two stats
? I'm not sure how else to compare them; please comment if there are other relevant aspects you can think of.
Here are some other differences, as per Stéphane Chazelas's comments below:
Other differences are: the
find
one is standard. while thestat
one needs the GNU implementation ofstat
. Thestat
one won't work for files modified within the same second (whilefind
should work on systems where sub-second granularity for timestamps is supported). Neitherfind
norstat
support arbitrary file names.
You'll find other differences if either of the files cannot be
stat()
ed.
Whattest
implementation do you have that does not have-n
? It's a standard option... Also quote the command substitution.
– Kusalananda
Jan 21 at 22:50
@Kusalananda I'm just confirming that no options is identical to-n
, so it's easier to grep theman
. Good point with the quote. Thanks.
– Sparhawk
Jan 21 at 22:56
I misunderstood what you were saying about-n
and read it as "there is no-n
option" instead of "test
without an option is the same astest -n
".
– Kusalananda
Jan 22 at 0:13
1
@Kusalananda Ah got it. I edited to clarify my ambiguous language. Thanks again.
– Sparhawk
Jan 22 at 1:25
1
Thank you, I'm convinced. It's striking to see how the process calls dominate the total overhead of these loops!
– L. Levrel
Jan 22 at 13:21
|
show 8 more comments
As far as I know, bash doesn't offer any versions of -ot
(and the like) which avoid dereferencing symlinks.
What you can do instead is use GNU stat (which doesn't dereference symbolic links without -L
) and compare their mtime epochs numerically:
if (( "$(stat --format=%Z lnkfile)" < "$(stat --format=%Z reffile)" )); then
# lnkfile is older
fi
Thank you for answering. Now I'm well embarrassed with two valid answers: what do you think about Sparhawk's solution? Especially in re efficiency, since I'll have scores of link-and-file pairs to test.
– L. Levrel
Jan 22 at 8:50
add a comment |
With zsh
5.6 or above (for the nanosecond precision), you could do it with builtins only with:
zmodload zsh/stat
if
stat -LA lnktime -F '%021s%N' +mtime -- $lnkfile &&
stat -A reftime -F '%021s%N' +mtime -- $reffile &&
[[ $lnktime < $reftime ]]
then
print -r -- $lnkfile is older than $reffile
fi
Which would work regardless of what characters or non-characters the file names contain and compare timestamps down to the nanosecond.
We're comparing the timestamps as strings (number of nanoseconds as a decimal string representation zero-padded to 30 digits) instead of floating points because the typical double precision floating points of a x86_64 PC running GNU/Linux at least don't have enough precision to store numbers like 1548195897.775033155
so you would not be able to tell apart two files modified today within the same 100 nanoseconds.
$ ((1548195897.775033155 < 1548195897.775033255)) && echo yes
$ [[ 1548195897775033155 < 1548195897775033255 ]] && echo yes
yes
Thank you for the details. Could you expand about "non-characters" please? I've tested with a filename containing newline: GNUstat
shows no problem.find
will replace the newline with?
if output goes to the terminal, otherwise it is preserved (which is the case in Sparhawk's answer, but anyway we're just testing if there's any output, so?
would be fine). All substitutions are double-quoted to avoid word splitting.
– L. Levrel
Jan 23 at 10:00
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f495864%2fcomparing-the-time-of-a-symlink%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
I don't think there is a way with test
, but you could use find
.
test "$(find reffile -prune -newer lnkfile)" && command
Here, find
returns output if lnkfile
is older than reffile
. test
without an option is equivalent to test -n
. This is true if the length of the string is nonzero. Hence, if there is output from find
, command
is executed.
In the comments, I was asked to make a comparison of this solution vs. stat
. Firstly, I find the stat
approach perfectly fine.
I did a benchmark to compare. I repeated the test a few times, alternating, and got similar results.
$ time (for i in 1..1000; do test "$(stat --format=%Z a)" -lt "$(stat --format=%Z b)" && echo foo > /dev/null ; done)
================
CPU 101%
CPU 104%
user 1.264
system 0.942
total 2.108
$ time (for i in 1..1000; do test "$(find b -newer a)" && echo foo > /dev/null ; done)
================
CPU 104%
user 0.693
system 0.526
total 1.164
I looks like find
is almost twice as fast, perhaps because it's a single process rather than two stats
? I'm not sure how else to compare them; please comment if there are other relevant aspects you can think of.
Here are some other differences, as per Stéphane Chazelas's comments below:
Other differences are: the
find
one is standard. while thestat
one needs the GNU implementation ofstat
. Thestat
one won't work for files modified within the same second (whilefind
should work on systems where sub-second granularity for timestamps is supported). Neitherfind
norstat
support arbitrary file names.
You'll find other differences if either of the files cannot be
stat()
ed.
Whattest
implementation do you have that does not have-n
? It's a standard option... Also quote the command substitution.
– Kusalananda
Jan 21 at 22:50
@Kusalananda I'm just confirming that no options is identical to-n
, so it's easier to grep theman
. Good point with the quote. Thanks.
– Sparhawk
Jan 21 at 22:56
I misunderstood what you were saying about-n
and read it as "there is no-n
option" instead of "test
without an option is the same astest -n
".
– Kusalananda
Jan 22 at 0:13
1
@Kusalananda Ah got it. I edited to clarify my ambiguous language. Thanks again.
– Sparhawk
Jan 22 at 1:25
1
Thank you, I'm convinced. It's striking to see how the process calls dominate the total overhead of these loops!
– L. Levrel
Jan 22 at 13:21
|
show 8 more comments
I don't think there is a way with test
, but you could use find
.
test "$(find reffile -prune -newer lnkfile)" && command
Here, find
returns output if lnkfile
is older than reffile
. test
without an option is equivalent to test -n
. This is true if the length of the string is nonzero. Hence, if there is output from find
, command
is executed.
In the comments, I was asked to make a comparison of this solution vs. stat
. Firstly, I find the stat
approach perfectly fine.
I did a benchmark to compare. I repeated the test a few times, alternating, and got similar results.
$ time (for i in 1..1000; do test "$(stat --format=%Z a)" -lt "$(stat --format=%Z b)" && echo foo > /dev/null ; done)
================
CPU 101%
CPU 104%
user 1.264
system 0.942
total 2.108
$ time (for i in 1..1000; do test "$(find b -newer a)" && echo foo > /dev/null ; done)
================
CPU 104%
user 0.693
system 0.526
total 1.164
I looks like find
is almost twice as fast, perhaps because it's a single process rather than two stats
? I'm not sure how else to compare them; please comment if there are other relevant aspects you can think of.
Here are some other differences, as per Stéphane Chazelas's comments below:
Other differences are: the
find
one is standard. while thestat
one needs the GNU implementation ofstat
. Thestat
one won't work for files modified within the same second (whilefind
should work on systems where sub-second granularity for timestamps is supported). Neitherfind
norstat
support arbitrary file names.
You'll find other differences if either of the files cannot be
stat()
ed.
Whattest
implementation do you have that does not have-n
? It's a standard option... Also quote the command substitution.
– Kusalananda
Jan 21 at 22:50
@Kusalananda I'm just confirming that no options is identical to-n
, so it's easier to grep theman
. Good point with the quote. Thanks.
– Sparhawk
Jan 21 at 22:56
I misunderstood what you were saying about-n
and read it as "there is no-n
option" instead of "test
without an option is the same astest -n
".
– Kusalananda
Jan 22 at 0:13
1
@Kusalananda Ah got it. I edited to clarify my ambiguous language. Thanks again.
– Sparhawk
Jan 22 at 1:25
1
Thank you, I'm convinced. It's striking to see how the process calls dominate the total overhead of these loops!
– L. Levrel
Jan 22 at 13:21
|
show 8 more comments
I don't think there is a way with test
, but you could use find
.
test "$(find reffile -prune -newer lnkfile)" && command
Here, find
returns output if lnkfile
is older than reffile
. test
without an option is equivalent to test -n
. This is true if the length of the string is nonzero. Hence, if there is output from find
, command
is executed.
In the comments, I was asked to make a comparison of this solution vs. stat
. Firstly, I find the stat
approach perfectly fine.
I did a benchmark to compare. I repeated the test a few times, alternating, and got similar results.
$ time (for i in 1..1000; do test "$(stat --format=%Z a)" -lt "$(stat --format=%Z b)" && echo foo > /dev/null ; done)
================
CPU 101%
CPU 104%
user 1.264
system 0.942
total 2.108
$ time (for i in 1..1000; do test "$(find b -newer a)" && echo foo > /dev/null ; done)
================
CPU 104%
user 0.693
system 0.526
total 1.164
I looks like find
is almost twice as fast, perhaps because it's a single process rather than two stats
? I'm not sure how else to compare them; please comment if there are other relevant aspects you can think of.
Here are some other differences, as per Stéphane Chazelas's comments below:
Other differences are: the
find
one is standard. while thestat
one needs the GNU implementation ofstat
. Thestat
one won't work for files modified within the same second (whilefind
should work on systems where sub-second granularity for timestamps is supported). Neitherfind
norstat
support arbitrary file names.
You'll find other differences if either of the files cannot be
stat()
ed.
I don't think there is a way with test
, but you could use find
.
test "$(find reffile -prune -newer lnkfile)" && command
Here, find
returns output if lnkfile
is older than reffile
. test
without an option is equivalent to test -n
. This is true if the length of the string is nonzero. Hence, if there is output from find
, command
is executed.
In the comments, I was asked to make a comparison of this solution vs. stat
. Firstly, I find the stat
approach perfectly fine.
I did a benchmark to compare. I repeated the test a few times, alternating, and got similar results.
$ time (for i in 1..1000; do test "$(stat --format=%Z a)" -lt "$(stat --format=%Z b)" && echo foo > /dev/null ; done)
================
CPU 101%
CPU 104%
user 1.264
system 0.942
total 2.108
$ time (for i in 1..1000; do test "$(find b -newer a)" && echo foo > /dev/null ; done)
================
CPU 104%
user 0.693
system 0.526
total 1.164
I looks like find
is almost twice as fast, perhaps because it's a single process rather than two stats
? I'm not sure how else to compare them; please comment if there are other relevant aspects you can think of.
Here are some other differences, as per Stéphane Chazelas's comments below:
Other differences are: the
find
one is standard. while thestat
one needs the GNU implementation ofstat
. Thestat
one won't work for files modified within the same second (whilefind
should work on systems where sub-second granularity for timestamps is supported). Neitherfind
norstat
support arbitrary file names.
You'll find other differences if either of the files cannot be
stat()
ed.
edited Jan 22 at 23:28
answered Jan 21 at 22:15
SparhawkSparhawk
9,59864093
9,59864093
Whattest
implementation do you have that does not have-n
? It's a standard option... Also quote the command substitution.
– Kusalananda
Jan 21 at 22:50
@Kusalananda I'm just confirming that no options is identical to-n
, so it's easier to grep theman
. Good point with the quote. Thanks.
– Sparhawk
Jan 21 at 22:56
I misunderstood what you were saying about-n
and read it as "there is no-n
option" instead of "test
without an option is the same astest -n
".
– Kusalananda
Jan 22 at 0:13
1
@Kusalananda Ah got it. I edited to clarify my ambiguous language. Thanks again.
– Sparhawk
Jan 22 at 1:25
1
Thank you, I'm convinced. It's striking to see how the process calls dominate the total overhead of these loops!
– L. Levrel
Jan 22 at 13:21
|
show 8 more comments
Whattest
implementation do you have that does not have-n
? It's a standard option... Also quote the command substitution.
– Kusalananda
Jan 21 at 22:50
@Kusalananda I'm just confirming that no options is identical to-n
, so it's easier to grep theman
. Good point with the quote. Thanks.
– Sparhawk
Jan 21 at 22:56
I misunderstood what you were saying about-n
and read it as "there is no-n
option" instead of "test
without an option is the same astest -n
".
– Kusalananda
Jan 22 at 0:13
1
@Kusalananda Ah got it. I edited to clarify my ambiguous language. Thanks again.
– Sparhawk
Jan 22 at 1:25
1
Thank you, I'm convinced. It's striking to see how the process calls dominate the total overhead of these loops!
– L. Levrel
Jan 22 at 13:21
What
test
implementation do you have that does not have -n
? It's a standard option... Also quote the command substitution.– Kusalananda
Jan 21 at 22:50
What
test
implementation do you have that does not have -n
? It's a standard option... Also quote the command substitution.– Kusalananda
Jan 21 at 22:50
@Kusalananda I'm just confirming that no options is identical to
-n
, so it's easier to grep the man
. Good point with the quote. Thanks.– Sparhawk
Jan 21 at 22:56
@Kusalananda I'm just confirming that no options is identical to
-n
, so it's easier to grep the man
. Good point with the quote. Thanks.– Sparhawk
Jan 21 at 22:56
I misunderstood what you were saying about
-n
and read it as "there is no -n
option" instead of "test
without an option is the same as test -n
".– Kusalananda
Jan 22 at 0:13
I misunderstood what you were saying about
-n
and read it as "there is no -n
option" instead of "test
without an option is the same as test -n
".– Kusalananda
Jan 22 at 0:13
1
1
@Kusalananda Ah got it. I edited to clarify my ambiguous language. Thanks again.
– Sparhawk
Jan 22 at 1:25
@Kusalananda Ah got it. I edited to clarify my ambiguous language. Thanks again.
– Sparhawk
Jan 22 at 1:25
1
1
Thank you, I'm convinced. It's striking to see how the process calls dominate the total overhead of these loops!
– L. Levrel
Jan 22 at 13:21
Thank you, I'm convinced. It's striking to see how the process calls dominate the total overhead of these loops!
– L. Levrel
Jan 22 at 13:21
|
show 8 more comments
As far as I know, bash doesn't offer any versions of -ot
(and the like) which avoid dereferencing symlinks.
What you can do instead is use GNU stat (which doesn't dereference symbolic links without -L
) and compare their mtime epochs numerically:
if (( "$(stat --format=%Z lnkfile)" < "$(stat --format=%Z reffile)" )); then
# lnkfile is older
fi
Thank you for answering. Now I'm well embarrassed with two valid answers: what do you think about Sparhawk's solution? Especially in re efficiency, since I'll have scores of link-and-file pairs to test.
– L. Levrel
Jan 22 at 8:50
add a comment |
As far as I know, bash doesn't offer any versions of -ot
(and the like) which avoid dereferencing symlinks.
What you can do instead is use GNU stat (which doesn't dereference symbolic links without -L
) and compare their mtime epochs numerically:
if (( "$(stat --format=%Z lnkfile)" < "$(stat --format=%Z reffile)" )); then
# lnkfile is older
fi
Thank you for answering. Now I'm well embarrassed with two valid answers: what do you think about Sparhawk's solution? Especially in re efficiency, since I'll have scores of link-and-file pairs to test.
– L. Levrel
Jan 22 at 8:50
add a comment |
As far as I know, bash doesn't offer any versions of -ot
(and the like) which avoid dereferencing symlinks.
What you can do instead is use GNU stat (which doesn't dereference symbolic links without -L
) and compare their mtime epochs numerically:
if (( "$(stat --format=%Z lnkfile)" < "$(stat --format=%Z reffile)" )); then
# lnkfile is older
fi
As far as I know, bash doesn't offer any versions of -ot
(and the like) which avoid dereferencing symlinks.
What you can do instead is use GNU stat (which doesn't dereference symbolic links without -L
) and compare their mtime epochs numerically:
if (( "$(stat --format=%Z lnkfile)" < "$(stat --format=%Z reffile)" )); then
# lnkfile is older
fi
answered Jan 21 at 22:08
Chris DownChris Down
80.2k14189202
80.2k14189202
Thank you for answering. Now I'm well embarrassed with two valid answers: what do you think about Sparhawk's solution? Especially in re efficiency, since I'll have scores of link-and-file pairs to test.
– L. Levrel
Jan 22 at 8:50
add a comment |
Thank you for answering. Now I'm well embarrassed with two valid answers: what do you think about Sparhawk's solution? Especially in re efficiency, since I'll have scores of link-and-file pairs to test.
– L. Levrel
Jan 22 at 8:50
Thank you for answering. Now I'm well embarrassed with two valid answers: what do you think about Sparhawk's solution? Especially in re efficiency, since I'll have scores of link-and-file pairs to test.
– L. Levrel
Jan 22 at 8:50
Thank you for answering. Now I'm well embarrassed with two valid answers: what do you think about Sparhawk's solution? Especially in re efficiency, since I'll have scores of link-and-file pairs to test.
– L. Levrel
Jan 22 at 8:50
add a comment |
With zsh
5.6 or above (for the nanosecond precision), you could do it with builtins only with:
zmodload zsh/stat
if
stat -LA lnktime -F '%021s%N' +mtime -- $lnkfile &&
stat -A reftime -F '%021s%N' +mtime -- $reffile &&
[[ $lnktime < $reftime ]]
then
print -r -- $lnkfile is older than $reffile
fi
Which would work regardless of what characters or non-characters the file names contain and compare timestamps down to the nanosecond.
We're comparing the timestamps as strings (number of nanoseconds as a decimal string representation zero-padded to 30 digits) instead of floating points because the typical double precision floating points of a x86_64 PC running GNU/Linux at least don't have enough precision to store numbers like 1548195897.775033155
so you would not be able to tell apart two files modified today within the same 100 nanoseconds.
$ ((1548195897.775033155 < 1548195897.775033255)) && echo yes
$ [[ 1548195897775033155 < 1548195897775033255 ]] && echo yes
yes
Thank you for the details. Could you expand about "non-characters" please? I've tested with a filename containing newline: GNUstat
shows no problem.find
will replace the newline with?
if output goes to the terminal, otherwise it is preserved (which is the case in Sparhawk's answer, but anyway we're just testing if there's any output, so?
would be fine). All substitutions are double-quoted to avoid word splitting.
– L. Levrel
Jan 23 at 10:00
add a comment |
With zsh
5.6 or above (for the nanosecond precision), you could do it with builtins only with:
zmodload zsh/stat
if
stat -LA lnktime -F '%021s%N' +mtime -- $lnkfile &&
stat -A reftime -F '%021s%N' +mtime -- $reffile &&
[[ $lnktime < $reftime ]]
then
print -r -- $lnkfile is older than $reffile
fi
Which would work regardless of what characters or non-characters the file names contain and compare timestamps down to the nanosecond.
We're comparing the timestamps as strings (number of nanoseconds as a decimal string representation zero-padded to 30 digits) instead of floating points because the typical double precision floating points of a x86_64 PC running GNU/Linux at least don't have enough precision to store numbers like 1548195897.775033155
so you would not be able to tell apart two files modified today within the same 100 nanoseconds.
$ ((1548195897.775033155 < 1548195897.775033255)) && echo yes
$ [[ 1548195897775033155 < 1548195897775033255 ]] && echo yes
yes
Thank you for the details. Could you expand about "non-characters" please? I've tested with a filename containing newline: GNUstat
shows no problem.find
will replace the newline with?
if output goes to the terminal, otherwise it is preserved (which is the case in Sparhawk's answer, but anyway we're just testing if there's any output, so?
would be fine). All substitutions are double-quoted to avoid word splitting.
– L. Levrel
Jan 23 at 10:00
add a comment |
With zsh
5.6 or above (for the nanosecond precision), you could do it with builtins only with:
zmodload zsh/stat
if
stat -LA lnktime -F '%021s%N' +mtime -- $lnkfile &&
stat -A reftime -F '%021s%N' +mtime -- $reffile &&
[[ $lnktime < $reftime ]]
then
print -r -- $lnkfile is older than $reffile
fi
Which would work regardless of what characters or non-characters the file names contain and compare timestamps down to the nanosecond.
We're comparing the timestamps as strings (number of nanoseconds as a decimal string representation zero-padded to 30 digits) instead of floating points because the typical double precision floating points of a x86_64 PC running GNU/Linux at least don't have enough precision to store numbers like 1548195897.775033155
so you would not be able to tell apart two files modified today within the same 100 nanoseconds.
$ ((1548195897.775033155 < 1548195897.775033255)) && echo yes
$ [[ 1548195897775033155 < 1548195897775033255 ]] && echo yes
yes
With zsh
5.6 or above (for the nanosecond precision), you could do it with builtins only with:
zmodload zsh/stat
if
stat -LA lnktime -F '%021s%N' +mtime -- $lnkfile &&
stat -A reftime -F '%021s%N' +mtime -- $reffile &&
[[ $lnktime < $reftime ]]
then
print -r -- $lnkfile is older than $reffile
fi
Which would work regardless of what characters or non-characters the file names contain and compare timestamps down to the nanosecond.
We're comparing the timestamps as strings (number of nanoseconds as a decimal string representation zero-padded to 30 digits) instead of floating points because the typical double precision floating points of a x86_64 PC running GNU/Linux at least don't have enough precision to store numbers like 1548195897.775033155
so you would not be able to tell apart two files modified today within the same 100 nanoseconds.
$ ((1548195897.775033155 < 1548195897.775033255)) && echo yes
$ [[ 1548195897775033155 < 1548195897775033255 ]] && echo yes
yes
edited Jan 23 at 10:50
answered Jan 22 at 22:31
Stéphane ChazelasStéphane Chazelas
305k57574927
305k57574927
Thank you for the details. Could you expand about "non-characters" please? I've tested with a filename containing newline: GNUstat
shows no problem.find
will replace the newline with?
if output goes to the terminal, otherwise it is preserved (which is the case in Sparhawk's answer, but anyway we're just testing if there's any output, so?
would be fine). All substitutions are double-quoted to avoid word splitting.
– L. Levrel
Jan 23 at 10:00
add a comment |
Thank you for the details. Could you expand about "non-characters" please? I've tested with a filename containing newline: GNUstat
shows no problem.find
will replace the newline with?
if output goes to the terminal, otherwise it is preserved (which is the case in Sparhawk's answer, but anyway we're just testing if there's any output, so?
would be fine). All substitutions are double-quoted to avoid word splitting.
– L. Levrel
Jan 23 at 10:00
Thank you for the details. Could you expand about "non-characters" please? I've tested with a filename containing newline: GNU
stat
shows no problem. find
will replace the newline with ?
if output goes to the terminal, otherwise it is preserved (which is the case in Sparhawk's answer, but anyway we're just testing if there's any output, so ?
would be fine). All substitutions are double-quoted to avoid word splitting.– L. Levrel
Jan 23 at 10:00
Thank you for the details. Could you expand about "non-characters" please? I've tested with a filename containing newline: GNU
stat
shows no problem. find
will replace the newline with ?
if output goes to the terminal, otherwise it is preserved (which is the case in Sparhawk's answer, but anyway we're just testing if there's any output, so ?
would be fine). All substitutions are double-quoted to avoid word splitting.– L. Levrel
Jan 23 at 10:00
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f495864%2fcomparing-the-time-of-a-symlink%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown