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

51–60 of 87 posts

Re: Posix.1-2024 is published

#51

Post by unnah »

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…

That's also one of the more notable incompatibilities of zsh - by default it treats $a the same as "$a", and you're supposed to use arrays if you want multiple words. Although I'm not an expert - maybe ysh and zsh differ in the details here?

Re: Posix.1-2024 is published

#52

Post by matrss »

ko1nksm wrote: post #49
matrss wrote: post #44

Earlier quoted context omitted.

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.

Oh wow, I didn't know that. I am pretty sure I had a sh trip up on it just recently, so I thought it still was bash only. Yes, use it everywhere possible.

Re: Posix.1-2024 is published

#53

Post by matrss »

cesarb wrote: post #50
matrss wrote: post #44

Earlier quoted context omitted.

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

I find it to be a good default when writing a script, but yes, it can get noisy and potentially leak stuff, if that is what your script deals with. That hasn't been a concern in the settings I usually use it, though.

I am not sure how it could break anything though, unless you are parsing stderr of your script in a subsequent step, which would seem unusual anyway.

Re: Posix.1-2024 is published

#54

Post by _7tgr »

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

Prefer `#!/usr/bin/env bash` instead, since /bin/bash isn't a standardized location for bash (even across Linux distros). The former causes $PATH to be searched for bash.

Re: Posix.1-2024 is published

#55

Post by tommiegannert »

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.

Oh, it seems set -u was fixed with regards to arrays in 2011 or so: https://stackoverflow.com/questions/7577052/unbound-variable...

Maybe I can start using it again. (I think I noticed that issue while I was at Google, and they used an older version of Bash.)

Re: Posix.1-2024 is published

#56

Post by chubot »

unnah wrote: post #51
chubot wrote: post #36

Earlier quoted context omitted.

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…

That's also one of the more notable incompatibilities of zsh - by default it treats $a the same as "$a", and you're supposed to use arrays if you want multiple words. Although I'm not an expert - maybe ysh and zsh differ in the details here?

Yup, in terms of ls $a -- YSH happens to be like zsh. OSH is compatible with bash and does the POSIX word splitting, but YSH is not.

In general YSH is pretty different than zsh though -- it's more of a Python- JS-like language with structured data, e.g.

    ysh$ var a = ['list', 'of' strings']
    ysh$ write -- @a
    list
    of
    strings
In zsh I still think that's the pretty obscure "${a[@]}" rather than @a.

Arrays are also "flat" in zsh -- you can't have an array of arrays, because there's no garbage collector. But YSH has arbitrarily nested JSON-like data structures, and JSON serialization built in.

I need to put some code examples on the home page, but for now - https://www.oilshell.org/release/latest/doc/ysh-tour.html

Re: Posix.1-2024 is published

#57

Post by EuAndreh »

dwheeler wrote: post #26
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 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…

wow, I just realized you're the same dwheeler from the work on diverse double-compilation!

Thanks for the improvements on POSIX, I've read many issues and discussions raised by you in the past couple of years.

If fact, I think it was one of yoir comments on make(1)'s dynamic dependency graph that reassured me I had a correct grasp on its execution model!

Re: Posix.1-2024 is published

#58

Post by arp242 »

unnah wrote: post #51
chubot wrote: post #36

Earlier quoted context omitted.

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…

That's also one of the more notable incompatibilities of zsh - by default it treats $a the same as "$a", and you're supposed to use arrays if you want multiple words. Although I'm not an expert - maybe ysh and zsh differ in the details here?

You can use $=a to get word splitting in zsh.

While incompatible, the zsh behaviour makes a lot more sense.

You can use "setopt sh_word_split" to get the POSIX behaviour.

Or split explicitly with ${(s: :)a}, ${(s:SPLIT-ON-THIS:)a}, etc. (not compatible with anything but zsh).

Re: Posix.1-2024 is published

#59

Post by colinsane »

tiffanyh wrote: post #16

The PDF is behind a login wall :(

dead on arrival as far as i'm concerned.

i guess the parts of the ecosystem low enough to care about things like POSIX compliance are mostly attached to some foundation or other, so maybe those foundations will purchase copies for their core maintainers? but that's a pretty counter-intuitive thing. i wonder if there are large closed-source POSIX implementors out there that this is aimed at, but are there really enough closed-source implementations out there for any of them to care about compatibility with eachother?

Re: Posix.1-2024 is published

#60

Post by Maledictus »

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 prefer set -Eeuxo pipefail, so my ERR trap is inherited in functions.
Post reply on HN