Live data from Hacker News

Posix.1-2024 is published

ieeexplore.ieee.org

31–40 of 87 posts

Re: Posix.1-2024 is published

#31
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…

> Where is POSIX actually useful today?

Defining a stable API to code against?

> And with many things being Linux (or Linux-like like WSL) the need for this might be less?

Define "being Linux". RHEL? Ubuntu? Other? Is /bin/sh linked to Bash or something?

* https://mywiki.wooledge.org/Bashism

* https://linux.die.net/man/1/checkbashisms

> Are Android and/or iOS fully POSIX compliant?

UNIX® Certified Products include macOS:

* https://www.opengroup.org/openbrand/register/

POSIX:

* https://posix.opengroup.org/register.html

Re: Posix.1-2024 is published

#32
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…

It's as good as any other standard: as a baseline of agreed-upon "correct" behavior for interoperability. Anything you add from there is gravy. It's more for implementers than users, e.g. for someone writing a new shell rather than writing shell scripts. Having the standard handy is also pretty useful when writing foreign interfaces, like the posix modules in python and perl.

As for the current state of POSIX, well, you're looking at it. Might find a blog or two of someone on the POSIX committees, but the organizations aren't the kind that keep blogs. Probably best to just dive into the Wikipedia article on POSIX and start following the references on the bottom. You'll probably want to look into SUS, the Single Unix Specification, as well: it's identical to POSIX (plus curses for some reason) but it's the label that OS vendors may use rather than POSIX. macOS and some Linux distributions claim to be fully SUS-compliant; Linux as a whole does not, because its official scope is limited to the kernel which only implements a subset of POSIX.

Fun fact: the name "POSIX" was coined by Richard Stallman.

Re: Posix.1-2024 is published

#33
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…

My view is that shell scripting feels like the wild-west, so I try to conform to POSIX to maintain some level of sanity, though it feels restrictive at times. I rely on ShellCheck to help me write shell scripts that are POSIX compliant.

Re: Posix.1-2024 is published

#34
post #28
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%. Bourne shell features add a lot of overhead and that's not always an acceptable tradeoff.

I seem to recall it was much smaller than that, something like 4% on a 2008 EEE-PC or something like that, but I can't find any numbers on that right now.

The Debian startup scripts were already POSIX; it's not hard to get better performance out of zsh or bash by avoiding expensive processes lookups.

Overall, I consider this to be mostly a myth, or at least extremely simplistic.

Re: Posix.1-2024 is published

#35
post #27
post #12

Earlier quoted context omitted.

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

Indeed, Bash is always available on Debian! After all, Debian uses Bash as the default interactive shell. But that's not the point of writing system scripts for dash. They are written for dash because that's still the default non-interactive shell. And it is so because dash is leaner and faster. Quoting from the link I posted in my previous comment:

> Since it executes scripts faster than bash, and has fewer library dependencies (making it more robust against software or hardware failures), it is used as the default system shell on Debian systems.

Re: Posix.1-2024 is published

#36
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 WORD SEQUENCE

This occurs in 2 places in POSIX shell:

   ls $x$y   # simple command is a sequence of words
 
   for i in $x$y; do echo $i; done  # for loop
And 1 place in bash:

   a=( $x$y )  # array literal
In these cases, the shell "wants" a sequence of strings, not a single one. So it does splitting.

---

(2) EVAL WORD TO STRING

But there are many other contexts where the shell does not "want" a sequence of strings.

It wants a SINGLE string. And conversely, it actually JOINS arrays of strings, rather than splitting.

Usually "$@" is an array / sequence of strings, while $@ or $* is a string, roughly speaking.

But the shell doesn't want sequences of strings in MANY cases, e.g.

    a=$@  # I only want 1 string here, so I JOIN rather than splitting

    echo hi > "$@"   # redirect arg (not all shells agree though!)

    case "$@" in ... esac  # as you point out

So the bottom line is that variables aren't really strings OR arrays of strings. Whatever the shell wants, it converts it to.

And shells also DISAGREE on the specifics of those rules. POSIX shell has the array "$@", but arrays in general are not in POSIX.

---

And even worse, think about this case:

   local x=$a
Does it behave like an assignment, which wants a single string?

Or does it behave like a simple command, which wants a sequence?

You can look at it both ways. The bottom line is that assignment builtins are special and they don't follow the normal rules of simple commands. Shells have differed, but POSIX decided on this awhile ago.

---

This is all of course mind numbing trivia that has no real reason for existing ... YSH fixes it, and it's now pure native C++, no more Python.

YSH Doesn't Require Quoting Everywhere - https://www.oilshell.org/blog/2021/04/simple-word-eval.html (Oil was renamed to YSH since this blog post was written)

Simple Word Evaluation in Unix Shell - https://www.oilshell.org/release/latest/doc/simple-word-eval...

In YSH you can tell just by looking it's a single string or an array.

    ls $a  # identical to ls "$a"

    ls @myarray  # splice an array
It never "molests" your variables. There's no auto-conversion, and you can upgrade to those rules with

    shopt --set ysh:upgrade

Re: Posix.1-2024 is published

#38

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

Thanks, those will indeed be useful. Looks like `pipefail` is already in Dash https://salsa.debian.org/debian/dash/-/blame/debian/unstable...

Re: Posix.1-2024 is published

#39
post #18

Earlier quoted context omitted.

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!

How many other posix functions take allocators?

Re: Posix.1-2024 is published

#40
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.
Post reply on HN