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

41–50 of 257 posts

Re: Debian's Which Hunt

#41

Post by mindcrime »

IshKebab wrote: post #28
simias wrote: post #12

Earlier quoted context omitted.

I learned about `command -v` just now reading this article. I only knew of `which` and `type` (as well as the very convenient `=executable` syntax that expands to the path of the binary, but I think that's a zsh-ism). What makes `command -v` not machine friendly? It seems to always output just the PATH, unlike type which tries to be human friendly.

> I learned about `command -v` just now reading this article Me too and I'm sure we're not the only ones. But look at this quote from the article: > surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job This is an mind-bogglingly misguided attitude. Anyone that has never heard of an obscure POSIX command is incompetent? Or is it that really that mos…

I'd also never heard of `command -v` until reading this article just now. But then I've only been using *nix systems for about 25 years.

Re: Debian's Which Hunt

#42

Post by denton-scratch »

shadowgovt wrote: post #34
vidanay wrote: post #3

Wow, talk about a tempest in a tea kettle. Bikeshedding like this is why Linux will never achieve any significant market share for average consumers. (Because all that mental effort could have been spent on solving some real problem instead of philosophical conformity.)

One of the advantage to the more hierarchical approach found in many commercial software development houses is that someone has the authority to say "These are about the same, we're doing it this way, the decision is arbitrary, and anyone who doesn't toe the line can work on something else." Makes it easier to avoid burning time on problems with equivalently-good solutions, or even not-equivalently-good-but-perfectio…

Non-hierarchical decision-making is hard work, and time-consuming. There are lots of challenges - it can be hijacked easily by arseholes, you need lots of rules that everyone has to learn, and nobody agrees on what "consensus" means.

Nevertheless, I think that if you can make it work then you get better decisions. Debian's been pretty good at it (systemd aside :-)

Re: Debian's Which Hunt

#44

Post by guerrilla »

scbrg wrote: post #38
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?

This is a very unlikely output when run from a script using the /bin/sh interpreter on Debian, though. If that is the output you've gone out of your way to create an alias in a script, in which case it's reasonable output. It is what will happen when the script runs that command, after all.

I'm certain there's masses of code that depends on `which` responding the way it does and scripts with aliases in them regardless of whether that was the right way to do it or not, so your point is probably irrelevant in the grand scheme of things. Think about all that enterprise install and setup crap. People still depend on that spaghetti trash working.

Re: Debian's Which Hunt

#45

Post by pornel »

I'm a descriptivist when it comes to standards. When everyone uses `which`, POSIX should add it. "but it's non-standard!" can be fixed by making it a standard.

Re: Debian's Which Hunt

#46

Post by chasil »

Enginerrrd wrote: post #32
dilawar wrote: post #2

'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.

What a mess. It sounds like command -v should have been the default from the get go and which should never have been introduced to debianutils. Once it was though, IMO, debian should never make a decision that breaks existing functionality. In general, I don't care if you extend features beyond POSIX in your core utilities, but once you do, you have to assume people rely on that functionality. I think this is the mos…

I am fairly certain that which came first.

This is the POSIX specification for command:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...

Re: Debian's Which Hunt

#47

Post by sixothree »

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.

Re: Debian's Which Hunt

#48

Post by Taywee »

guerrilla wrote: post #27
simias wrote: post #12

Earlier quoted context omitted.

I learned about `command -v` just now reading this article. I only knew of `which` and `type` (as well as the very convenient `=executable` syntax that expands to the path of the binary, but I think that's a zsh-ism). What makes `command -v` not machine friendly? It seems to always output just the PATH, unlike type which tries to be human friendly.

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 different depending on shell and what implementation of `which` you actually have installed.

Re: Debian's Which Hunt

#49

Post by richardwhiuk »

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.

Parsing the bytestream output of another program is the unix way.

Re: Debian's Which Hunt

#50

Post by guerrilla »

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…

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 in the environment vari‐
       able PATH using the same algorithm as bash(1).
Post reply on HN