10:06 <sewn> dnkl: wiki patch: https://b.sewn.moe/uploads/sewn/0144bc76-0001-fix-posix-sh-spaces-and-use-local.patch

16:05 <dnkl> sewn: you contributed the original variant; why did you change it to use 'local' now, even though 'local' isn't POSIX?

16:06 <sewn> if your shell doesnt have local its not interactive

16:06 <sewn> plus for local in-shell functions it should be preferred than using unset

16:06 <sewn> imho: overwriting other functions variables rather than keeping them local

16:08 <dnkl> I understand that. But perhaps we shouldn't call it POSIX (the name of the section) when it no longer is?

16:08 <sewn> i dont think it matters

17:19 <emersion> well, standards exist for a reason

17:42 <toast> technically local is POSIX but there is no associated behavior

17:42 <toast> I.e it is not a syntax error to have it, and what it does is implementation defined

17:44 <toast> it’s specified in 2.9.1 command search and execution

17:44 <toast> > If the command name matches the name of a utility listed in the following table, the results are unspecified.

17:45 <toast> with the only search entry taking priority over this being special built-ins

17:45 <toast> (it’s in the same group as “builtin”, “disown”, “history”…)

17:45 <sewn> emersion: sometimes standards arent for good, especially missing no-brainer features

17:46 <sewn> in other words: it should have *been* in the standard

17:46 <sewn> if its needed, i can resubmit the patch with the "unset" commands and with function specific variable naming.

17:48 <toast> basically all implementations have it and those that don’t basically ignore it; so unless the latter is an issue you can probably keep it as is (?)

17:49 <emersion> sewn: then don't refer to the standard at least

17:49 <toast> POSIX is full of “details” like this so that avoiding all undefined behaviours is very hard

17:49 <emersion> (but I disagree in general)