Re: CVS commit: src

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 22 Dec 2024 14:23:19 +0000
    From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
    Message-ID:  <20241222142323.DE3FC84CE2%mail.netbsd.org@localhost>

  | but I find the syntax of `local x=y' syntax to be a sharp edge
  | because it works differently from `x=y'.

It does indeed, and you're right, those quotes probably should not
have been removed.   I will fix them.

POSIX is (stupidly I think, though there are reasons) partly fixing
that in the latest version (not that it directly affects "local" as
that isn't in POSIX .. not enough shells agree on how it really works)
by adding the notion of "declaration utilities".  In those (export,
readonly, and by analogy, anything similar, like local) the args are
parsed as if they were var-assigns (any args that look like one).
I think it is unnecessary, and have no plans to go anywhere near that
(it breaks the way the shell works in general), but it would fix this
particular issue.

  | So I think it is better style in shell scripts to either consistently
  | write
  |
  | 	local x="$1"
  |
  | with the quotes, or separate the local and the assignment:
  |
  | 	local x
  |
  | 	x=$1

Not consistently, there are times when one is better than the other,
for various possible reasons, but in general, using one of those is
the right way.

  | (That said, I agree that the inner quotes in "${2-"$1"}" were silly
  | and replacing it by  local result="${2-$1}"  is fine.)

Not just silly, simply wrong.   In that (the original) the $1 is actually
unquoted.  In those old original 4 ${varXword} operators (X = '-' '+' '=' or 
'?') the quoting rules (derived from Bourne's original pdp-11 implementation,
where code space was at a premium) the " chars simply operate in pairs.

Almost no-one can believe this, and people get it wrong all the time.
In the previous standard, POSIX required that inside the {} any quotes
were at least paired, to avoid stuff like "${1"-word} which Bourne's shell
allowed, but in the latest version what all this might mean has just been
made unspecified, which paves the way for shells (given sufficient time for
old code to mostly go away) to change the rules and allow a new quoting
context inside the {} (just as is done for the substring match operators,
and in shells that provide more operators, all of them as well).

I'm not sure it is actually possible to reasonably change the meaning
however, too much (currently correctly written) would become unquoted,
and potentially wrong.

kre