Earlier 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?
ircv3 did it
Posix.1-2024 is published
21–30 of 87 posts
Re: Posix.1-2024 is published
#22Did we get `local`?
Re: Posix.1-2024 is published
#23I am hoping this appears at https://pubs.opengroup.org/onlinepubs/9699919799/ soon. This is the link I use most often to go through the specification. In fact, I owe a lot of my shell scripting skills to this online resource. As a specific example, the seemingly simple matter of when the shell decides to split a string based on $IFS and when it does not were quite confusing to me until I went through the specificatio…
> However the following is fine: > > case $a in > > No field splitting occurs here This kind of bullshit is how I made a career rewriting people's buggy shell scripts in Python
Wow, no kidding. I’ve been writing little shell scripts to do random things for literally decades and this is the first time I heard about it.
I also rewrite my stuff in Python as soon as it becomes nontrivial.
Re: Posix.1-2024 is published
#24Where 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’ve wondered the same. The most common standard I’ve seen in everyday work for a long time now is “runs on my Mac and the Linux server we’re deploying to”.
I’m not talking about shops that ship software that customers receive and install on prem on their HPUX or whatever. That’s still a thing and people have to take that into account. I’m grateful I’m no longer among them.
Re: Posix.1-2024 is published
#25Where 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…
> Aren't people targetting bash or basic bourne shell features intead of posix? I know many banks still have AIX systems with shells like ksh89, ksh93, etc. as the default shell. So if a shell script is written to work with a POSIX shell (instead of a particular shell), it has a better chance of running on such systems. Also, on Debian, the default non-interactive shell is dash [1]. This is the Debian Almquist Shell…
> So again, if we write system scripts for Debian and want it to run on Debian without any hassle, it makes sense to write the scripts to conform to POSIX shell.
Or explicitly use bash in your shebang.
One of the problems with Bash is that it insists on doing bash-y things even when you tell it to act like sh.
People ask why you should write (or at least test) code to be multi-platform (even the basics of running it on BSD or macOS): it's because it forces you to be honest. Things change and initial assumptions may not be the same forever.
* https://wiki.debian.org/Shell
Re: Posix.1-2024 is published
#26Some goodies for POSIX sh programmers: * readlink/realpath ( https://austingroupbugs.net/view.php?id=1457 ) * find -print0, xargs -0 and read -d ( https://austingroupbugs.net/view.php?id=243 ) * find -iname ( https://austingroupbugs.net/view.php?id=1031 * sed -E ( https://austingroupbugs.net/view.php?id=528 ) * set -o pipefail ( https://austingroupbugs.net/view.php?id=789 )
I agree! You can blame me for some of those proposals :-), my thanks to the POSIX team for getting this out the door.
The sed -E option makes it easy to portably use extended regular expressions.
The find -print0, xargs -0, and read -d provide portable ways to securely process lists of files. They were already widely implemented, but now they're officially part of the spec and can be counted on being present in many other places.
Re: Posix.1-2024 is published
#27Where 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…
> Aren't people targetting bash or basic bourne shell features intead of posix? I know many banks still have AIX systems with shells like ksh89, ksh93, etc. as the default shell. So if a shell script is written to work with a POSIX shell (instead of a particular shell), it has a better chance of running on such systems. Also, on Debian, the default non-interactive shell is dash [1]. This is the Debian Almquist Shell…
Bash has `Priority: required` and is marked as "essential", it's available on every Debian system.
Re: Posix.1-2024 is published
#28Where 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…
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/bash to the top of your file instead of #!/bin/sh to force a bash compatible shell.
Re: Posix.1-2024 is published
#29Some goodies for POSIX sh programmers: * readlink/realpath ( https://austingroupbugs.net/view.php?id=1457 ) * find -print0, xargs -0 and read -d ( https://austingroupbugs.net/view.php?id=243 ) * find -iname ( https://austingroupbugs.net/view.php?id=1031 * sed -E ( https://austingroupbugs.net/view.php?id=528 ) * set -o pipefail ( https://austingroupbugs.net/view.php?id=789 )
Also c17 -G to create shared objects, SIGWINCH and tcgetwinsize() to query the size of a terminal window, lots of new shell features, make is now somewhat useful, gettext() and associated commands are in, asprintf(), C17 support, strlcpy, strlcat, and many more all new and exciting features.
c17 -G to create shared objects
Finally! It always seemed very strange to me that posix said that shared objects were a thing and provided a rtld API for using them, but never specified how to create them.
Re: Posix.1-2024 is published
#30Did we get `local`?
Sadly no. That's one of the few things that can't be done with, but semantics can subtly vary between implementation. Which is why I do a runtime check for them: https://git.sr.ht/~q3cpma/scripts/tree/b4b3c62f6a77828d0c445...