Posix.1-2024 is published

a-french-anon wrote: post #3

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.

Re: Posix.1-2024 is published

#6

Post by mike_hock » Fri, Jun 14, 2024, 2:21 PM UTC

So, what's new?

Re: Posix.1-2024 is published

#7

Post by diggan » Fri, Jun 14, 2024, 2:25 PM UTC

carterschonwald wrote: post #4

Is there a changelog for these standards?

Not an official one, as far as I'm aware. Maybe the Wikipedia article is the best resource for that right now: https://en.wikipedia.org/wiki/POSIX#Versions (but doesn't seem to have info on POSIX.1-2024 yet)

Re: Posix.1-2024 is published

#8

Post by susam » Fri, Jun 14, 2024, 2:25 PM UTC

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 specification here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

For example, if

  a="foo bar"

then

  ls $a

will split the value into two fields (thus two arguments to ls). Of course we should surround $a with double-quotes to avoid the field splitting. However the following is fine:

  case $a in

No field splitting occurs here. However, to be kind to your code reviewer, you might want to double-quote this anyway for the sake of simplicity and consistency. Behaviour like this is specified in sections "Field Splitting" and "Case Conditional Construct" of the aforementioned link. Specification documents like this were formative in in my journey toward learning to write shell scripts confidently.

Re: Posix.1-2024 is published

#9

Post by dveeden2 » Fri, Jun 14, 2024, 2:32 PM UTC

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 and/or iOS fully POSIX compliant?

Any good blog or presentation describing the current state of POSIX?

Re: Posix.1-2024 is published

#10

Post by crote » Fri, Jun 14, 2024, 2:35 PM UTC

carterschonwald wrote: post #4

Is there a changelog for these standards?

I keep getting surprised at how little the tech industry as a whole seems to care about documentation. Way too many authors just upload the new PDF to some website - of course overwriting the old one.

As an implementer I'm often more interested in the exact changes than in the current wording. My product is already supporting the old spec, what do I need to change to support the new one? A redlined version is more valuable than the full PDF. Bonus points if it actually comes with the reasoning behind it so I don't have to guess why some seemingly-arbitrary change was made.

My dream documentation is a simple Markdown file (or similar) stored in a git repository. It allows me to see the current version, the old version, the diff, and the commit messages can even store the reasoning.