Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Posix.1-2024 is published

ieeexplore.ieee.org

Post reply on HN
Print view View original

41–50 of 87 posts

Re: Posix.1-2024 is published

#41

Post by LegionMammal978 »

crote wrote: post #10
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 va…

Though with a sufficiently-gnarly release history, even the Git repo might not tell the full story. I've recently been tracing the history of one particular library that's been around since the early 2000s, and hardly any of the versioned Git tags correspond exactly to the files in the released tarballs. Finding all the releases was quite tedious: the tarballs were published on multiple websites, some tarballs were updated in place (without changing the version number), one website (which held some versions exclusive to it) routinely deleted very old versions, and that website also no longer exists outside the Internet Archive. Overall, some of the releases have been totally lost to time, and the Git repo is of no help in reconstructing them.

Re: Posix.1-2024 is published

#43

Post by casey2 »

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 )

I for one am overjoyed that i can now type readlink instead of invoking a shell script. I know newbies will also be overjoyed now that they can just read a LLONG_MAX page manual containing the solution to all their problems

Re: Posix.1-2024 is published

#44

Post by matrss »

thomashabets2 wrote: post #40
susam wrote: 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…

I make a habit to always quote strings with "${a?}". That way a typo variable won't blindly go ahead and do the wrong thing.

I can recommend starting every bash script with

    set -euxo pipefail
The "u" has basically the same effect as the question mark, but for every variable usage.

Re: Posix.1-2024 is published

#45

Post by parasense »

chubot wrote: post #36
susam wrote: 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…

I think many people are even more surprised by this: x=$a # not split! It means the same thing as x="$a" They were taught that you have to quote everything, which is a reasonable rule to follow, but it's not true. --- I never wrote about this on the Oils blog ( https://www.oilshell.org/ ), but the post would be titled: Shell Has Context Sensitive Evaluation Basically the two contexts you should think of are: (1) EVAL…

Sometimes when I'm being lazy, say for example I have a variable with some folder/file absolute path... I'll convert the slashes to spaces, and word split there, sending the results into the stack.

    $ readarray -d '/'
and you get a nice list of folders you can push/pop as you wish...

Re: Posix.1-2024 is published

#46

Post by jwilk »

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 $'…' strings: https://austingroupbugs.net/view.php?id=249

Re: Posix.1-2024 is published

#47

Post by cesarb »

jjmarr wrote: post #28
dveeden2 wrote: 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…

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

> One big factor is for performance reasons in shell scripts. At the time, the switch decreased boot times for Debian by 7.5%.

And that should no longer be a relevant factor, since most of the boot process is now implemented directly in C (within systemd), instead of a bunch of shell scripts.

Re: Posix.1-2024 is published

#48

Post by jwilk »

crote wrote: post #10
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 va…

POSIX folks "have no plans to move to a public git repository for managing the development of the standard."

https://lore.kernel.org/linux-man/04801FEA-3560-4BA5-93EF-76...

Re: Posix.1-2024 is published

#49

Post by ko1nksm »

matrss wrote: post #44
thomashabets2 wrote: post #40

Earlier quoted context omitted.

I make a habit to always quote strings with "${a?}". That way a typo variable won't blindly go ahead and do the wrong thing.

I can recommend starting every bash script with set -euxo pipefail The "u" has basically the same effect as the question mark, but for every variable usage.

set -o pipefail is now POSIX compliant. Use it in all POSIX shell scripts, not just bash scripts.

Re: Posix.1-2024 is published

#50

Post by cesarb »

matrss wrote: post #44
thomashabets2 wrote: post #40

Earlier quoted context omitted.

I make a habit to always quote strings with "${a?}". That way a typo variable won't blindly go ahead and do the wrong thing.

I can recommend starting every bash script with set -euxo pipefail The "u" has basically the same effect as the question mark, but for every variable usage.

I do the same, except for the "x" (that is, "set -euo pipefail"); depending on what you're doing, "set -x" might be helpful, might be too much noise, or it could even break things which were not expecting the extra output (and in the worst case, it might end up echoing secret tokens into your build logs).
Post reply on HN