Live data from Hacker News

Posix.1-2024 is published

ieeexplore.ieee.org

11–20 of 87 posts

Re: Posix.1-2024 is published

#11

Some 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.

asprintf is a pretty cool one. https://frippery.org/make/2024.html details some of the make changes.

Re: Posix.1-2024 is published

#12
post #9

Where 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 (dash). It is a POSIX-compliant shell derived from ash. 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 system scripts to conform to POSIX shell. Although shellcheck cannot perform full POSIX compliance check at this time, it is still a pretty good tool that can help with checking compliance with dash in particular.

[1]: https://packages.debian.org/stable/dash

Re: Posix.1-2024 is published

#13
post #8

I 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…

The note on the front page of the Austin Groups' website says as much with regards to publication:

> June 14, 2024: IEEE Std 1003.1-2024 has been published by IEEE. The Open Group Base Specifications, Issue 8 has been published by The Open Group. At this stage only PDF is available. The HTML edition to follow soon.

https://www.opengroup.org/austin/

Re: Posix.1-2024 is published

#18

Some 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.

asprintf is a nice toy, but it should really take a context and a "realloc" function pointer to be useful, in general. Here's hoping for 2040!

Re: Posix.1-2024 is published

#19
post #8

I 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

Post reply on HN