[Buildroot] [PATCH 1/1] Prefer 'command -v' over 'which' (for portability)
bjorn.forsman at gmail.com
Mon Jan 27 21:09:08 UTC 2014
On 27 January 2014 21:32, Thomas De Schampheleire
<patrickdepinguin at gmail.com> wrote:
> On Mon, Jan 27, 2014 at 9:01 PM, Bjørn Forsman <bjorn.forsman at gmail.com> wrote:
>> On 27 January 2014 10:19, Samuel Martin <s.martin49 at gmail.com> wrote:
>>> Bjørn, all,
>>> "command -v" seems not playing very well with aliases:
>>> $ command -v make
>>> alias make='~/.config/ctafconf/bin/colorwarper make'
>>> $ which make
>> Ah, correct.
>> There is "type -P" which is more like "which" in that regard, but the
>> "-P" option doesn't seem to be specified by POSIX. For example, "type
>> -P which" fails in dash.
>> Instead of an alias, you could write a one-liner shell wrapper? I tend
>> to prefer wrappers over aliases anyway, because of issues like these;
>> aliases sometimes behave differently than proper commands.
> Why I also think this is saner than aliases, we cannot dictate this
> principle to all buildroot users, so buildroot cannot rely on aliases
> not being used...
In the example above, "which" finds the /usr/bin/make binary and
ignores the alias. So what do you propose that Buildroot should
The way I see it we have three options:
1) Allow aliases but silently ignore them (current behaviour)
2) Allow aliases and handle them properly (requires some changes)
3) Disallow aliases (and suggest wrappers?)
If we apply this s/which/command -v/ patch I think we can still obtain
the current behaviour by just running "unalias" for each core
More information about the buildroot