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

71–80 of 87 posts

Re: Posix.1-2024 is published

#71

Post by kazinator »

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…

This is old hat though; I think it was already specified that way in 1990 POSIX.

Re: Posix.1-2024 is published

#72

Post by eqvinox »

koolala wrote: post #61
eqvinox wrote: post #37

Earlier quoted context omitted.

With all due respect, you don't seem to understand what POSIX is.

I 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

Your 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?"

Re: Posix.1-2024 is published

#73

Post by _7tgr »

mappu wrote: post #67
_7tgr wrote: post #54

Earlier quoted context omitted.

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.

This is pretty common advice but I think it is fighting the previous war. This idea is useful for virtualenv-type tricks if you want to ensure use of your personal version of the interpreter on a shared system, but you have to boil an ocean of scripts. You don't know if you caught them all. Docker won instead - a quick filesystem namespace comprehensively catches everything. Just use #!/bin/bash. EDIT: I was thinking…

#!/bin/bash won't work on, say, nixos, and as you noted, many non-linux platforms. It's a few more characters to do something (more) portable! You're right that docker (or something like nix flakes, which are lighter-weight/easier to introspect imo) are probably a better solution in the long run, though.

Re: Posix.1-2024 is published

#74

Post by _7tgr »

n_plus_1_acc wrote: post #66
_7tgr wrote: post #54

Earlier quoted context omitted.

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.

Is /usr/bin/env a standardized location?

I don't know, but it's been more reliable for me than /bin/bash. I think env is part of POSIX.

Re: Posix.1-2024 is published

#75

Post by ko1nksm »

n_plus_1_acc wrote: post #66
_7tgr wrote: post #54

Earlier quoted context omitted.

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.

Is /usr/bin/env a standardized location?

No. No new locations added in POSIX.1-2024.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

POSIX omits from standardisation what is not necessary for an application to work, so that a wide range of systems can be supported. As for Shebang, it can be rewritten in the installation script and is therefore considered an area of system administration.

Re: Posix.1-2024 is published

#76

Post by ko1nksm »

throw0101d wrote: post #25
susam wrote: 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…

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

> One of the problems with Bash is that it insists on doing bash-y things even when you tell it to act like sh.

Its behaviour is a common behaviour of all sh, not just Bash.

Re: Posix.1-2024 is published

#77

Post by PhilipRoman »

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…

Embedded shell scripts typically end up targeting the common denominator of bash/BusyBox/coreutils but the POSIX standards are a pretty good reference too. People often don't realize this, but standards are useful even if they aren't implemented 100% fully and correctly.

Re: Posix.1-2024 is published

#78

Post by alganet »

a-french-anon wrote: post #30
ykonstant wrote: post #15

Did we get `local`?

Sadly 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/b4b3c62f6a77828d0c445...

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

Re: Posix.1-2024 is published

#80

Post by koolala »

Jtsummers wrote: post #65
koolala wrote: post #20

Earlier quoted context omitted.

webrtc, ws, postmessage?

Those aren't part of Wasm. WebRTC and WebSockets both predate Wasm by 6 years, and neither require Wasm to work. postMessage is part of Web Workers, also separate frow Wasm. I'll ask again, what would it mean for POSIX to "support" Wasm?

A standard document defining how it could work on the web. Wasm is literally just Javascript.
Post reply on HN