POSIX defines struct timeval in
I've discovered a gap in POSIX compliance in lib/sh/strftime.c on the devel branch. POSIX mandates that the timeval struct be defined in , although as can be seen on Line 67 of the file in question, the file is only included here if the tm struct -- which POSIX mandates be defined in -- is defined in . The libc implementation I'm working with defines timeval in and tm in as mandated by POSIX so here I encounter a compile failure on Line 193. ../../../bash-5.1/lib/sh/strftime.c: In function ‘strftime’: ../../../bash-5.1/lib/sh/strftime.c:193:17: error: storage size of ‘tv’ isn’t known struct timeval tv; ^~ Please correct me if I'm wrong as I may have missed something in the POSIX spec that results in the definition of timeval being available from another header, although I believe that the fix for this should be to move the include on Line 69 outside the enclosing #if guard, as it should always be required for POSIX compliance.
Re: ?maybe? RFE?... read -h ?
L A Walsh writes: > I know how -h can detect a symlink, but I was wondering, is > there a way for bash to know where the symlink points (without > using an external program)? My understanding is that it has been convention to use the "readlink" program for a very long time, so there's never been much demand to add it to bash. Of course, looking at the options to readlink shows that there are several different meanings of "where a symlink points". Dale
Re: ?maybe? RFE?... read -h ?
On Sun, Sep 5, 2021, at 11:11 PM, Dale R. Worley wrote: > L A Walsh writes: > > I know how -h can detect a symlink, but I was wondering, is > > there a way for bash to know where the symlink points (without > > using an external program)? > > My understanding is that it has been convention to use the "readlink" > program for a very long time, so there's never been much demand to add > it to bash. Of course, looking at the options to readlink shows that > there are several different meanings of "where a symlink points". The distribution ships with a "realpath" loadable builtin, FWIW. bash-5.1$ enable -f /opt/local/lib/bash/realpath realpath bash-5.1$ type realpath realpath is a shell builtin bash-5.1$ readlink /usr/bin/cc clang bash-5.1$ realpath /usr/bin/cc /usr/bin/clang -- vq
Re: ?maybe? RFE?... read -h ?
On Sun, Sep 05, 2021 at 11:54:05PM -0400, Lawrence Velázquez wrote: > On Sun, Sep 5, 2021, at 11:11 PM, Dale R. Worley wrote: > > > ... I was wondering, is there a way for bash to know where the > > > symlink points (without using an external program)? > > The distribution ships with a "realpath" loadable builtin, FWIW. > bash-5.1$ enable -f /opt/local/lib/bash/realpath realpath > bash-5.1$ realpath /usr/bin/cc > /usr/bin/clang I think this answer the need, but using this to populate a variable implie anyway a fork. realPathArray=$(realpath /bin/sh /usr/bin/X) It would be nice if builtins intended to produce *answer* use more or less common switch like `printf -v` behaviour. usage: realpath [-a array] [-csv] pathname [pathname...] options: -a NAME assign the output to shell array NAME rather than display it on the standard output -c check whether or not each resolved path exists -s no output, exit status determines whether path is valid -v produce verbose output -- Félix Hauri -- http://www.f-hauri.ch
Re: ?maybe? RFE?... read -h ?
i totally agree with any make subshells obsolete ( for cpu speed ) plans On Mon, Sep 6, 2021, 08:36 felix wrote: > On Sun, Sep 05, 2021 at 11:54:05PM -0400, Lawrence Velázquez wrote: > > On Sun, Sep 5, 2021, at 11:11 PM, Dale R. Worley wrote: > > > > > ... I was wondering, is there a way for bash to know where the > > > > symlink points (without using an external program)? > > > > The distribution ships with a "realpath" loadable builtin, FWIW. > > bash-5.1$ enable -f /opt/local/lib/bash/realpath realpath > > bash-5.1$ realpath /usr/bin/cc > > /usr/bin/clang > > I think this answer the need, but using this to populate a variable implie > anyway a fork. > > realPathArray=$(realpath /bin/sh /usr/bin/X) > > It would be nice if builtins intended to produce *answer* use more or less > common switch like `printf -v` behaviour. > > usage: realpath [-a array] [-csv] pathname [pathname...] > > options: -a NAME assign the output to shell array NAME rather than >display it on the standard output >-c check whether or not each resolved path exists >-s no output, exit status determines whether path is > valid >-v produce verbose output > > > > -- > Félix Hauri -- http://www.f-hauri.ch > >
Re: ?maybe? RFE?... read -h ?
btw in the help you pasted there is the -a arr in question On Mon, Sep 6, 2021, 08:36 felix wrote: > On Sun, Sep 05, 2021 at 11:54:05PM -0400, Lawrence Velázquez wrote: > > On Sun, Sep 5, 2021, at 11:11 PM, Dale R. Worley wrote: > > > > > ... I was wondering, is there a way for bash to know where the > > > > symlink points (without using an external program)? > > > > The distribution ships with a "realpath" loadable builtin, FWIW. > > bash-5.1$ enable -f /opt/local/lib/bash/realpath realpath > > bash-5.1$ realpath /usr/bin/cc > > /usr/bin/clang > > I think this answer the need, but using this to populate a variable implie > anyway a fork. > > realPathArray=$(realpath /bin/sh /usr/bin/X) > > It would be nice if builtins intended to produce *answer* use more or less > common switch like `printf -v` behaviour. > > usage: realpath [-a array] [-csv] pathname [pathname...] > > options: -a NAME assign the output to shell array NAME rather than >display it on the standard output >-c check whether or not each resolved path exists >-s no output, exit status determines whether path is > valid >-v produce verbose output > > > > -- > Félix Hauri -- http://www.f-hauri.ch > >
