Re: bin/47597: local and $() don't play well with each other

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

    Date:        Tue, 26 Feb 2013 14:33:51 +0100
    From:        Steffen "Daode" Nurpmeso <sdaoden%gmail.com@localhost>
    Message-ID:  <20130226133351.ef+tQgKnJ66rV6LglDTgSVVf@dietcurd.local>

  | I'm confused about this thread.  NetBSD /bin/sh works absolutely
  | fine and complies to what POSIX says, even you add
  | 
  |   foo=YYY export what=ever
  |   f
  | 
  | to the example?

This might be flogging a dead horse now, as your message had to be sent
before my last two, and I think I may have answered you already, but
you're right, there's no problem with NetBSD's handling of the special
built-in commands (nor ksh's) - that's all as it should be (with the
exception perhaps of unset as in the example in my earlier message.)

  | My personal feeling is however also that the standard is absurd in
  | that it requires that VAR of 'VAR=VAL util' is treated as an
  | assigned if 'util' is a special shell builtin utility, but not
  | otherwise (because who can write stable scripts like that?).

You have that kind of backwards, the very point of the

        VAR=val util

syntax is to assign VAR to val (and export it) for util to use, and
only util.

If you just want a variable for the script to use, you just do
        VAR=val
(and export if needed) and everything works the way that you want.

The only issue is the special built-ins, which the standard treats as
special (I think) because of the way they had been implemented in existing
shells - not for any particularly good reason.

That is, someone looked at things carefully, and saw that
        "In our shell, a var assignment on a break statement
        isn't undone when the break executes"
which given the way that most special built-ins are implemented, is
actually entirely reasonable.    But instead of looking at this and
determining if that was just an implementation artifact, or something
actually desireable, they just write it down as it was implemented.
It is 99.999% useless (no-one actually does var assignments on special
built-ins that I have ever seen - not even the ':' example in real life,
they're just pointless - if you want it, you just do the var assignment
as a null command of its own).    But it is also mostly harmless, for the
same reason.

But on function calls, it is neither harmless or useless, and the SUS
is just plain stupid.

The particular case (or one particular case) I have, is that in my
X startup scripts I want to do (approx, it is actually more parameterised):

        DISPLAY=:0 xtoolwait xterm ...

The problem is that xtoolwait isn't a standard X utility, so it isn't
always present.

So, my startup script looks to see if it is there (that's easy) and if
it isn't, defines something approximately similar to

        xtoolwait() { "$@" & sleep 1 ; }

Or that's what I wanted, but when I set this up (many years ago) it
didn't work, because the DISPLAY=:0 assignment never happened when
xtoolwait was the function version (but worked fine for the real command).

Now, it would work, but if the SUS is followed, it would also result
in setting (actually, changing) DISPLAY for the rest of the script,
which I don't want (there's a lot of uses of this, so I don't want to
go remembering and resetting DISPLAY around every use of this.)

kre