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

191–200 of 257 posts

Re: Debian's Which Hunt

#191

Post by rezonant »

mjevans wrote: post #138
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.

Minimally breaking solution 1) Require the output of which in non-interactive environments to conform to the behavior a reasonable shell script author is likely to have assumed the specification was based on observations. In the case of historic 'which' that would be to print the absolute path to an executable without any other arguments, or a specific error message and exit status. 2) Allow __interactive__ shells to…

This is shockingly obvious and it's sort of crazy that it doesn't seem to be discussed [edit: in the overall discussion not just this thread]

Re: Debian's Which Hunt

#192

Post by soraminazuki »

sneak wrote: post #108
pornel wrote: post #45

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.

Also, POSIX is basically irrelevant now. There are only two Unixen that anyone uses: RMS/Linux and whatever outdated garbage userspace Apple is shipping with macOS.

> whatever outdated garbage userspace Apple is shipping with macOS

Is that a criticism of the FreeBSD userspace? Because that's where much of Apple's UNIX userspace is derived from, and they're regularly synced with upstream.

Re: Debian's Which Hunt

#194

Post by cryptonector »

Taywee wrote: post #58
pornel wrote: post #45

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.

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.

That is NOT a problem. Because which is an external program, it can't know about things like shell aliases and functions, and that's OK because users know it or expect it. Indeed, if you're writing a script then you already know what aliases and functions are in it, and you're only going to be interested in knowing what's outside the script -- which(1) does that just fine.

Stop looking for problems to solve where there are no problems. It's a waste of others' time, not just your own. Be respectful of others' time.

Re: Debian's Which Hunt

#195

Post by kleiba »

kelnos wrote: post #152

> * 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".* This feels a little tone-deaf to me. I've been using the *nix command-line and writing (and reading) shell scripts for 20+ years,…

`which` and `command -v` give different results when you have aliased a command, e.g., `alias ls='ls --color=auto'`.

Re: Debian's Which Hunt

#196

Post by cryptonector »

Liquix wrote: post #105
overgard wrote: post #103

When I read stuff like this I can't help but wonder how anything ever even gets done on this project. The amazing thing is 'which' was working perfectly fine for everyone. Just leave it alone? The amount of time they wasted on debating this is staggering compared to just not changing it.

>I can't help but wonder how anything ever even gets done on this project Slowly, methodically, and with minimal user impact. As mentioned at the end of the article, what first appears a waste of time for a small issue could also be seen as a beautiful illustration of the democratic process that makes Debian so stable/widely adopted.

Removing which(1) is NOT "minimal user impact". Evidently it's also not minimal maintainer impact. All this sturm und drang of which(1) is completely unjustified and far exceeds the work of including that BSD option or deciding to not include it.

Re: Debian's Which Hunt

#198

Post by rascul »

Izkata wrote: post #166
liquidise wrote: post #159

Earlier quoted context omitted.

My story would echo this same sentiment. Incidentally, running `man command` on OS X actually does not reference a '-v' option at all, instead only stating the more verbose `command which`. Both appear to work, but it further highlights your (our) discoverability issue(s).

There is no man or info page for "command" on Ubuntu, I guess it's just a bash builtin ("which command" doesn't find it). "which" has a man page though.

For bash, it is documented with 'help command' or the bash man page, section SHELL BUILTIN COMMANDS.

Re: Debian's Which Hunt

#199

Post by rascul »

AceJohnny2 wrote: post #172
liquidise wrote: post #159

Earlier quoted context omitted.

My story would echo this same sentiment. Incidentally, running `man command` on OS X actually does not reference a '-v' option at all, instead only stating the more verbose `command which`. Both appear to work, but it further highlights your (our) discoverability issue(s).

The main problem is there is no good way to provide manpages for shell builtins, like `command`. Man can only have one entry (per section) for a given command, but what if you're using Bash? Or Zsh? How would it know which one to give you? If they're named differently (like a manpage for `bash-command` vs `zsh-command`), how would you know to look those up? (never mind that apropos would give you so-overloaded-to-be-…

There could potentially be a bash- man page. For example, bash-command or bash-mapfile.

Re: Debian's Which Hunt

#200

Post by rascul »

pornel wrote: post #45

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.

I don't see that there's a POSIX way to provide the same functionality of 'which' without searching $PATH yourself.
Post reply on HN