Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian's Which Hunt

lwn.net

Post reply on HN
Print view View original

71–80 of 257 posts

Re: Debian's Which Hunt

#71

Post by [deleted] »

sixothree wrote: post #47
nonameiguess wrote: post #22

> The POSIX-blessed way of finding an executable program is command -v, which is consequently built into most shells. Given the standard alternative, Adams said, "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job". While I can understand having this attitude, a whole lot of package build scripts, not just in Debian, but in the upstreams, rely up…

Wait. Is the problem here extra _text_ in the output that shouldn't be parsed? I cannot believe people are parsing text output from other commands in the year 2021. To me that this sounds like incredibly unsafe practice and am just astounded it happens.

[deleted]

Re: Debian's Which Hunt

#72

Post by capableweb »

guerrilla wrote: post #61
Taywee wrote: post #58

Earlier quoted context omitted.

The problem is that `which` behaves differently in many different existing use-cases (sometimes reporting aliases and sometimes not). If POSIX defines the behavior, then many existing uses become non-standard, and the existing implementations have to decide to change to become standard and possibly break backward compatibility or remain the same and stay non-standard.

In that case, pick the system which is statistically dominant and clone that. That'd be GNU first and FreeBSD second. The standard can be some subset of their behavior.

Or, add a new standard describing the wanted behavior from `which` which everyone is already using, but put it under a new binary name. If it's supposed to show the path for the thing passed in, maybe `where` would make sense.

Re: Debian's Which Hunt

#74

Post by anonydsfsfs »

jagger27 wrote: post #66

Here's how zsh 5.8 behaves on macOS: $ which {which,type,command,vi} which: shell built-in command type: shell built-in command command: shell built-in command /usr/bin/vi $ type {which,type,command,vi} which is a shell builtin type is a shell builtin command is a shell builtin vi is /usr/bin/vi $ command -v {which,type,command,vi} which type command /usr/bin/vi Which is quite different from how bash 5.1 behaves: bas…

"command -v" isn't reliable because several shells (including Dash) don't obey the POSIX standard. See https://github.com/oilshell/oil/blob/8fbc09bb3254cee944b0450...

Re: Debian's Which Hunt

#75

Post by pxc »

Taywee wrote: post #48
guerrilla wrote: post #27

Earlier quoted context omitted.

It's pretty much useless for the same purpose: $ which ls /usr/bin/ls $ type ls ls is aliased to `ls --color=auto' $ command -v ls alias ls='ls --color=auto' Suddenly I find myself irritated at Debian despite not even using it. Why would they not just include the GNU one?

That depends on whether your shell has a built-in which or not. Mine says % which ls ls: aliased to /bin/ls --color=auto Which makes way more sense. Your "which" is not telling you what will actually be executed when you run the `ls` command there. `command`, on the other hand, is guaranteed to be a built-in, has consistent behavior, and has defined, consistent output, unlike `which`. What `which` outputs will be dif…

You can use the `command` command to determine which `which` you use ;)

    % which which
    which: shell built-in command
    % command which which
    /run/current-system/sw/bin/which
I like to use `which` together with `realpath` to see what exact version of a program I'm using, e.g. (in Fish),

    [I] ⋊> ~ realpath (command which which)
    /nix/store/3w3rvxhlv5dcmdih72da6m613qyav9kw-which-2.21/bin/which
Idk if it's also POSIX, but `command` also typically has an analogue called `builtin` that you can use ensure that you are not looking at an external command, e.g.:

    [I] ⋊> ~ builtin which which   # Fish doesn't have a builtin called `which`
    fish: Unknown builtin “which”
    [I] ⋊> ~ command command command # and I don't have an external command called `command`
    command: command not found
It can also be useful for figuring out which package owns an executable you're running, e.g., on Debian-based systems (also with Fish):

    > apt show (dpkg -S (realpath (command which php)) | cut -d':' -f1)
    Package: php7.4-cli
    Version: 7.4.25-1+ubuntu18.04.1+deb.sury.org+1
    Priority: optional
    Section: php
    Source: php7.4
    Maintainer: Debian PHP Maintainers 
    Installed-Size: 4,711 kB
    Provides: php-cli, phpapi-20190902
    Depends: libedit2 (>= 2.11-20080614-4), libmagic1, mime-support, php7.4-common (= 7.4.25-1+ubuntu18.04.1+deb.sury.org+1), php7.4-json, php7.4-opcache, php7.4-readline, tzdata, ucf, libargon2-1 (>= 0~20171227), libc6 (>= 2.27), libpcre2-8-0 (>= 10.32), libsodium23 (>= 1.0.14), libssl1.1 (>= 1.1.0), libxml2 (>= 2.8.0), zlib1g (>= 1:1.1.4)
    Suggests: php-pear
    Download-Size: 1,398 kB
    APT-Sources: http://ppa.launchpad.net/ondrej/php/ubuntu bionic/main amd64 Packages
    Description: command-line interpreter for the PHP scripting language
    This package provides the /usr/bin/php7.4 command interpreter, useful for
    testing PHP scripts from a shell or performing general shell scripting tasks.
    .
    The following extensions are built in: Core date filter hash libxml openssl
    pcntl pcre Reflection session sodium SPL standard zlib.
    .
    PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used
    open source general-purpose scripting language that is especially suited
    for web development and can be embedded into HTML.

    N: There is 1 additional record. Please use the '-a' switch to see it
> What `which` outputs will be different depending on shell

This is also true of `command -v`, whose behavior with respect to builtins varies per shell, and is not implemented in some shells.

Fish:

    [I] ⋊> ~ fish --version                                                                                                  10:55:42
    fish, version 3.3.1
    [I] ⋊> ~ command -v command
    [I] ⋊> ~ command -v which
    /run/current-system/sw/bin/which
tcsh:

    > tcsh --version
    tcsh 6.22.04 (Astron) 2021-04-26 (x86_64-unknown-linux) options wide,nls,dl,al,kan,sm,rh,color,filec
    > command -v command
    command: Command not found.
    > command -v which
    command: Command not found.
    > builtins | grep command
    >
ksh:

    $ ksh --version
      version         sh (AT&T Research) 2020.0.0
    $ command -v command
    'command '
    $ command -v which
    /run/current-system/sw/bin/which
    $
mksh:

    $ echo $KSH_VERSION
    @(#)MIRBSD KSH R59 2020/10/31
    $ command -v command
    command
    $ command -v which
    /run/current-system/sw/bin/which
    $
pwsh:

    PS> $PSVersionTable

    Name                           Value
    ----                           -----
    PSVersion                      7.1.4
    PSEdition                      Core
    GitCommitId                    7.1.4
    OS                             Linux 5.14.12 #1-NixOS SMP Wed Oct 13 07:42:04 UTC 2021
    Platform                       Unix
    PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
    PSRemotingProtocolVersion      2.3
    SerializationVersion           1.1.0.1
    WSManStackVersion              3.0

    PS> command -v command
    PS> command -v which
    PS> command which

    CommandType     Name                                               Version    Source
    -----------     ----                                               -------    ------
    Application     which                                              0.0.0.0    /run/current-system/sw/bin/which
Granted, some of those shells (Fish, tcsh, PowerShell) don't aim for full POSIX compliance, and the most popular shells (bash, dash, zsh) all behave the same way as mksh in the example above. But you can also see that the output given for builtins varies among POSIX shell implementations by comparing the output of the AT&T Korn shell to the MirBSD Korn shell.

Re: Debian's Which Hunt

#77

Post by ketralnis »

capableweb wrote: post #72
guerrilla wrote: post #61

Earlier quoted context omitted.

In that case, pick the system which is statistically dominant and clone that. That'd be GNU first and FreeBSD second. The standard can be some subset of their behavior.

Or, add a new standard describing the wanted behavior from `which` which everyone is already using, but put it under a new binary name. If it's supposed to show the path for the thing passed in, maybe `where` would make sense.

A standards descriptivist is unlikely to agree with "make a new standard so everybody has to change their behaviour"

Re: Debian's Which Hunt

#78

Post by pxc »

Taywee wrote: post #55
guerrilla wrote: post #50

Earlier quoted context omitted.

That depends on which which you mean. Which on GNU has always been this: NAME which - shows the full path of (shell) commands. DESCRIPTION Which takes one or more arguments. For each of its arguments it prints to stdout the full path of the executables that would have been executed when this argument had been entered at the shell prompt. It does this by searching for an executable or script in the directories listed…

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, th…

> 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
    _______
    
    -------
            \   ^__^
             \  (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.

Re: Debian's Which Hunt

#79

Post by denton-scratch »

Taywee wrote: post #56
chasil wrote: post #46

Earlier quoted context omitted.

I am fairly certain that which came first. This is the POSIX specification for command: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...

Notable sections from that page: > The command -v and -V options were added to satisfy requirements from users that are currently accomplished by three different historical utilities: type in the System V shell, whence in the KornShell, and which in the C shell. Since there is no historical agreement on how and what to accomplish here, the POSIX command utility was enhanced and the historical utilities were left unmo…

Hmm. So you have two conflicting conventions; and the solution is a third convention. Now you have three conflicting conventions.

I think I've come across this somewhere else.

Re: Debian's Which Hunt

#80

Post by pxc »

Taywee wrote: post #67
guerrilla wrote: post #59

Earlier quoted context omitted.

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.

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…

> 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.

Post reply on HN