Re: Bug in [ -d ... ] ?

2017-11-02 Thread Robert Elz
Date:Thu, 2 Nov 2017 16:54:48 + From:Michael F Gordon Message-ID: <20171102165448.ga18...@ee.ed.ac.uk> | Also, replacing := with :- gives "no" on both versions when unquoted | or unquoted. That's because they're doing different things, the := form assigns ""

Re: New MILLISECONDS “special” variable?

2017-11-02 Thread Chet Ramey
On 11/2/17 4:09 PM, DJ Mills wrote: > > > On Thu, Nov 2, 2017 at 3:35 PM, Chet Ramey > wrote: > > There is a special builtin in the devel branch version (EPOCHREALTIME) > that > gives you the epoch time with microsecond resolution. It will be in the > ne

Re: New MILLISECONDS “special” variable?

2017-11-02 Thread DJ Mills
On Thu, Nov 2, 2017 at 3:35 PM, Chet Ramey wrote: > > There is a special builtin in the devel branch version (EPOCHREALTIME) that > gives you the epoch time with microsecond resolution. It will be in the > next release. > > Out of curiosity, is that functionality going to extend to printf '%(fmt)T

Re: New MILLISECONDS “special” variable?

2017-11-02 Thread Chet Ramey
On 11/1/17 4:19 PM, Alan Dipert wrote: > Hello all, > > I understand there is a “special” variable, SECONDS, which returns the > number of seconds since bash invocation when referenced. > > Unfortunately for tasks like profiling one’s .profile, SECONDS is too > coarse a unit. Milliseconds are mor

Re: Bug in [ -d ... ] ?

2017-11-02 Thread Chet Ramey
On 11/2/17 12:54 PM, Michael F Gordon wrote: > > Interesting. This is the way "[" has always been documented to work, but > something has changed in newer versions of the shell I answered this. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vit

Re: New MILLISECONDS “special” variable?

2017-11-02 Thread Eduardo Bustamante
El mié., nov. 1, 2017 8:48 PM, Eduardo A. Bustamante López < dual...@gmail.com> escribió: > [...] > /* FIXME: do better validation */ > static int parse_timeval (const char *s, struct timeval *tv) { > char *ds; > timerclear(tv); > tv->tv_sec = strtol(s, &ds, 10); > if (ds && *ds == '.') {

Re: Bug in [ -d ... ] ?

2017-11-02 Thread Michael F Gordon
On Thu, Nov 02, 2017 at 09:47:24AM -0400, Greg Wooledge wrote: > Quoting failure. > > wooledg:~$ unset FOO > wooledg:~$ if [ -d "${FOO:=""}" ]; then echo yes; else echo no; fi > no > > With quotes the command is transformed to > > [ -d "" ] > > Without quotes it becomes > > [ -d ] > > A singl

Re: Bug in [ -d ... ] ?

2017-11-02 Thread Chet Ramey
On 11/2/17 7:03 AM, Michael F Gordon wrote: > Can anyone explain the following? > > tla19> set|grep FOOFOOFOO > tla19> if [ -d ${FOOFOOFOO:=""} ]; then echo YES;fi > YES > tla19> echo $BASH_VERSION > 4.4.12(1)-release Greg is correct. This expands to [ -d ], which is true. There was an expansio

Re: Bug in [ -d ... ] ?

2017-11-02 Thread Eric Blake
On 11/02/2017 06:03 AM, Michael F Gordon wrote: > Can anyone explain the following? Yes. You used incorrect quoting. > > tla19> set|grep FOOFOOFOO > tla19> if [ -d ${FOOFOOFOO:=""} ]; then echo YES;fi > YES Because you forgot to quote the variable expansion, you ended up executing: if [ -d ];

Re: Bug in [ -d ... ] ?

2017-11-02 Thread Greg Wooledge
On Thu, Nov 02, 2017 at 11:03:27AM +, Michael F Gordon wrote: > Can anyone explain the following? > > tla19> set|grep FOOFOOFOO > tla19> if [ -d ${FOOFOOFOO:=""} ]; then echo YES;fi > YES Quoting failure. wooledg:~$ unset FOO wooledg:~$ if [ -d "${FOO:=""}" ]; then echo yes; else echo no; fi

Bug in [ -d ... ] ?

2017-11-02 Thread Michael F Gordon
Can anyone explain the following? tla19> set|grep FOOFOOFOO tla19> if [ -d ${FOOFOOFOO:=""} ]; then echo YES;fi YES tla19> echo $BASH_VERSION 4.4.12(1)-release I don't get YES printed with 4.1.2(1)-release on Scientific Linux 6. I do with 4.2.46(1)-release on Scientific Linux 7 and it happens wi