Mailing List Archive

Should we join the which hunt?
Recently Debian has started to transition away from the "which" command.
[1]

which is a non-POSIX command which prints out the location of specified
executables that are in your path. Unfortunately, there are several
versions of the program around which are not compatible with each other.
We package the GNU version as sys-apps/which, which is in the system set
since 2004.

Already in 2007, vapier asked developers to avoid which in ebuilds. [2]
The replacement in most circumstances is "type -p" which is a bash
builtin command.

So, should we join the "which hunt", with the goal of removing
sys-apps/which from the system set and from stage1? I think the first
step would be to identify which packages use which, and add it as an
explicit dependency. (Maybe the tinderbox could help there?) A bug for
this [3] has already been filed by mgorny some time ago.

Unfortunately, the command pops up in unexpected places, e.g. it appears
to be an (indirect) build-time dependency of systemd. [4]

Ulrich

[1] https://lwn.net/Articles/874049/
[2] https://archives.gentoo.org/gentoo-dev/message/e04d4db72572dd5fec48e87c6b18c525
[3] https://bugs.gentoo.org/646588
[4] https://bugs.gentoo.org/502084
Re: Should we join the which hunt? [ In reply to ]
On Fri, 2022-05-13 at 09:11 +0200, Ulrich Mueller wrote:
>
> So, should we join the "which hunt", with the goal of removing
> sys-apps/which from the system set and from stage1?

Yes, although I would suggest "command -v" as a POSIX replacement that
can be sent upstream. The "type" utility is also standard, but the "-p"
flag is not, so "type -p" creates some pointless bashisms. Both are
built-in to bash so there's no performance penalty in ebuilds either
way.
Re: Should we join the which hunt? [ In reply to ]
220513 Ulrich Mueller wrote:
> Recently Debian has started to transition away from the "which" command.
> [1]

Do we take Debian as a role model ?

> 'which' is a non-POSIX command which prints out the location of specified
> executables that are in your path. Unfortunately, there are several
> versions of the program around which are not compatible with each other.
> We package the GNU version as sys-apps/which,
> which is in the system set since 2004.

If there is a GNU version, that would seem to be somewhat "official".
Also, it's been around a long time.

> Already in 2007, vapier asked developers to avoid which in ebuilds. [2]

There well mb good reasons for the devs to do that,
but users may have different needs or preferences.

> The replacement in most circumstances is "type -p"
> which is a bash builtin command.

It does appear to do the same job, but it's more difficult to remember.
Yes, anyone could make 'which' an alias for 'type -p'.

> So, should we join the "which hunt", with the goal
> of removing sys-apps/which from the system set and from stage1 ?
> The first step would be to identify which packages use 'which'
> and add it as an explicit dependency.
> Maybe the tinderbox could help there ?
> A bug for this [3] has already been filed by mgorny some time ago.
> Unfortunately, the command pops up in unexpected places,
> e.g. it appears to be an (indirect) build-time dependency of systemd. [4]
> [1] https://lwn.net/Articles/874049/
> [2] https://archives.gentoo.org/gentoo-dev/message/e04d4db72572dd5fec48e87c6b18c525
> [3] https://bugs.gentoo.org/646588
> [4] https://bugs.gentoo.org/502084

Those are a user's reactions. I trust the devs to do something sensible.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca
Re: Should we join the which hunt? [ In reply to ]
>>>>> On Fri, 13 May 2022, Michael Orlitzky wrote:

>> So, should we join the "which hunt", with the goal of removing
>> sys-apps/which from the system set and from stage1?

> Yes, although I would suggest "command -v" as a POSIX replacement that
> can be sent upstream. The "type" utility is also standard, but the "-p"
> flag is not, so "type -p" creates some pointless bashisms.

This depends on context. I think with bash "type -p" is the better
choice, because it simply prints the path which is machine readable
without any postprocessing.

In other posixly-correct contexts "command -v" may be the best
alternative available, indeed.

> Both are built-in to bash so there's no performance penalty in ebuilds
> either way.
Re: Should we join the which hunt? [ In reply to ]
On 13/05/2022 09.11, Ulrich Mueller wrote:
> So, should we join the "which hunt", with the goal of removing
> sys-apps/which from the system set and from stage1?

Yes, please. If there is a equally powerful bash builtin, and even a
POSIX shell function, that performs the same task as the external
command, than the shell builtins should be used.

Since ebuilds are bash, it seems safe to use "type -p" in them.

Would it be possible to add a QA check to portage that detects invalid
usages of 'which' and flags them to be replaced with "type -p"? I think
that would be a good first step.

- Flow
Re: Should we join the which hunt? [ In reply to ]
On Fri, May 13, 2022 at 05:02:25AM -0400, Michael Orlitzky wrote:
> On Fri, 2022-05-13 at 09:11 +0200, Ulrich Mueller wrote:
> >
> > So, should we join the "which hunt", with the goal of removing
> > sys-apps/which from the system set and from stage1?
>
> Yes, although I would suggest "command -v" as a POSIX replacement that
> can be sent upstream. The "type" utility is also standard, but the "-p"
> flag is not, so "type -p" creates some pointless bashisms. Both are
> built-in to bash so there's no performance penalty in ebuilds either
> way.

fwiw both command -v and type -p aren't analogous to which given they
check shell functions too, requiring to pay attention to namespace.

e.g. if have /bin/ftest and ftest() { :; }, with bash:
which ftest: /bin/ftest
command -v ftest: ftest
type -p ftest: (nothing)
type -P ftest: /bin/ftest

If the function is unset they all return /bin/ftest though. In bash
/ ebuilds I don't see much reason to use command -v, but if swapping
which for command -v with POSIX sh should check if the script doesn't
have simple function names everywhere.

--
ionen
Re: Should we join the which hunt? [ In reply to ]
>>>>> On Fri, 13 May 2022, Philip Webb wrote:

>> Recently Debian has started to transition away from the "which" command.
>> [1]

> Do we take Debian as a role model ?

No, but it is additional input. Note that our own activities [2,3]
started earlier than that.

>> 'which' is a non-POSIX command which prints out the location of specified
>> executables that are in your path. Unfortunately, there are several
>> versions of the program around which are not compatible with each other.
>> We package the GNU version as sys-apps/which,
>> which is in the system set since 2004.

> If there is a GNU version, that would seem to be somewhat "official".
> Also, it's been around a long time.

It's been around at least since the 1980s but in spite of this it was
never standardised. The GNU version exists since 1999 and had its last
release in 2015.

>> Already in 2007, vapier asked developers to avoid which in ebuilds. [2]

> There well mb good reasons for the devs to do that,
> but users may have different needs or preferences.

Nobody is asking to drop the sys-apps/which package, so users can
install it if they like the command. Gentoo is about choice, so we
shouldn't force installation for everybody if the package isn't needed
in @system. (The same applies to sys-apps/less BTW, but that's a
different story.)

Ulrich

>> [1] https://lwn.net/Articles/874049/
>> [2] https://archives.gentoo.org/gentoo-dev/message/e04d4db72572dd5fec48e87c6b18c525
>> [3] https://bugs.gentoo.org/646588
>> [4] https://bugs.gentoo.org/502084
Re: Should we join the which hunt? [ In reply to ]
On Fri, May 13, 2022 at 3:11 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> Recently Debian has started to transition away from the "which" command.
> [1]
>
> which is a non-POSIX command which prints out the location of specified
> executables that are in your path. Unfortunately, there are several
> versions of the program around which are not compatible with each other.
> We package the GNU version as sys-apps/which, which is in the system set
> since 2004.
>
> Already in 2007, vapier asked developers to avoid which in ebuilds. [2]
> The replacement in most circumstances is "type -p" which is a bash
> builtin command.
>
> So, should we join the "which hunt", with the goal of removing
> sys-apps/which from the system set and from stage1? I think the first
> step would be to identify which packages use which, and add it as an
> explicit dependency. (Maybe the tinderbox could help there?) A bug for
> this [3] has already been filed by mgorny some time ago.
>
> Unfortunately, the command pops up in unexpected places, e.g. it appears
> to be an (indirect) build-time dependency of systemd. [4]

"which" is a built-in command in bash, but not in dash. For most
users, /bin/sh points at bash and I don't expect to see much breakage
when /usr/bin/which is removed. The bug reports will come from people
who like pain and run their systems with /bin/sh pointed at dash.
Re: Should we join the which hunt? [ In reply to ]
On Fri, May 13, 2022 at 11:44 AM Mike Gilbert <floppym@gentoo.org> wrote:
>
> On Fri, May 13, 2022 at 3:11 AM Ulrich Mueller <ulm@gentoo.org> wrote:
> >
> > Recently Debian has started to transition away from the "which" command.
> > [1]
> >
> > which is a non-POSIX command which prints out the location of specified
> > executables that are in your path. Unfortunately, there are several
> > versions of the program around which are not compatible with each other.
> > We package the GNU version as sys-apps/which, which is in the system set
> > since 2004.
> >
> > Already in 2007, vapier asked developers to avoid which in ebuilds. [2]
> > The replacement in most circumstances is "type -p" which is a bash
> > builtin command.
> >
> > So, should we join the "which hunt", with the goal of removing
> > sys-apps/which from the system set and from stage1? I think the first
> > step would be to identify which packages use which, and add it as an
> > explicit dependency. (Maybe the tinderbox could help there?) A bug for
> > this [3] has already been filed by mgorny some time ago.
> >
> > Unfortunately, the command pops up in unexpected places, e.g. it appears
> > to be an (indirect) build-time dependency of systemd. [4]
>
> "which" is a built-in command in bash, but not in dash. For most
> users, /bin/sh points at bash and I don't expect to see much breakage
> when /usr/bin/which is removed. The bug reports will come from people
> who like pain and run their systems with /bin/sh pointed at dash.

Oops, turns out I tested with zsh, not bash. Disregard the above.
Re: Should we join the which hunt? [ In reply to ]
On Fri, 2022-05-13 at 11:44 -0400, Mike Gilbert wrote:
>
> "which" is a built-in command in bash, but not in dash. For most
> users, /bin/sh points at bash and I don't expect to see much breakage
> when /usr/bin/which is removed. The bug reports will come from people
> who like pain and run their systems with /bin/sh pointed at dash.
>

Debian did that first, too. If your oldest and most boring friend jumps
off a bridge, it's fine. And it makes each ./configure run like 15%
faster!

Who is Gentoo for if not for people who would sacrifice essential
stability for a little temporary performance, and deserve neither?
Re: Should we join the which hunt? [ In reply to ]
On Fri, 13 May 2022 09:11:30 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> Recently Debian has started to transition away from the "which"
> command. [1]
>
> which is a non-POSIX command which prints out the location of
> specified executables that are in your path. Unfortunately, there are
> several versions of the program around which are not compatible with
> each other. We package the GNU version as sys-apps/which, which is in
> the system set since 2004.
>
> Already in 2007, vapier asked developers to avoid which in ebuilds.
> [2] The replacement in most circumstances is "type -p" which is a bash
> builtin command.
>
> So, should we join the "which hunt", with the goal of removing
> sys-apps/which from the system set and from stage1? I think the first
> step would be to identify which packages use which, and add it as an
> explicit dependency. (Maybe the tinderbox could help there?) A bug for
> this [3] has already been filed by mgorny some time ago.
>
> Unfortunately, the command pops up in unexpected places, e.g. it
> appears to be an (indirect) build-time dependency of systemd. [4]
>
> Ulrich
>
> [1] https://lwn.net/Articles/874049/
> [2]
> https://archives.gentoo.org/gentoo-dev/message/e04d4db72572dd5fec48e87c6b18c525
> [3] https://bugs.gentoo.org/646588 [4] https://bugs.gentoo.org/502084

To solve this exact issue I wrote a pure shell script to find
executable files in the user's $PATH. It should work with posix
compatible shell and about as fast as which(1).

https://notabug.org/orbea/exists/src/master/exists.sh

There are a lot of tests as well.

https://notabug.org/orbea/exists/src/master/test.sh