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

231–240 of 257 posts

Re: Debian's Which Hunt

#231

Post by rolandog »

hibbelig wrote: post #212
kjeetgill wrote: post #207

Earlier quoted context omitted.

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! #!

The ls command does this: if output is to a tty then it prints in columns. Many commands add color when the output is a tty. I don’t think it would be a big issue.

Not the person you replied to, but I hadn't thought about that particular difference and I take it for granted, so thanks for bringing it up!

Re: Debian's Which Hunt

#232

Post by marcosdumay »

josefx wrote: post #218
marcosdumay wrote: post #87

Earlier quoted context omitted.

> "but it's non-standard!" can be fixed by making it a standard. But which which do you make standard? When one says it's non-standard, it normally means that you don't know if the way you are using it will work on other places.

Unix predates POSIX -> All Unix flavors were non standard + your reasoning -> POSIX cannot exist.

Making it standard is a lot of hard work while you make a lot of people argue and act in a way that makes sure that some part of the thing will work everywhere.

Standards exist on the real world, you can't just define them into existence without doing the work.

Re: Debian's Which Hunt

#233

Post by eddieh »

pxc wrote: post #102
eddieh wrote: post #96

Earlier quoted context omitted.

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 %

Yeah, this is probably because macOS has done something very, very weird, and added an executable `/usr/bin/command` to the system. These are the contents on the old MacBook I have for work right here: #!/bin/sh # $FreeBSD: src/usr.bin/alias/generic.sh,v 1.2 2005/10/24 22:32:19 cperciva Exp $ # This file is in the public domain. builtin `echo %{0##*/} | tr \[:upper:] \[:lower]` ${1+"$@"} If you have SIP disabled, try…

I do have SIP disabled for DYLD_LIBRARY_PATH and a handful of other things, but macOS still says /usr/bin/command is on a read-only file system.

[edit]

Not hard to remount root as writable

    $ sudo mount -uw /
    Password:
    $ sudo mv /usr/bin/command /usr/bin/command.save
    $ tcsh
    % command -v command
    command: Command not found.
    % command -V command
    command: Command not found.
    %
Now reversing the changes

   % exit
   exit
   $ sudo mv /usr/bin/command.save /usr/bin/command
   $ sudo mount -ur /
   mount_apfs: volume could not be mounted: Invalid argument
   mount: / failed with 66
Looks like I'll have to reboot to get the read-only state back.

Re: Debian's Which Hunt

#235

Post by jagger27 »

pxc wrote: post #226
jagger27 wrote: post #104

Earlier quoted context omitted.

It’s a shell built-in.

No, macOS has an executable called `command` so that it is available even on shells that don't implement the builtin

If you look at the last part of my comment, you’ll see it’s just a shell script that invokes the built-in.

Re: Debian's Which Hunt

#236

Post by Woodi »

quotemstr wrote: post #209
Seirdy wrote: post #187

Earlier quoted context omitted.

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…

> Or you can give the middle finger to POSIX

Ok, pleas someone tell me how to use that "upvote" festure on HN :)

More on the subject, nor type nor command, nor constantly mentioned shellcheck recipe for all posixs actually do what which do - just returns path ! Looks like with some options, maybe, but it could be simply added with "which -h" - (standard *nix human readable form toggle), if -h is not already taken.

POSIX in the first place should just standarise which instead of inventing some "command".

Advice: to write best POSIX scripts write moustly-POSIX scripts and be done. Simply becose you should write big shell scripts in the first place. It is Perl job and it do it very better. And if you want more you need C and actually using system calls yourself, eg. for precise path not-globbing.

PS. Now just wait for Mr Poettering take on the subject becouse why be bothered by decades old working admins opinions or work conditions ? Or usable standards, or already working code, or not containers use cases, or just short, human friendly commandline ? Or not tangled and small codebases ?? Let's leave it to, I don't know, IBM ? Is systemd portable to AIX yet, any plans ? ;) WINDOWIZACION95 FTW

Re: Debian's Which Hunt

#237

Post by denton-scratch »

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…

I didn't know about the "help" command in bash. I've always gone to "man bash", and then scrolled up and down for an hour or so.

Or just cranked-up a search engine.

So thanks for that.

Re: Debian's Which Hunt

#238

Post by pxc »

jagger27 wrote: post #235
pxc wrote: post #226

Earlier quoted context omitted.

No, macOS has an executable called `command` so that it is available even on shells that don't implement the builtin

If you look at the last part of my comment, you’ll see it’s just a shell script that invokes the built-in.

Yeah, I discovered that after I made my previous comment, and before I saw your whole long one.

It's a weird choice, because it means that command will sometimes tell you about 'builtins' that are not actually built in to the shell you invoke it from, including `command` itself.

Re: Debian's Which Hunt

#239

Post by lucb1e »

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…

> having it print out a deprecation warning without considering what that means to all the people that use it

Virtually every command can fail in some way, and they will all write to stderr (or worse, stdout, but that's not what happened here). How is that unexpected at all? How else would you communicate the change? (For the sake of argument, let's say the change is going to happen regardless, since you're arguing for the irresponsibleness of showing a warning.)

Re: Debian's Which Hunt

#240

Post by lucb1e »

anonydsfsfs wrote: post #74
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...

I checked your link but I don't quite get it. Is status=0 supposed to be a check rather than an assignment?

Either way, it doesn't have that behavior like that for me on Debian: it behaves the same as bash. This is in dash:

    $ command -v whoami
    /usr/bin/whoami
    $ echo $?
    0
    $ command -v echo
    echo
    $ echo $?
    0
    $ command -v nonexistent
    $ echo $?
    127
So that is with both a proper command (whoami), a shell built-in (echo), and neither (nonexistent). It's all as I would expect from a shell.

Bash does exactly the same, although dash chooses 127 as exit status and bash chooses 1 but they're both nonzero (thus error statuses).

Post reply on HN