[Taywee]

Unless you're using a shell that subverts that by providing its own built-in, like Zsh, which is allowed because there is no standard for `which`, and depending on its behavior can be problematic and inherently non-portable.

That description is also doesn't correctly describe the behavior of the command if the shell has any aliases or built-ins of that name. If you have an alias that points to a different command, then `which` is distinctly not printing the executable that would have been executed.

[pxc]

> That description is also doesn't correctly describe the behavior of the command if the shell has any aliases or built-ins of that name. If you have an alias that points to a different command, then `which` is distinctly not printing the executable that would have been executed.

I have some bad news.

    % command -v which
    Unknown option: v
    _______
    < which >
    -------
            \   ^__^
             \  (oo)\_______
                (__)\       )\/\
                    ||----w |
                    ||     ||
    % alias
    command=cowsay
    run-help=man
    which-command=whence
    %

Interestingly, at least one shell will not let you do this, but it's not entirely POSIX compliant anyway:

    [I] ⋊> ~ echo $FISH_VERSION
    3.3.1
    [I] ⋊> ~ alias command cowsay
    - (line 1): function: The name 'command' is reserved, and cannot be used as a function name
    function command --wraps cowsay --description 'alias command cowsay';  cowsay $argv; end
    ^
    from sourcing file -
            called on line 70 of file /nix/store/gwc21f4ra55h0x0b8xbwnpjlc6223z3q-fish-3.3.1/share/fish/functions/alias.fish
    in function 'alias' with arguments 'command cowsay'

It's also probably worth noting at this point that portability isn't the same kind of issue for interactive shells as it is for scripts, and you should probably not expect to be using or encountering aliases in scripts at all, if you can avoid it.

[guerrilla]

As I said, it depends on which which you mean. In this case, Debian is changing it's behavior away from how it's been for 28 years or whatever and breaking heaps of code and people's habits in the process.

[Taywee]

Yes, you're right. I think it's fine to depend on the existing which behavior for the current use cases. I just disagree that the behavior is really more useful than `command -v` for any sort of build or scripting purposes. It's definitely more useful as a user-facing utility to have a very recognizable name, like `which`. I'm one of the people who had never heard of `command -v` before now, and I'd used `which` for scripting, because I assumed it was standardized. I just don't see much use case for a shell command that finds a command in the path while specifically ignoring all aliases, functions, and built-ins over something like `command -v`.

> In this case, Debian is changing it's behavior away from how it's been for 28 years

In this case, Debian has voted to keep it the same: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994275

[pxc]

> I just don't see much use case for a shell command that finds a command in the path while specifically ignoring all aliases, functions, and built-ins over something like `command -v`.

It's useful if you want to track down an executable! For example, if you're performing an Arch Linux install for the first time in years, and you notice that a program is missing on your install but present on the installation media, you can use `which` in combination with `realpath` and `pacman -Qf` to find out what you need to install to get it. (This happened to me a couple days ago, when I decided to really revisit Arch for the first time in over a decade.)

Also, `command -v` reporting builtins is kinda against the spirit of the `command` command in the first place. From, for example, the bash help:

    $ help command
    command: command [-pVv] command [arg ...]
        Execute a simple command or display information about commands.

        Runs COMMAND with ARGS suppressing  shell function lookup, or display
        information about the specified COMMANDs.  Can be used to invoke commands
        on disk when a function with the same name exists.

        Options:
          -p    use a default value for PATH that is guaranteed to find all of
                the standard utilities
          -v    print a description of COMMAND similar to the `type' builtin
          -V    print a more verbose description of each COMMAND

        Exit Status:
        Returns exit status of COMMAND, or failure if COMMAND is not found.

> Runs COMMAND with ARGS suppressing shell function lookup

Or in the ksh manual:

       command [ -pvxV ] name [ arg ... ]
              Without  the  -v  or  -V options, command executes name with the arguments given by arg.  The -p option causes a default path to be searched rather than the one defined by the value of PATH.  Functions will not be searched for when finding name.  In addition, if name refers to a special built-in, none of the special properties associated with the leading daggers will be honored.  (For example, the predefined alias redirect=′command exec′ prevents a  script  from  terminating when  an invalid redirection is given.)  With the -x option, if command execution would result in a failure because there are too many arguments, errno E2BIG, the shell will invoke command name multiple times with a subset of the arguments on each invocation.  Arguments that occur prior to the first word that expands to multiple arguments and after the last word that expands to multiple arguments will be passed on each invocation.  The exit status will be the maximum invocation exit status.  With the -v option, command is equivalent to the built-in whence command described below.  The -V option causes command to act like whence -v.
              

> Functions will not be searched for when finding name. In addition, if name refers to a special built-in, none of the special properties associated with the leading daggers will be honored.

and so on.