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

201–210 of 257 posts

Re: Debian's Which Hunt

#201

Post by rascul »

22c wrote: post #170
throwaway09223 wrote: post #165

There's a problem with "command -v," in that it's not actually a command. It's a Bourne shell builtin. You can't use `command -v` in csh or other shells, only in Bourne style shells (bash, zsh, etc). /usr/bin/which is a standalone binary. It can be invoked without a shell at all. Many comments discussing `command` being part of POSIX are I think missing that `command` is only part of POSIX insofar as the Bourne shell…

You can use command -v in any POSIX compliant shell. csh is not POSIX compliant. Your list of shells in inexhaustive to the point of being almost misleading. bash and zsh are "heavy-weight" shells, a lot of lightweight shells also support command. If you're specifying your shebang as #!/bin/sh then you should not assume you have access to functions like type or binaries like which, but you can generally assume you ha…

> If you're specifying your shebang as #!/bin/sh then you should not assume you have access to functions like type

'type' is actually POSIX though. bash does extend it.

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

Re: Debian's Which Hunt

#202

Post by rascul »

denton-scratch wrote: post #141
tannhaeuser wrote: post #136

Earlier quoted context omitted.

Out of interest, are you using Devuan or other Debian distro specifically designed to be systemd-free?

Not Devuan, normal vanilla Debian (and one Debian-Xen VM host). There are instructions online for removing systemd; I think it is cause for regret that there isn't an install option and a commandline tool to "just do it". It's not tricky; it's just a nuisance that you have to do it at all. [Edit] And a debconfig thing. It should be that easy to switch. [Edit 2] I deserve to be voted down, I realise! I called for a ch…

Is this still relevant?

https://wiki.debian.org/systemd#Installing_without_systemd

I haven't used debian for awhile, and longer without systemd, I don't really know if that section still applies to the latest debian stable.

Re: Debian's Which Hunt

#203

Post by inkyoto »

kbenson wrote: post #125

Regardless of whether 'command -v' is a better alternative, 'which' is ensconced as standard practice in many shell scripts, and I would go so far as to say I think the majority of them that actually have to choose between the two use 'which'. Given that, having it print out a deprecation warning without considering what that means to all the people that use it is irresponsible. I help manage a few hundred servers. W…

> 'which' is ensconced as standard practice in many shell scripts

Ugh. Now that the UNIX universe has collapsed unto Linux, BSD's and very, very few other *X's, it is less of an issue, but «which», due to it having never been enshrined in standards, has never been safe to use in shell scripts, and an invocation could yield a suprise for the unprepared. At least on Solaris (if I am not mistaken), the «which» output yields *two* lines, of which the first is useless (along the lines of «ohiyo, lookie at what I have found») and with the second being the actual path to the binary. So «which» has never been truly portable and safe to use.

Re: Debian's Which Hunt

#204

Post by [deleted] »

kbenson wrote: post #125

Regardless of whether 'command -v' is a better alternative, 'which' is ensconced as standard practice in many shell scripts, and I would go so far as to say I think the majority of them that actually have to choose between the two use 'which'. Given that, having it print out a deprecation warning without considering what that means to all the people that use it is irresponsible. I help manage a few hundred servers. W…

[deleted]

Re: Debian's Which Hunt

#205

Post by kbenson »

inkyoto wrote: post #203
kbenson wrote: post #125

Regardless of whether 'command -v' is a better alternative, 'which' is ensconced as standard practice in many shell scripts, and I would go so far as to say I think the majority of them that actually have to choose between the two use 'which'. Given that, having it print out a deprecation warning without considering what that means to all the people that use it is irresponsible. I help manage a few hundred servers. W…

> 'which' is ensconced as standard practice in many shell scripts Ugh. Now that the UNIX universe has collapsed unto Linux, BSD's and very, very few other *X's, it is less of an issue, but «which», due to it having never been enshrined in standards, has never been safe to use in shell scripts, and an invocation could yield a suprise for the unprepared. At least on Solaris (if I am not mistaken), the «which» output yi…

I agree! Nothing I said was really to do with how scripts should be written, it's about how they are and how they have been written for decades at this point. People would be better served by not using which, and using something portable.

None of that helps this specific situation at all, which seems to have been poorly thought out in that it had the possibility of negatively affect many people, and not just the developers/admins who write scripts, but those that use what other people have written.

It's important to strive for chance for the better, but it's also important to see the world for how it actually is and what happens if that change happens all at once, which can (hopefully temporarily) be worse than what came before.

Re: Debian's Which Hunt

#206

Post by crehn »

matheusmoreira wrote: post #148
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 understand why people even care about POSIX in 2021. It's not like Linux distributions are POSIX certified. So many things can't be good because it's not in POSIX or because POSIX requires something else. People actually force themselves to write scripts in some mythical POSIX shell that nobody uses.

It's minimal effort to maximize compatibility and consistency, regardless of where the script may be run.

Shell scripts can run in a myriad of hosts, from VMs to stripped-down containers. When writing robust production code (not to say that shell scripts are ideal for that purpose), you'll want to minimize moving parts and risk surface, so that you can go home more confident that things will just work regardless of what you throw at it.

Re: Debian's Which Hunt

#207

Post by kjeetgill »

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…

I feel like I'm going to be bit when I try commands interactively and then that act differently in a script. I think the current solution is the pragmatic one, don't standardize things you can't pull off standardizing! #!

Re: Debian's Which Hunt

#208

Post by quotemstr »

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

Standards are supposed to reflect time-tested practice, not the other way around. Instead of "fixing" every shell script on Earth to use "command -v" instead of the superior and perfectly functional which(1) command, we should just change POSIX and standardize which(1).

Re: Debian's Which Hunt

#209

Post by quotemstr »

Seirdy wrote: post #187
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,…

You should be using ShellCheck or an equivalent linter on your shell scripts in POSIX mode if you want them to be portable; in POSIX mode it warns when using "which" instead of "command -v", and I think it also warns when using "whence" or "where" outside of zsh. There's a host of other Bashisms/GNUisms and other noncompliant antipatterns it checks for too. It's also worth reading through the POSIX manpages for POSIX…

> It's also worth reading through the POSIX manpages for POSIX sh if you want to be a good shell scripter.

Or you can give the middle finger to POSIX, write shell scripts for bash, or even zsh, and end up with faster, more correct, and more beautiful shell scripts that in practice are just as portable as the ones that mindlessly follow the limited and bizarre POSIX shell spec.

I'll write POSIXly-correct shell scripts when the POSIX people stop pretending it's still 1995.

Re: Debian's Which Hunt

#210

Post by fractalb »

sevensor wrote: post #176
Izkata wrote: post #166

Earlier quoted context omitted.

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.

In bash, such things are documented in the help system: $ 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 g…

Wow. I never knew this. I tried scouring through the bash manpage to get hold of its inbuilt commands. Thanks.
Post reply on HN