6 ms·

Does anyone care about the standard? Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generall

Does anyone care about the standard? Let's be honest it's outdated, has a bad UX and is with the standards I would hold such a standard against today generally not so good. Sure systems seen try to somewhat be POSIX compliance but from my experience not because they care about POSIX but because that happen to overlap with the idea to be somewhat compiland with other similar systems so that porting software/scripts is easier. So if the systems you use support long options for POSIX commands go ahead and use them. Furthermore if the command you can are not in the standard anyway you again can use long options because they are as much standard as the short ones. Let's be honest this leaves very little use-cases where long options are a problem.

kazinator 6y ago
Last published in 2018 (and actively being worked on) is not outdated. https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/ > Sure systems seen try to somewhat be POSIX compliance The mainstream systems you know and use adhere very rigorously to POSIX. GNU Libc, Kernel, Coreutils, ... and their counterparts in BSD Unixes, proprietary Unixes, Cygwin and whatnot all take POSIX seriously. POSIX is very helpful, and smart coders and sysadmins use it as one of their references for required behavior.
- chubot 6y ago
  Larry Wall said It's easier to port a shell than a shell script in 1998 ... 22 years later I still think that holds. https://news.ycombinator.com/item?id=10104203 https://news.ycombinator.com/item?id=10104203 Although I would agree that there's a slight hole there: you still need to port stuff like coreutils and all the dependencies, which has been done of course. But I'd be happier if something like busybox was actually portable.
  - kazinator 6y ago
    I think it's easier to write a portable shell script today than 30 years ago. The Autoconf system is predicated on the idea that writing a portable shells script is hard, and so we hide the shell programming behind a mountain of M4 macros. It's not necessarily easier to port a shell script today than 22 years ago, which was not written with portability in mind. There are more shells with more extensions, and then beyond the language concerns, and the environments have exploded. A shell script can easily depend on all sorts of cruft you've never heard of. Oh, just install these five things from the following github repos ...
samtheprogram 6y ago
Yes, if you care about portability. Anything that's not Linux likely won't have GNU grep installed by default. This includes macOS and the BSDs. If this is your own dotfiles or utilities, sure, but if I'm working on something collaborative, yes, I care about the standard.
- saagarjha 6y ago
  I stick to POSIX in my dotfiles precisely because I carry it around on many different systems and that’s the only thing that can keep it sane.
  - samtheprogram 6y ago
    Same here — I felt it would detract from the point I was trying to make so I didn’t mention it, especially since I don’t think most people run multiple OS’s :) At the least though, I would assume people regularly have collaborators that run different OS’s.
- dathinab 6y ago
  If I would create something which needs that degree of portability I would never use a shell script. It's just way too easy to run into a unexpected gotcha on some platform/configuration.
chubot 6y ago
Yeah I agree with this. I claimed a few years ago that you could view https://www.oilshell.org/ https://www.oilshell.org/ as a "better POSIX", and I still hold that view. http://www.oilshell.org/blog/2018/01/28.html#limit-to-posix http://www.oilshell.org/blog/2018/01/28.html#limit-to-posix Recent comment about this: https://news.ycombinator.com/item?id=24428347 https://news.ycombinator.com/item?id=24428347 POSIX is just too limited and not what people use in practice. If you want a portable shell script, in many cases my (biased) advice would be to make your script work on both bash and Oil. (Obviously there are short shell scripts which you may want to run on BSD, etc. This is more about big scripts, which POSIX falls down for.) Oil already runs some of the biggest shell scripts in the world, many of them unmodified. Moreoever, when there's a patch necessary to run it, it often IMPROVES the program. http://www.oilshell.org/blog/2020/06/release-0.8.pre6.html#patch-to-run-the-mal-lisp http://www.oilshell.org/blog/2020/06/release-0.8.pre6.html#p... You'll be less tied to the vagaries of bash. If anyone's script doesn't run under Oil, I'm interested. See https://github.com/oilshell/oil/wiki/What-Is-Expected-to-Run-Under-OSH https://github.com/oilshell/oil/wiki/What-Is-Expected-to-Run...
ridiculous_fish 6y ago
fish shell has been burned in the few places it strictly implements POSIX. The most vivid example is test, aka /bin/[. POSIX specifies that, if test is invoked with one argument, you must "Exit true (0) if $1 is not null; otherwise, exit false" [1]. This means that `test --help` is forbidden from printing any help. It means that `test -d $argv` expands to `test -d` if $argv is empty, which then must "succeed" because "-d" is not null. It bites users over and over again [2]. Implementing this POSIX piece has resulted in more headaches, not fewer. I regret implementing a POSIX-conformant test, I wish I had just picked mostly-compatible but also-sane semantics. 1: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/t... 2: https://stackoverflow.com/questions/29635083/fish-shell-check-if-argument-is-provided-for-function/34221866 https://stackoverflow.com/questions/29635083/fish-shell-chec...
- a1369209993 6y ago
  > It means that `test -d $argv` expands to `test -d` if $argv is empty, which then must "succeed" because "-d" is not null. It bites users over and over again [2]. To be fair, while the POSIX behaviour is obviously wrong, using `$argv` on a bourne-style shell[0] is also wrong; that should be either `test -d "$argv"` or (if I recall the syntax correctly) `test -d "${argv[@]}"` if you actually intended argv to be a list rather than a single directory ("argv" suggests the former, but `test -d X` only accepts a single argument). 0: more specifically, a shell that does word splitting at the wrong place (after parameter expansion)

kazinator 6y ago

Last published in 2018 (and actively being worked on) is not outdated. https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/ > Sure systems seen try to somewhat be POSIX compliance The mainstream systems you know and use adhere very rigorously to POSIX. GNU Libc, Kernel, Coreutils, ... and their counterparts in BSD Unixes, proprietary Unixes, Cygwin and whatnot all take POSIX seriously. POSIX is very helpful, and smart coders and sysadmins use it as one of their references for required behavior.

chubot 6y ago
Larry Wall said It's easier to port a shell than a shell script in 1998 ... 22 years later I still think that holds. https://news.ycombinator.com/item?id=10104203 https://news.ycombinator.com/item?id=10104203 Although I would agree that there's a slight hole there: you still need to port stuff like coreutils and all the dependencies, which has been done of course. But I'd be happier if something like busybox was actually portable.
- kazinator 6y ago
  I think it's easier to write a portable shell script today than 30 years ago. The Autoconf system is predicated on the idea that writing a portable shells script is hard, and so we hide the shell programming behind a mountain of M4 macros. It's not necessarily easier to port a shell script today than 22 years ago, which was not written with portability in mind. There are more shells with more extensions, and then beyond the language concerns, and the environments have exploded. A shell script can easily depend on all sorts of cruft you've never heard of. Oh, just install these five things from the following github repos ...

samtheprogram 6y ago

Yes, if you care about portability. Anything that's not Linux likely won't have GNU grep installed by default. This includes macOS and the BSDs. If this is your own dotfiles or utilities, sure, but if I'm working on something collaborative, yes, I care about the standard.

saagarjha 6y ago
I stick to POSIX in my dotfiles precisely because I carry it around on many different systems and that’s the only thing that can keep it sane.
- samtheprogram 6y ago
  Same here — I felt it would detract from the point I was trying to make so I didn’t mention it, especially since I don’t think most people run multiple OS’s :) At the least though, I would assume people regularly have collaborators that run different OS’s.
dathinab 6y ago
If I would create something which needs that degree of portability I would never use a shell script. It's just way too easy to run into a unexpected gotcha on some platform/configuration.

chubot 6y ago

Yeah I agree with this. I claimed a few years ago that you could view https://www.oilshell.org/ https://www.oilshell.org/ as a "better POSIX", and I still hold that view. http://www.oilshell.org/blog/2018/01/28.html#limit-to-posix http://www.oilshell.org/blog/2018/01/28.html#limit-to-posix Recent comment about this: https://news.ycombinator.com/item?id=24428347 https://news.ycombinator.com/item?id=24428347 POSIX is just too limited and not what people use in practice. If you want a portable shell script, in many cases my (biased) advice would be to make your script work on both bash and Oil. (Obviously there are short shell scripts which you may want to run on BSD, etc. This is more about big scripts, which POSIX falls down for.) Oil already runs some of the biggest shell scripts in the world, many of them unmodified. Moreoever, when there's a patch necessary to run it, it often IMPROVES the program. http://www.oilshell.org/blog/2020/06/release-0.8.pre6.html#patch-to-run-the-mal-lisp http://www.oilshell.org/blog/2020/06/release-0.8.pre6.html#p... You'll be less tied to the vagaries of bash. If anyone's script doesn't run under Oil, I'm interested. See https://github.com/oilshell/oil/wiki/What-Is-Expected-to-Run-Under-OSH https://github.com/oilshell/oil/wiki/What-Is-Expected-to-Run...

ridiculous_fish 6y ago

fish shell has been burned in the few places it strictly implements POSIX. The most vivid example is test, aka /bin/[. POSIX specifies that, if test is invoked with one argument, you must "Exit true (0) if $1 is not null; otherwise, exit false" [1]. This means that `test --help` is forbidden from printing any help. It means that `test -d $argv` expands to `test -d` if $argv is empty, which then must "succeed" because "-d" is not null. It bites users over and over again [2]. Implementing this POSIX piece has resulted in more headaches, not fewer. I regret implementing a POSIX-conformant test, I wish I had just picked mostly-compatible but also-sane semantics. 1: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/t... 2: https://stackoverflow.com/questions/29635083/fish-shell-check-if-argument-is-provided-for-function/34221866 https://stackoverflow.com/questions/29635083/fish-shell-chec...

a1369209993 6y ago
> It means that `test -d $argv` expands to `test -d` if $argv is empty, which then must "succeed" because "-d" is not null. It bites users over and over again [2]. To be fair, while the POSIX behaviour is obviously wrong, using `$argv` on a bourne-style shell[0] is also wrong; that should be either `test -d "$argv"` or (if I recall the syntax correctly) `test -d "${argv[@]}"` if you actually intended argv to be a list rather than a single directory ("argv" suggests the former, but `test -d X` only accepts a single argument). 0: more specifically, a shell that does word splitting at the wrong place (after parameter expansion)