Bring consistency to `which` about xonsh HOT 14 CLOSED

We don't need to do anything. But we've always tried to help users understand why a given command is doing what it is doing. To that end, returning nothing (or erroring) when you call which on an alias seems like a terrible pattern, since it is evident that by executing the command (the alias) that something is happening.

I am a strong -1 on copying bash behavior here because I find it to be terrible.

Option 1 would be fine, although it will take some work in the detypers to make sure things like $(which vim) myfile still work

from xonsh.

yeah, that's where you'd want the horrible @$ operator, so @$(which vim) world
(that's a different and longer discussion)

the more likely use case is if you want to cat out the contents of a script on your path, then you might do

cat $(which scriplet)

from xonsh.

There's GNU which, the bash built-in which, the zsh built-in which and BSD which -- these all have different behaviors and take different command line args.

So which inconsistency do we choose?

You say it's inconsistent because one is a path location and one is an alias.

I say yours is inconsistent because one returns a path location and one says "there is no callable called X"

There are likely infinite degrees of cardinality up on which we can choose to say "this consistency is important."

from xonsh.

@gforsyth may be you remember why we need to return aliases in which?

from xonsh.

to make sure things like $(which vim) myfile still work

Why it's needed instead of vim myfile?

from xonsh.

It's just a representative example of using the output of which in a capture to create another command

from xonsh.

As I see $(which vim) works like vim so I haven't catch a benefit.

from xonsh.

Ah, you mean that vim could be a variable? Looks like ugly case but yes it's possible.

from xonsh.

But in fact it's not working:

which vim 
# /usr/bin/vim

aliases['vim'] = 'echo vim'
which vim
# echo vim

vim = 1
vim
# 1

which vim
# echo vim

$(which vim) world
# xonsh: subprocess mode: command not found: 'echo vim\n' :)))
# EXPECTED: vim world

from xonsh.

I find which for aliases invaluable for commands that run a user-supplied command, e.g. watch @$(which ls)

from xonsh.

My logic is:

0. It's bad to have inconsistency by default.

1. The man which page tells us "which – locate a program file in the user's path" and it's expected by the people to have "location" as the output of which. Am I right?

2. The which command in xonsh is different (UPD: in zsh too) and can unintended return the text of alias. It's bad.

3. I see that there is -s, --skip-alias option in xonsh's which and this is fun because it should be exactly the opposite - the option -ia, --include-alias should be by default to avoid unintended inconsistency in output i.e. watch @$(which -ia ls).

@gforsyth it looks more sane, isn't it?

@Qyriad thanks for nice example! Meanwhile by default it breaks on ExecAlias e.g.:

aliases['ls'] = 'echo @("ls")'
watch @$(which ls)
# sh: -c: line 0: syntax error near unexpected token `('
# sh: -c: line 0: `echo @("ls")'

Basically it's ok but not as default behavior. See logic above.

from xonsh.

The current default is the correct way around.

My usual case for which is (eg, which cmd)
a) See what cmd is
b) I just ran cmd and it did not do what I expected.

Thus I want which cmd to tell me what cmd is and that includes aliases.

This is all consistent, which tells me what cmd is.

There is a bit more to this. Do xonsh aliases work in non-interactive scripts? If so then the logic is the same and bash logic here is definitely wrong.

from xonsh.

There are two perspective of view:

(1) Simple user wants to know what behind the command word. This is reasonable. But:

• which command has history and the appropriate meaning that cover man which (yeah, but not for zsh). If we want to uncover words let's implement distinct command what or let's use var?.
• If we want really uncover the word we need also to tell about local variables because if you do ls=1 and then run ls you will get 1 instead of alias or utility.

(2) Advanced user wants stable sanity. If advanced user has a script (e.g. xontrib) he wants to have it readable and sane:

• To use path to utility we don't need to implicitly push him to the unexpected error when alias text exists instead of path.
• Basically which are used about checking the utility exists. If someone put alias before which - this is also unexpected issue.

Yes, I see that zsh is ugly too:

# zsh
which which
# which: shell built-in command
alias ll=ls
which ll
# ll: aliased to ls
echo $?
# 0         # return code 0 for alias this is so ugly because there is no checking that `ls` exists
which ls
# /opt/homebrew/opt/coreutils/libexec/gnubin/ls

I hate this because of logic above.

So the bad patterns are:

• Implicit behavior that has no pointers in the code.
• Implicit behavior that could be changed unexpected before usage. The addition to probability of unexpected issues.
• To use something (i.e. which) the new user needs to do effort to completely understand how it works. The additional time cost.

I think the key thought are said and I'm going to close this.

from xonsh.

I wish I had not started looking at what I say below, I remembered which not being consistent from 25 years ago but not why. So down a rabbit hole.

which does have history, also look at type and command -V.
The history is a mess and shows which is not that stable. I could not find which on the POSIX page so not a formal definition.

I think some shells aliases which to type -P - but see later ...

There is also a version that lists all the places a program can be found on the path.
In zsh (and Windows cmd) this is where. In zsh this also lists aliases - zsh also has whence..

type -a seems similar to where (and fails to find xonsh aliases as is an external program)

Also see SO answer as to why which is also not reliable.
Note that this suggests that type -P does what anki suggests but the POSIX definition of type is minimal and Wikipedia says type is not part of POSIX.

So there is no good consistent definition of which or type, seems that command -V is defined but that finds aliases.

I do think zsh has it correct. But I am in the simple user category,

However I do agree that for script writers you do need more. So I would suggest writing a Python function with well defined behaviour.

from xonsh.