On 2017-10-11, Pieter Kockx wrote:
> I used fstatat(AT_FDCWD, ...) instead of stat to deal with the case of
> relative paths.
> I generalized the error message to "external command":
> "external" to differentiate from builtin shell commands
> "command" since which essentially tries to mimic a typi
Alex Pilon wrote:
> > > On 2017-10-10-17, Evan Gates wrote:
> > >> I dislike that which(1) is even part of sbase as it's not POSIX. The
> > > > sh builtin 'command' can and should be used in its place as it is
> > > > standardized.
> > >
> > On 10/12/17, Michael Forney wrote:
> > > I'm fine rem
Michael Forney wrote:
> On 2017-10-10-17, Evan Gates wrote:
> > I dislike that which(1) is even part of sbase as it's not POSIX. The
> > sh builtin 'command' can and should be used in its place as it is
> > standardized.
>
> I'm fine removing it assuming there isn't a huge amount of scripts out
Surprisingly, the GNU coreutils don't include which, but Busybox does
(under the heading 'debianutils').
If we remove it, I'd add an FAQ referring to 'command -v' though.
On Thu, 12 Oct 2017 at 18:07 Alex Pilon wrote:
> > > On 2017-10-10-17, Evan Gates wrote:
> > >> I dislike that which(1) is
> > On 2017-10-10-17, Evan Gates wrote:
> >> I dislike that which(1) is even part of sbase as it's not POSIX. The
> > > sh builtin 'command' can and should be used in its place as it is
> > > standardized.
> >
> On 10/12/17, Michael Forney wrote:
> > I'm fine removing it assuming there isn't a hu
On 10/12/17, Michael Forney wrote:
> On 2017-10-10-17, Evan Gates wrote:
>> I dislike that which(1) is even part of sbase as it's not POSIX. The
>> sh builtin 'command' can and should be used in its place as it is
>> standardized.
>
> I'm fine removing it assuming there isn't a huge amount of scr
On 2017-10-10-17, Evan Gates wrote:
> I dislike that which(1) is even part of sbase as it's not POSIX. The
> sh builtin 'command' can and should be used in its place as it is
> standardized.
I'm fine removing it assuming there isn't a huge amount of scripts out
there that depend on it.
@Evan
I agree, 'which' does nothing the shell can't do better.
The utility is not standardized and implementations vary accordingly:
https://man.openbsd.org/which.1
https://linux.die.net/man/1/which
https://git.busybox.net/busybox/tree/debianutils/which.c
@Michael
If removing the utility is not an
On 10/10/17, Pieter Kockx wrote:
> Hello hackers
>
> $ which /usr/bin/env
> /usr/bin//usr/bin/env
>
> which should probably be idempotent when applied to its own output as
> in which $(which $(which env)).
>
> The underlying reason is that fstatat ignores dirfd if the the given
> filename is an ab
I dislike that which(1) is even part of sbase as it's not POSIX. The
sh builtin 'command' can and should be used in its place as it is
standardized.
That being said you are correct, that output is terrible and a patch
would be appreciated.
On Tue, Oct 10, 2017 at 3:56 PM Pieter Kockx wrote:
>
>
Hello hackers
$ which /usr/bin/env
/usr/bin//usr/bin/env
which should probably be idempotent when applied to its own output as
in which $(which $(which env)).
The underlying reason is that fstatat ignores dirfd if the the given
filename is an absolute path.
The following fix is possible:
if ((d
11 matches
Mail list logo
