8 ms·
Posix.1-2024 is published
- stephenr 2y agoI wonder how long till https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/ has the new revision.
- a-french-anon 2y agoSome goodies for POSIX sh programmers: * readlink/realpath (https://austingroupbugs.net/view.php?id=1457 https://austingroupbugs.net/view.php?id=1457) * find -print0, xargs -0 and read -d (https://austingroupbugs.net/view.php?id=243 https://austingroupbugs.net/view.php?id=243) * find -iname (https://austingroupbugs.net/view.php?id=1031 https://austingroupbugs.net/view.php?id=1031 * sed -E (https://austingroupbugs.net/view.php?id=528 https://austingroupbugs.net/view.php?id=528) * set -o pipefail (https://austingroupbugs.net/view.php?id=789 https://austingroupbugs.net/view.php?id=789)
- clausecker 2y agoAlso 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.
- a-french-anon 2y agoasprintf is a pretty cool one. https://frippery.org/make/2024.html https://frippery.org/make/2024.html details some of the make changes.
- thechao 2y agoasprintf 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!
- tedunangst 2y agoHow many other posix functions take allocators?
- cperciva 2y agoc17 -G to create shared objects Finally! It always seemed very strange to me that posix said that shared objects were a thing and provided a rtld API for using them, but never specified how to create them.
- nwellnhof 2y agoI'm most excited about getentropy().
- dwheeler 2y agoI 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 other places.
- stephenr 2y agoThanks, those will indeed be useful. Looks like `pipefail` is already in Dash https://salsa.debian.org/debian/dash/-/blame/debian/unstable/debian/changelog?ref_type=heads#L24 https://salsa.debian.org/debian/dash/-/blame/debian/unstable...
- EuAndreh 2y agowow, 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!
- dwheeler 2y agoThanks so much, that means a lot.
- casey2 2y agoI 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
- jwilk 2y agoAlso $'…' strings: https://austingroupbugs.net/view.php?id=249 https://austingroupbugs.net/view.php?id=249
- mathfailure 2y agoBut `find -iname` always worked; why was it proposed again?
- BoingBoomTschak 2y ago??? It wasn't standardized before, so it didn't "always work" on any implementation.
- carterschonwald 2y agoIs there a changelog for these standards?
- diggan 2y agoNot 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 https://en.wikipedia.org/wiki/POSIX#Versions (but doesn't seem to have info on POSIX.1-2024 yet)
- crote 2y agoI 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.
- LegionMammal978 2y agoThough 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.
- jwilk 2y ago
- mike_hock 2y agoSo, what's new?
- deleted 2y ago[deleted]
- susam 2y agoI am hoping this appears at https://pubs.opengroup.org/onlinepubs/9699919799/ 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/V3_chap02.html 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.
- thomashabets2 2y agoI make a habit to always quote strings with "${a?}". That way a typo variable won't blindly go ahead and do the wrong thing.
- dveeden2 2y agoWhere 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?
- susam 2y ago> 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 https://packages.debian.org/stable/dash
- throw0101d 2y ago> 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 scripts to conform to POSIX shell. Or explicitly use bash in your shebang. One of the problems with Bash is that it insists on doing bash-y things even when you tell it to act like sh. People ask why you should write (or at least test) code to be multi-platform (even the basics of running it on BSD or macOS): it's because it forces you to be honest. Things change and initial assumptions may not be the same forever. * https://wiki.debian.org/Shell https://wiki.debian.org/Shell * https://archlinux.org/packages/?name=checkbashisms https://archlinux.org/packages/?name=checkbashisms * https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh
- koolala 2y agowasm support?
- Jtsummers 2y agoWhat would it even mean for an interface description to "support" WASM which is a (virtual) machine target for implementations?
- koolala 2y agowebrtc, ws, postmessage?
- koolala 2y agoircv3 did it
- eqvinox 2y agoWith all due respect, you don't seem to understand what POSIX is.
- koolala 2y agoI appreciate your respect. Can you contrast POSIX with IRC and explain why IRC can work on the web but POSIX can't? https://ircv3.net/specs/extensions/websocket https://ircv3.net/specs/extensions/websocket
- deleted 2y ago[deleted]
- eqvinox 2y agoYour question fundamentally makes no sense; POSIX is not a protocol, it is an operating system interface definition. It describes the OS foundations which you can then build websockets, IRC, a web browser, a calculator, compilers, local login prompts, {python,ruby,...) interpreters, etc. on top of. Your question is analog to "why can't {Windows,Android} work on the web?"
- ykonstant 2y agoDid we get `local`?
- ko1nksm 2y agoNo. https://www.austingroupbugs.net/view.php?id=767 https://www.austingroupbugs.net/view.php?id=767
- a-french-anon 2y agoSadly no. That's one of the few things that can't be done with, but semantics can subtly vary between implementation. Which is why I do a runtime check for them: https://git.sr.ht/~q3cpma/scripts/tree/b4b3c62f6a77828d0c445a3d8e47df216355ec63/item/util.sh#L6 https://git.sr.ht/~q3cpma/scripts/tree/b4b3c62f6a77828d0c445...
- alganet 2y agoJust use: if command -v command >/dev/null 2>&1 then command -v local >/dev/null 2>&1 || alias local=typeset fi eval "__fn=;__fn(){ local __fn=leak;};__fn || :;" if test -n "$__fn" then echo local leaks here! fi It will not crash on posh because I'm being tricky with eval and command. posh supports local variable scope. The only shell partially missing local support is ksh, but it has a gotcha. It works if the function is declared with the `function` keyword. All you have to do is use ksh's own tools to redeclare all functions automatically: __list=$(typeset +f) IFS="$__eol" # __eol should have a line break for __decl in $__list do __name=${__decl%" #"*} __name=${__name%"()"} __body="$(typeset -f "$__name" || :)" eval "function $__name ${__body#"$__decl"}" done IFS=" " Of course, for this to work, all functions must be loaded before running and any declared after the fix will not be local, which is a good idea anyway. I always put the alias polyfill on the header of my library and the eval/for polyfill just before invoking my main function. There is still an inconsistency with default local values. To get the same behavior everywhere, always initialize local variables THIS IS FINE: local foo=; local foo=bar; THIS CAN INHERIT WEIRD STUFF: local foo; Done, you have portable bourne sh scope everywhere imaginable.
- tiffanyh 2y agoThe PDF is behind a login wall :(
- colinsane 2y agodead 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?
- blueflow 2y agoLeak when?
- kazinator 2y agoWonder how long before it appears in https://pubs.opengroup.org/onlinepubs/ https://pubs.opengroup.org/onlinepubs/
- mathfailure 2y agoStill no arrays in the standard? GTFO.