1

I was playing around with the command date to create timestamps and profile the execution of a script. I decided to set four of them, named t1 through t4. For t2 I created an empty file whose last modification time I could use at a later stage to retrieve the stamp.

As a test I launched the following line:

t1=$(date +%s.%N) && t2=$(date +%s.%N) && touch t3 && t4=$(date +%s.%N)

When reading the values stored in the variables/files with

echo $t1 ; echo $t2 ; date -r t3 +%s.%N ; echo $t4

I obtain

1552985555.199182223
1552985555.200921201  # t2
1552985555.199194549  # t3
1552985555.204244831

There I was surprised to see that t3<t2, that is the file t3 appears to have been created before the variable t2 that has been defined earlier.

This behaviour is reproducible (I make sure to remove the file t3 before each repetition). Once in a while. though, I get the expected time order:

1552985629.214695802
1552985629.216438952  # t2
1552985629.295196920  # t3
1552985629.300037794

Both date and touch are from GNU coreutils 8.12. For the rest: Ubuntu 14.04 LTS, GNU bash 4.3, filesystem ext4.

Would someone please double-check this evidence, point to oversights and suggest solutions? In the end the aim is to monitor the development of a script in a consistent and correct way

Addition: for example these are 20 repetitions launched 1 second apart: the same output is in one line, so please look at the second and third column

1552986458.449690567 1552986458.451507586 1552986458.451223453 1552986458.454980321
1552986459.462222634 1552986459.464054243 1552986459.463223485 1552986459.467449036
1552986460.474568039 1552986460.476331886 1552986460.475223518 1552986460.479723115
1552986461.486642776 1552986461.488337967 1552986461.487223550 1552986461.491586674
1552986462.498636420 1552986462.500441307 1552986462.499223582 1552986462.503847530
1552986463.510775519 1552986463.512552869 1552986463.511223615 1552986463.515951772
1552986464.522958303 1552986464.524715464 1552986464.523223647 1552986464.528149986
1552986465.535135630 1552986465.536956933 1552986465.535223679 1552986465.540370390
1552986466.547042343 1552986466.548551235 1552986466.547223712 1552986466.551542698
1552986467.558193986 1552986467.560011358 1552986467.559223744 1552986467.563421722
1552986468.570405064 1552986468.572197220 1552986468.571223777 1552986468.575637535
1552986469.582805473 1552986469.584617345 1552986469.583223809 1552986469.588061790
1552986470.595186569 1552986470.596950654 1552986470.595223841 1552986470.600317667
1552986471.607334711 1552986471.609094157 1552986471.607223874 1552986471.612469522
1552986472.619539297 1552986472.621338541 1552986472.619223906 1552986472.624619165
1552986473.631362828 1552986473.633185880 1552986473.631223939 1552986473.636591552
1552986474.643786598 1552986474.645547837 1552986474.643223971 1552986474.648885524
1552986475.656067174 1552986475.657817777 1552986475.659224003 1552986475.661214859
1552986476.668232234 1552986476.670022104 1552986476.671224036 1552986476.673411532

created with

while :; do 
  rm -f t3
  t1=$(date +%s.%N) && t2=$(date +%s.%N) && touch t3 && t4=$(date +%s.%N)
  echo $t1 $t2 $(date -r t3 +%s.%N) $t4
  sleep 1
done
XavierStuvw
  • 1,119
  • I'm not able to reproduce it even once on coreutils 8.22, but why do you want to use && in the first case, when you can just separate the commands distinctly with ; – Inian Mar 19 '19 at 09:05
  • @Inian I have added the report of 20 simulations to the post; I first noted the issue starting with ; and chosen && to enforce a stricter order of execution at least psychologically. The command separator is not important. – XavierStuvw Mar 19 '19 at 09:16
  • @StéphaneChazelas Indeed very relevant, hence upvoted: this other post explains a bit more https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond – XavierStuvw Mar 19 '19 at 09:29

0 Answers0