Re: [gentoo-dev] Should we join the which hunt?
On Fri, 13 May 2022 09:11:30 +0200 Ulrich Mueller 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
Re: [gentoo-dev] Should we join the which hunt?
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: [gentoo-dev] Should we join the which hunt?
On Fri, May 13, 2022 at 11:44 AM Mike Gilbert wrote: > > On Fri, May 13, 2022 at 3:11 AM Ulrich Mueller 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: [gentoo-dev] Should we join the which hunt?
On Fri, May 13, 2022 at 3:11 AM Ulrich Mueller 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: [gentoo-dev] Should we join the which hunt?
> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Should we join the which hunt?
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 signature.asc Description: PGP signature
Re: [gentoo-dev] Should we join the which hunt?
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: [gentoo-dev] Should we join the which hunt?
> 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. signature.asc Description: PGP signature
Re: [gentoo-dev] Should we join the which hunt?
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: [gentoo-dev] Should we join the which hunt?
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.
[gentoo-dev] 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 signature.asc Description: PGP signature