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

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmJ+BKIPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4udKMH/A44BDkS2oHhtorPNesjTiBSB26LJ5+bR/8y Bb2NooQOlnH+tzWypWYySQ0w4jROlZ4TA4v7U07a9WhJJ19Pl58oh8Q3DSZDeP5P KBLXAhpxgBi4ON6jkxXzm7WQBcKyaAUmeKbeJkoMNKkA9Rfr7nDwtvnQLXi5rm97 rlfVFpP4HkDnFbCbe3ZStjjIsih1w90D8eaFnQvQ+8DiHJm7bCtT4LtzF8zrASil bzv+yVFLleXazUjTa6u5gNNR3/hAwphK3xhWU7La6iveXRaXDwpoibZeJknDjzIv WWbiDAdqabPG4b4tScaqCXSNx3XtPXgVtff+HP8R09ikLBSwpzY=
=9olX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmJ+LVIPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4uzC8H/35EAsYi9zWQxWtC3Ya10ktToqBjqWRtsnFM 6YtzhY3reinH38sDWuorJfrRIkd5ecjLxszksoydBNY8tkxRKdP6oCFLVuirndvD ciwW/DJxa0WVYkTPnw/UTDpG+ciqkXFN5TU4RZQy9Do4UAm3NR7h2Fxmfwjl089U N6xiaCMCniQGTLsR9x1doLFNZDgcV0SOnuLAD74waIVg9kNTg+zit2oSTGzKFJPO TfgbrWxwz54z0NK1SkkdTe4j1ye3brG664+OPlyY47URvMf+ddr0iaWaMTzMBVqV qLxld6czNEOFppN33Z+dBFFARmvS3z46LWKuFEZgaLQ0d0/kC6g=
=D0g8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmJ+MpEPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4uKUwH/Row2sbZFCkYuyj6w4RBxf3iNc32KOUgpmO+ 4xNbi/UIw1/oAevUvX074FfOm0iqR4UQ69VJCQ3fcW7G0HbKkep2ake9zXYlNrIM 4Lc03odrWHcCno1rtBDNU5N56NDE65x6HqXGz6qryH+sj2hxZi/qWTTRQ6/idGcu 2Vd9A3Yrx0epYFjl5B6vPjBa2z5CFfYYGZPkkv36Rz4NERWUIR3DN4DamjRvzeDv cbskyfgLsffjoLhRPlXSHgYHsAogH8xWfGyDEVq/wr/a/f6Bj3d+4XmXRCq/pNJh wJRBEiKBuHz4wSqAZ08uxk7rV29Nyi5BbaK8L8G9lK3nq8iN94g=
=56AC
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmJ+MSwACgkQskQGsLCs QzS+cwf+MVNrM6KDycyNFEqSvg2Eq0wt713zYdGvN4EzOvXIktD2/i9wieem0Rtt LTFV8Hbw4IPIBffUNHJfD5TQSs1+s1SPuTlipbQxWDN+4bhV3Vx05J5mMoZY3rtp 6OlD4/CL0P3AiMMZLpNIr4VNYJJC+CwK22KAP7skPd8CNOalk5Br7YJpwOQ8muMp BSqWcqvnw4TGvlLGQq49ZC75hPaDBRyPeeGjmrJIjlyIryxNMz17PwajepzWoet9 YO7PdY077dQi97EeZIGHlC9cf6eg1mflIKHZxIiPxKHr1lP+MpWpmJvX8uCe9hNl Sky2aXXNN7X1c1Nm/2U00DyRDpKhrA==
=nX/3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)