Earlier quoted context omitted.
ircv3 did it
With all due respect, you don't seem to understand what POSIX is.
I appreciate your respect. Can you contrast POSIX with IRC and explain why IRC can work on the web but POSIX can't?
Posix.1-2024 is published
61–70 of 87 posts
Re: Posix.1-2024 is published
#62Earlier quoted context omitted.
set -o pipefail is now POSIX compliant. Use it in all POSIX shell scripts, not just bash scripts.
Oh wow, I didn't know that. I am pretty sure I had a sh trip up on it just recently, so I thought it still was bash only. Yes, use it everywhere possible.
Emphasis on now - it's new in this version, so probably expect a little bit of delay before it's actually available everywhere. But yes, excellent addition and I'm happy to have it available more broadly now.
Re: Posix.1-2024 is published
#63The PDF is behind a login wall :(
Leak when?
Re: Posix.1-2024 is published
#64Re: Posix.1-2024 is published
#65Earlier quoted context omitted.
What would it even mean for an interface description to "support" WASM which is a (virtual) machine target for implementations?
webrtc, ws, postmessage?
Those aren't part of Wasm. WebRTC and WebSockets both predate Wasm by 6 years, and neither require Wasm to work. postMessage is part of Web Workers, also separate frow Wasm.
I'll ask again, what would it mean for POSIX to "support" Wasm?
Re: Posix.1-2024 is published
#66Earlier quoted context omitted.
The original discussion on why Debian switched from bash to dash for /bin/sh is insightful. https://lwn.net/Articles/343924/ One big factor is for performance reasons in shell scripts. At the time, the switch decreased boot times for Debian by 7.5%. Bourne shell features add a lot of overhead and that's not always an acceptable tradeoff. Also, if you're using bash features in a script, you can always just add #!/bin/…
Prefer `#!/usr/bin/env bash` instead, since /bin/bash isn't a standardized location for bash (even across Linux distros). The former causes $PATH to be searched for bash.
Is /usr/bin/env a standardized location?
Re: Posix.1-2024 is published
#67Earlier quoted context omitted.
The original discussion on why Debian switched from bash to dash for /bin/sh is insightful. https://lwn.net/Articles/343924/ One big factor is for performance reasons in shell scripts. At the time, the switch decreased boot times for Debian by 7.5%. Bourne shell features add a lot of overhead and that's not always an acceptable tradeoff. Also, if you're using bash features in a script, you can always just add #!/bin/…
Prefer `#!/usr/bin/env bash` instead, since /bin/bash isn't a standardized location for bash (even across Linux distros). The former causes $PATH to be searched for bash.
This is pretty common advice but I think it is fighting the previous war. This idea is useful for virtualenv-type tricks if you want to ensure use of your personal version of the interpreter on a shared system, but you have to boil an ocean of scripts. You don't know if you caught them all. Docker won instead - a quick filesystem namespace comprehensively catches everything. Just use #!/bin/bash.
EDIT: I was thinking about Linux, but I suppose macOS users are stuck with needing this for Homebrew-supplied bash?
Re: Posix.1-2024 is published
#68Where is POSIX actually useful today? Is it mostly for shell scripts? Aren't people targetting bash or basic bourne shell features intead of posix? Is shellcheck checking for best practices instead of POSIX compliance? And for other applications (GUI, servers, etc) strict POSIX compliance might be too restrictive? And with many things being Linux (or Linux-like like WSL) the need for this might be less? Are Android a…
I’m probably going to be downvoted for this, but anyway: the single unix specification has always been the only place where i could find C headers documentation in by header file.
Meaning: i don’t want to know all the 6000 functions glibc support, i want to know what will (for example) net/inet.h will bring to my code (ideally with documentation).
For sonme reason that doesn’t seem to be a thing. Not for glibc for sure. But the SUS does that. And i like it.
Re: Posix.1-2024 is published
#69Where is POSIX actually useful today? Is it mostly for shell scripts? Aren't people targetting bash or basic bourne shell features intead of posix? Is shellcheck checking for best practices instead of POSIX compliance? And for other applications (GUI, servers, etc) strict POSIX compliance might be too restrictive? And with many things being Linux (or Linux-like like WSL) the need for this might be less? Are Android a…
> Where is POSIX actually useful today?
Every now and again, I get annoyed by those cases where Linux has some API/utility/etc but macOS doesn't. Getting that API/utility into POSIX greatly increases the odds that Apple will end up implementing it. (Whether just by copying it from FreeBSD, or by writing it themselves.)
Re: Posix.1-2024 is published
#70Wonder how long before it appears in https://pubs.opengroup.org/onlinepubs/