171–180 of 257 posts
Earlier quoted context omitted.
And yet they destabilized things by adding the deprecation/trying to get rid of it. And what even was the point of that?
They also mentioned how this could happen at the end of the article. In the end they are working on a distro with certain ideals and this illustrates how they can achieve things with their ideals in mind.
> * 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,…
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).
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-useless results for something as generic as `command`)
Which leaves us in the current situation where `man command` redirects to a generic `builtin` manpage, that doesn't have much info, and certainly nothing specific to Bash or Zsh.
Earlier quoted context omitted.
>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.
And yet they destabilized things by adding the deprecation/trying to get rid of it. And what even was the point of that?
I tried Manjaro the other day -- out of the box, wake from sleep was broken, bluetooth was broken, and 3/3 printers were broken. I eventually got sleep working with an older kernel version, I got bluetooth working with config file hacking, and I got the printers working with CUPS wrangling -- but on Ubuntu, all of this Just Worked for me.
That's the point of it.
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…
My own preference these days is to explicitly use /bin/zsh and just rely on zsh behaviour (e.g. "$+commands[ls]"). It's not "compatible" in the sense of "POSIX compatible", but it's more compatible in the sense of "much higher chance everything will work on a random system", with the only downside that people will need to install zsh. I think that's a fair trade-off for many (though obviously not all) cases.
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…
I understand Bourne style (POSIX) shells have the vast majority of the market, but the point is breaking other environments. "command -v" is not available everywhere so it is not a viable replacement for /usr/bin/which.
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.
$ 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 guaranteed to find all of
the standard utilities
-v print a description of COMMAND similar to the `type' builtin
-V print a more verbose description of each COMMAND
Exit Status:
Returns exit status of COMMAND, or failure if COMMAND is not found.Earlier quoted context omitted.
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.
FreeBSD with ZFS and being the backend of network CDN's wants a word or two with you.
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.
Earlier quoted context omitted.
In that case, pick the system which is statistically dominant and clone that. That'd be GNU first and FreeBSD second. The standard can be some subset of their behavior.
That’s not usually how standards are supposed to work — a POSIX operating system should not reimplement Linux, it should only have to reimplement what’s portable to existing systems.