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

91–100 of 257 posts

Re: Debian's Which Hunt

#91

Post by pxc »

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'm a descriptivist when it comes to standards

You can't quite be. Standards are norms, so there's no escaping normativity there. And simply describing existing conventions can't solve the problems that standards are introduced to solve, which is when you are faced with multiple, sometimes incompatible ways of doing things.

There's room for a kind of descriptivist reconciliation with updates to standards, though. You can say ‘Future versions of the standard should, as far as possible, directly incorporate contemporaneous usage. Where contemporaneous usage is divergent, they should reflect the virtues of contemporaneous usage in a new standard capable of replacing divergent uses.’

Re: Debian's Which Hunt

#92

Post by marcosdumay »

Taywee wrote: post #52
goohle wrote: post #35

Earlier quoted context omitted.

$ which true /usr/bin/true $ command -v true true $ which ls /usr/bin/ls $ command -v ls alias ls='ls --color=auto'

In this case, `which` is just searching the `PATH` and not telling you what will actually run. `command` is correctly informing you of the whole story. I'll add that `which` on my setup is using the zsh built-in, which also informs of aliases and built-ins. So yes, that's more useful if you're using `which` to determine "Does this name exist as an executable anywhere in the PATH", but most people use it to mean "What…

> `command` is correctly informing you of the whole story.

You are assuming a bit too much here.

Which tells you the preferred executable with that name, while command tells you what will run if you execute it on the current shell.

From what I can tell, one does not replace the other. But yes, for your example of usage, command is more correct.

Re: Debian's Which Hunt

#93

Post by Spivak »

sixothree wrote: post #54
richardwhiuk wrote: post #49

Earlier quoted context omitted.

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

I get that. I'm just surprised it's still considered acceptable. I feel like even simple JSON would be a better output. Sure, humans would have a problem reading it but that's what shells are for.

That JSON would be the text output of the command. There are utilities like grep, find, sed, awk, git porcelain, readlink, basedir, which, that write output suitable for machines on stdout and other utilities that write output suitable for humans.

If you want to be a good UNIX netizen then stdout is for machines while stderr is for humans.

Re: Debian's Which Hunt

#95

Post by buitreVirtual »

WastingMyTime89 wrote: post #82
emptyparadise wrote: post #7

Seems like this is a case of Debian governance working as designed. I'm surprised that 'which' isn't POSIX though.

Still a gigantic waste of everyone time. They could just have kept which has it has been for more than a decade and nothing would have happened. That's the decision that prevailed in the end but the fact that it had to go all the way to the Technical Committee before sanity prevailed says a lot about the utter madness of the Debian development process.

If there wasn't a committee, the change would have been made and a lot of people would have suffered. In this particular case, the time spent in following the process is negligible compared to the damage this change would have caused.

Re: Debian's Which Hunt

#96

Post by eddieh »

pxc wrote: post #75
Taywee wrote: post #48

Earlier quoted context omitted.

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 `co…

tcsh on my system:

    $ tcsh --version
    tcsh 6.21.00 (Astron) 2019-05-08 (x86_64-apple-darwin) options wide,nls,dl,bye,al,kan,sm,rh,color,filec
    $ tcsh
    % command -v command
    command
    % command -V command
    command is a shell builtin
    % builtins | grep command
    %

Re: Debian's Which Hunt

#97

Post by ysavir »

WastingMyTime89 wrote: post #82
emptyparadise wrote: post #7

Seems like this is a case of Debian governance working as designed. I'm surprised that 'which' isn't POSIX though.

Still a gigantic waste of everyone time. They could just have kept which has it has been for more than a decade and nothing would have happened. That's the decision that prevailed in the end but the fact that it had to go all the way to the Technical Committee before sanity prevailed says a lot about the utter madness of the Debian development process.

My take away is that they have a great system which allowed for voices to be heard, perspectives to be presented, and for an ultimate decision made in the best interest of Debian users. Doesn't seem a waste of time to me.

Re: Debian's Which Hunt

#98

Post by guerrilla »

eddieh wrote: post #96
pxc wrote: post #75

Earlier quoted context omitted.

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 `co…

tcsh on my system: $ tcsh --version tcsh 6.21.00 (Astron) 2019-05-08 (x86_64-apple-darwin) options wide,nls,dl,bye,al,kan,sm,rh,color,filec $ tcsh % command -v command command % command -V command command is a shell builtin % builtins | grep command %

Someone should make this into a blog post at this point :P

Re: Debian's Which Hunt

#99

Post by denton-scratch »

marcosdumay wrote: post #88
denton-scratch wrote: post #24

Earlier quoted context omitted.

Not like systemd, then. [Edit] I didn't mean the systemd thing lacked transparency; I just mean the result wasn't "nice".

The systemd thing was extremely transparent. It didn't reach a solution that satisfied everybody, but there wasn't any secrecy on it.

Yes.

I have no gripe about the process. (Well, I don't think it was a technical decision, so it shouldn't have been dumped on the TC). It was pellucidly transparent. Exemplary, really.

I just really don't like systemd, so I'm sorry that it became the Debian default init. My gripe is with the outcome, not the process. Most package-maintainers must have disagreed with me. It's OK, I'm used to people not agreeing with me.

/me still a Debian user, with sysvinit.

Re: Debian's Which Hunt

#100

Post by kevin_thibedeau »

WastingMyTime89 wrote: post #82
emptyparadise wrote: post #7

Seems like this is a case of Debian governance working as designed. I'm surprised that 'which' isn't POSIX though.

Still a gigantic waste of everyone time. They could just have kept which has it has been for more than a decade and nothing would have happened. That's the decision that prevailed in the end but the fact that it had to go all the way to the Technical Committee before sanity prevailed says a lot about the utter madness of the Debian development process.

I don't get why they can't switch to GNU which and put it in whatever package it harmonizes with. Throwing out deprecation notices for core utilities is irresponsible.
Post reply on HN