Re: [gentoo-dev] Should we join the which hunt?

2022-05-14 Thread orbea
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

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Michael Orlitzky
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

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Mike Gilbert
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

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Mike Gilbert
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

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Ulrich Mueller
> 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

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Ionen Wolkens
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

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Florian Schmaus
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

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Ulrich Mueller
> 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

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Philip Webb
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 >

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Michael Orlitzky
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

[gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Ulrich Mueller
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