51–60 of 257 posts
Seems fine to deprecate its usage inside bash scripts or scripts that you know are pegged to an interpreter that implements `command`, though.
Earlier quoted context omitted.
What's not machine-friendly about `command -v`'s output? Can you not just use the exit status? Or did you mean that you avoid `which` in favor of `command -v`?
$ which true /usr/bin/true $ command -v true true $ which ls /usr/bin/ls $ command -v ls alias ls='ls --color=auto'
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 will actually be executed if I run this word as a command?"
edit: Or, most often in scripts, it's used just for its exit status to tell whether the command exists to be executed at all.
Earlier quoted context omitted.
What's not machine-friendly about `command -v`'s output? Can you not just use the exit status? Or did you mean that you avoid `which` in favor of `command -v`?
$ which true /usr/bin/true $ command -v true true $ which ls /usr/bin/ls $ command -v ls alias ls='ls --color=auto'
Earlier quoted context omitted.
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.
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.
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…
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…
That description is also doesn't correctly describe the behavior of the command if the shell has any aliases or built-ins of that name. If you have an alias that points to a different command, then `which` is distinctly not printing the executable that would have been executed.
Earlier quoted context omitted.
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...
> The command -v and -V options were added to satisfy requirements from users that are currently accomplished by three different historical utilities: type in the System V shell, whence in the KornShell, and which in the C shell. Since there is no historical agreement on how and what to accomplish here, the POSIX command utility was enhanced and the historical utilities were left unmodified. The C shell which merely conducts a path search. The KornShell whence is more elaborate-in addition to the categories required by POSIX, it also reports on tracked aliases, exported aliases, and undefined functions.
> The output format of -V was left mostly unspecified because human users are its only audience. Applications should not be written to care about this information; they can use the output of -v to differentiate between various types of commands, but the additional information that may be emitted by the more verbose -V is not needed and should not be arbitrarily constrained in its verbosity or localization for application parsing reasons.
I'm immediately turned off by this person. They don't say exactly who or when the command was altered to put the warning in place, but it sounds like one inept, opinionated person decided to flip a switch without caring about any other practical reasons that conflict with his puritan take.
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.
Earlier quoted context omitted.
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…
Unless you're using a shell that subverts that by providing its own built-in, like Zsh, which is allowed because there is no standard for `which`, and depending on its behavior can be problematic and inherently non-portable. That description is also doesn't correctly describe the behavior of the command if the shell has any aliases or built-ins of that name. If you have an alias that points to a different command, th…
'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.