Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14814 > unrolled thread
| Started by | Eric Blake <eblake@redhat.com> |
|---|---|
| First post | 2018-11-13 11:54 -0600 |
| Last post | 2018-11-13 11:54 -0600 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: built-in '[' and '/usr/bin/[' yield different results Eric Blake <eblake@redhat.com> - 2018-11-13 11:54 -0600
| From | Eric Blake <eblake@redhat.com> |
|---|---|
| Date | 2018-11-13 11:54 -0600 |
| Subject | Re: built-in '[' and '/usr/bin/[' yield different results |
| Message-ID | <mailman.3986.1542131701.1284.bug-bash@gnu.org> |
On 11/13/18 10:29 AM, Service wrote: > # ensure that file1 exists and that file2 does not exist There's your problem. It is inherently ambiguous what timestamp to use when a file is missing (infinitely new or infinitely old, or always an error for not existing); bash's -nt picked one way, while other shells have picked the other. POSIX is silent on the matter (-nt is an extension outside of POSIX), so there is nothing portable you can rely on. > /bin/touch file1 > /bin/rm -f file2 > # built-in > if [ file1 -nt file2 ]; then echo nt; else echo not_nt; fi > # external > if /usr/bin/[ file1 -nt file2 ]; then echo nt; else echo not_nt; fi > > # Output is as expected: > nt > nt That is, bash's builtin '[' and coreutil's external '[' happened to pick the same thing: a missing file is treated as infinitely old. > > 2. This does not work: > > # Put the above commands into a script, say check.sh > # Run with: /bin/sh < check.sh > # Or : /bin/sh ./check.sh > # Or : /usr/bin/env ./check.sh > > # Output is always not ok: > not_nt > nt Most likely, this is because your /bin/sh is not bash, but probably dash, and dash has picked a missing file as being treated as always an error. That does not make it a bug in bash, though, but a difference in behavior of your /bin/sh. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Back to top | Article view | gnu.bash.bug
csiph-web