@toast it’s cool but has a bunch of pitfalls if you’re not careful

i.e. people using printf and letting the format-string be user controlled

thankfully -v can only be the first argument, so you can’t accidentally let an attacker write to an arbitrary variable… rare case when the posix parameter order actually helps

(do note: i’m in the 0.1% of shell scripters who even consider it to be a “security boundary” of any sort because of httpsh, so i’m firmly an outlier and i shoudl not have been counted)

@domi @toast i got so confused for a while, checked the posix and coreutils manpage, got even more confused

then checked the bash manpage, and then it made sense

now i wonder why did bash add printf -v var when we had var=$(printf) =w= maybe some edge case i can’t think of

@navi @toast subshells! $() spawns another process, which adds a bunch of overhead, and changes scoping (which can cause issues - it’s very rare, but i’ve encountered cases where printf -v was the only way to assign a variable

btw: modern bash supports ${echo asdf}, which acts exacly the same as $(echo asdf) except it does some magic behind the scenes to not spawn a subshell

@domi @toast yea i’m aware of subshells

but also there’s no actual reason a shell couldn’t see that a certain command doesn’t cause side effects, then just posix_spawn() things directly, doesn’t even seem too hard to implement if you keep track of your “env-altering” builtins

(also yes ${... ;} it’s useful but a) i hate how it has the same syntax as variable expansion and b) you need to end with the semi-colon iirc due to (a))

@navi @toast yeah you need the semicolon and load-bearing spaces ^^ you can tell i haven’t used this one much because I forgor

the variable assignment thing is an unfortunate side-effect… there’s a bunch of shell features I would write differently if I were designing them myself. maybe one day ;)