3 ms·

For context, how "compatible" is BSD utils with either one? IOW: how much does it matter?

by knorker 10mo ago

IshKebab 10mo ago
Not very. Most notably `env -S` doesn't work on some systems. I did get bitten by one script on Ubuntu using uutils where the script expected `uname -p` to work but it just prints `unknown` (technically legal I guess). But when I went to fix it they already had. Probably was a bit premature for Ubuntu to enable it by default. Looking at the graph uutils will be fully compatible (or as close as makes no difference) in about 2 years, so I would have waited until then. Still, I think most of the push-back is just the usual anti-Rust luddites.
- knorker 10mo ago
  > expected `uname -p` to work but it just prints `unknown` I just tried that on three very different Linux systems of mine, and all print `unknown`.
pseudalopex 10mo ago
These utilities' purpose is to replace GNU utilities. BSD utilities' purpose is not.
- knorker 10mo ago
  Seems like there's more uproar with this than with changing the /bin/sh symlink to dash, and that difference seems much bigger.
  - NekkoDroid 10mo ago
    To be fair, `/bin/sh` is suppose to be the POSIX shell, so as long as they are compliant it really doesn't matter. The problem with `/bin/sh` being bash, is that it provides extensions (even when running in POSIX mode from what I remember) and relying on them makes those scripts technically broken. It would be more of a comparison if dash was aiming to be a drop-in replacement for bash and not a POSIX shell.
    - knorker 10mo ago
      Well that's kind of my point. `ls` and `find` are "supposed to be" POSIX `ls` and `find`. Obviously on a GNU system one can't just drop the GNU extensions, but what Rust Coreutils is fighting is (IIUC) to a large extent the goal of becoming bug-compatible, or unspecified-compatible. For unspecified-compatible, to support users who relied on it (Hyrum's law), the same case could be made that lots of people relied on /bin/sh being bash. dash may not have been aiming to be drop-in replacement for bash, but when OS vendors change /bin/sh to dash, what's the difference?
      - NekkoDroid 10mo ago
        > Well that's kind of my point. `ls` and `find` are "supposed to be" POSIX `ls` and `find`. I don't know about that, I at least wouldn't 100% agree on that. Mostly since POSIX only defines short args it kinda makes just not want to use them, since I like to spell out the long arg in scripts for clarity. So by default I just assume I am using GNU coreutils (since BSD coreutils have slightly different names in some places IIRC). And since there isn't such a destinction between "POSIX coreutils" and "GNU coreutils" like there is with "POSIX shell" (sh) and "bash" I wouldn't call the situations equivalent.
  - pseudalopex 10mo ago
    Ubuntu made /bin/sh dash in 2006 according to Wikipedia. Many fewer people used Ubuntu then.

For context, how "compatible" is BSD utils with either one? IOW: how much does it matter?

by knorker 10mo ago

For context, how "compatible" is BSD utils with either one? IOW: how much does it matter?

Not very. Most notably `env -S` doesn't work on some systems. I did get bitten by one script on Ubuntu using uutils where the script expected `uname -p` to work but it just prints `unknown` (technically legal I guess). But when I went to fix it they already had. Probably was a bit premature for Ubuntu to enable it by default. Looking at the graph uutils will be fully compatible (or as close as makes no difference) in about 2 years, so I would have waited until then. Still, I think most of the push-back is just the usual anti-Rust luddites.

knorker 10mo ago
> expected `uname -p` to work but it just prints `unknown` I just tried that on three very different Linux systems of mine, and all print `unknown`.

pseudalopex 10mo ago

These utilities' purpose is to replace GNU utilities. BSD utilities' purpose is not.

knorker 10mo ago
Seems like there's more uproar with this than with changing the /bin/sh symlink to dash, and that difference seems much bigger.
- NekkoDroid 10mo ago
  To be fair, `/bin/sh` is suppose to be the POSIX shell, so as long as they are compliant it really doesn't matter. The problem with `/bin/sh` being bash, is that it provides extensions (even when running in POSIX mode from what I remember) and relying on them makes those scripts technically broken. It would be more of a comparison if dash was aiming to be a drop-in replacement for bash and not a POSIX shell.
  - knorker 10mo ago
    Well that's kind of my point. `ls` and `find` are "supposed to be" POSIX `ls` and `find`. Obviously on a GNU system one can't just drop the GNU extensions, but what Rust Coreutils is fighting is (IIUC) to a large extent the goal of becoming bug-compatible, or unspecified-compatible. For unspecified-compatible, to support users who relied on it (Hyrum's law), the same case could be made that lots of people relied on /bin/sh being bash. dash may not have been aiming to be drop-in replacement for bash, but when OS vendors change /bin/sh to dash, what's the difference?
    - NekkoDroid 10mo ago
      > Well that's kind of my point. `ls` and `find` are "supposed to be" POSIX `ls` and `find`. I don't know about that, I at least wouldn't 100% agree on that. Mostly since POSIX only defines short args it kinda makes just not want to use them, since I like to spell out the long arg in scripts for clarity. So by default I just assume I am using GNU coreutils (since BSD coreutils have slightly different names in some places IIRC). And since there isn't such a destinction between "POSIX coreutils" and "GNU coreutils" like there is with "POSIX shell" (sh) and "bash" I wouldn't call the situations equivalent.
- pseudalopex 10mo ago
  Ubuntu made /bin/sh dash in 2006 according to Wikipedia. Many fewer people used Ubuntu then.