| 1 |
On Fri, May 13, 2022 at 05:02:25AM -0400, Michael Orlitzky wrote: |
| 2 |
> On Fri, 2022-05-13 at 09:11 +0200, Ulrich Mueller wrote: |
| 3 |
> > |
| 4 |
> > So, should we join the "which hunt", with the goal of removing |
| 5 |
> > sys-apps/which from the system set and from stage1? |
| 6 |
> |
| 7 |
> Yes, although I would suggest "command -v" as a POSIX replacement that |
| 8 |
> can be sent upstream. The "type" utility is also standard, but the "-p" |
| 9 |
> flag is not, so "type -p" creates some pointless bashisms. Both are |
| 10 |
> built-in to bash so there's no performance penalty in ebuilds either |
| 11 |
> way. |
| 12 |
|
| 13 |
fwiw both command -v and type -p aren't analogous to which given they |
| 14 |
check shell functions too, requiring to pay attention to namespace. |
| 15 |
|
| 16 |
e.g. if have /bin/ftest and ftest() { :; }, with bash: |
| 17 |
which ftest: /bin/ftest |
| 18 |
command -v ftest: ftest |
| 19 |
type -p ftest: (nothing) |
| 20 |
type -P ftest: /bin/ftest |
| 21 |
|
| 22 |
If the function is unset they all return /bin/ftest though. In bash |
| 23 |
/ ebuilds I don't see much reason to use command -v, but if swapping |
| 24 |
which for command -v with POSIX sh should check if the script doesn't |
| 25 |
have simple function names everywhere. |
| 26 |
|
| 27 |
-- |
| 28 |
ionen |
Archives