4 ms·

Wait what macOS has an executable called `command`? Does any other OS?

by pxc 5y ago

jagger27 5y ago
It’s a shell built-in.
- pxc 5y ago
  No, macOS has an executable called `command` so that it is available even on shells that don't implement the builtin
  - jagger27 5y ago
    If you look at the last part of my comment, you’ll see it’s just a shell script that invokes the built-in.
    - pxc 5y ago
      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.
kayodelycaon 5y ago
BSD and Linux do.
- pxc 5y ago
  What Linux distros do? The comments in the `command` script on macOS indicate that FreeBSD included a separate executable for `command` in 2005. But there's no package in all of Nixpkgs providing a `command` executable and the command-not-found handler for Ubuntu doesn't suggest anything either. The norm, afaict, is for `command` to be a shell built-in only, and not available as a separate program.
kelnos 5y ago
The article points out that "command -v" is the only thing in this mess that's actually standardized by POSIX as "print out the path to the thing specified".
- pxc 5y ago
  The standard[1] is for a shell built-in, not a separate executable: > Since command is a regular built-in utility it is always found prior to the PATH search. That's why it's weird that macOS has an executable which wraps it from `sh`, which I've discovered since the GP is something it inherits from FreeBSD. I'm not sure if FreeBSD still does this (some FreeBSD poster let me know), but apparently they used to generate wrappers for shell builtins pegged to #!/bin/sh and drop them in /usr/bin, presumably so that scripts running in non-POSIX shells that didn't implement them at all could still invoke them. It seems kinda neat. But it also leads to weird behavior where you can run `command` in tcsh and it will tell you something is a shell built-in even though it doesn't appear in the list of tcsh's shell builtins and you're running tcsh, which seems... wrong. — 1: https://pubs.opengroup.org/onlinepubs/007904975/utilities/command.html https://pubs.opengroup.org/onlinepubs/007904975/utilities/co...
tiahura 5y ago
MS-DOS
deleted 5y ago
[deleted]

Wait what macOS has an executable called `command`? Does any other OS?

by pxc 5y ago

Wait what macOS has an executable called `command`? Does any other OS?

jagger27 5y ago

It’s a shell built-in.

pxc 5y ago
No, macOS has an executable called `command` so that it is available even on shells that don't implement the builtin
- jagger27 5y ago
  If you look at the last part of my comment, you’ll see it’s just a shell script that invokes the built-in.
  - pxc 5y ago
    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.

kayodelycaon 5y ago

BSD and Linux do.

pxc 5y ago
What Linux distros do? The comments in the `command` script on macOS indicate that FreeBSD included a separate executable for `command` in 2005. But there's no package in all of Nixpkgs providing a `command` executable and the command-not-found handler for Ubuntu doesn't suggest anything either. The norm, afaict, is for `command` to be a shell built-in only, and not available as a separate program.

kelnos 5y ago

The article points out that "command -v" is the only thing in this mess that's actually standardized by POSIX as "print out the path to the thing specified".

pxc 5y ago
The standard[1] is for a shell built-in, not a separate executable: > Since command is a regular built-in utility it is always found prior to the PATH search. That's why it's weird that macOS has an executable which wraps it from `sh`, which I've discovered since the GP is something it inherits from FreeBSD. I'm not sure if FreeBSD still does this (some FreeBSD poster let me know), but apparently they used to generate wrappers for shell builtins pegged to #!/bin/sh and drop them in /usr/bin, presumably so that scripts running in non-POSIX shells that didn't implement them at all could still invoke them. It seems kinda neat. But it also leads to weird behavior where you can run `command` in tcsh and it will tell you something is a shell built-in even though it doesn't appear in the list of tcsh's shell builtins and you're running tcsh, which seems... wrong. — 1: https://pubs.opengroup.org/onlinepubs/007904975/utilities/command.html https://pubs.opengroup.org/onlinepubs/007904975/utilities/co...

tiahura 5y ago

MS-DOS

deleted 5y ago

[deleted]