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

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

    Date:        Sat, 02 Mar 2013 09:28:59 -0800
    From:        Bruce Korb <bruce.korb%gmail.com@localhost>
    Message-ID:  <513236DB.9060408%gmail.com@localhost>

  | > It doesn't have a -p option, or a posix mode, either.
  | 
  | "it" being the shell, or the command "command"?

I meant the shell, but I realised later that isn't what you meant, I
misread that part of your message - sorry.

  | POSIX absolutely, unambiguously requires that $(command -p -v sh)
  | yield a posix compliant shell program.

NetBSD does have ``command -v -p'' of course, and it will find a sh
(the path to a sh - /bin/sh of course) as expected.  That sh is NetBSD's
version of what a standard posix shell should be.

  | Except for running programs that I know to be programs and not
  | functions, I, personally, don't use var=whatever before the command.

This all started (and why the Subject header in this e-mail thread is
so weird) because when I was researching the bug report referred to
in the Subject, I noticed that NetBSD's sh man page said that var=foo myfunc
was supposed to work - the last time I tried it, it didn't (the var= part
was just a no-op...)   That was a long time ago ... (many many years).
I never complained, as I had looked at the posix spec, and saw how it
was written, and decided that implementing that would be just as bad as
not having it at all (it wouldn't be possible to use anyway) - so I just
ignored the problem.   Then I saw it was fixed, tested it, and saw it was
fixed properly (well, almost properly, I didn't notice the bug at the time,
I have just filed a bug report to get the bug that remains fixed).

I then asked NetBSD people if they agreed with my interpretation of it all,
and for someone to please promise not to change things to do it the posix
way.   That led to a long discussion, with some people not even willing to
believe the standard could possibly say what it clearly says, that being so
stupid...

Anyway, now I can do var=foo myfunc on NetBSD - which I actually really need
to do.   The reason is that I have scripts that want to use non-standard
utilities, so clearly I cannot rely upon them being present.  The solution is
to implement enough of the utility as a function to fool the script into
believing that the utility actually exists (the function won't really act
properly, but does a good enough job that the script works, well enough).

My problem was that I need to pass env vars to the non-standard utility
(it is a X application, and needs DISPLAY set).  So I want to do

        DISPLAY=xxx x-utility ...

and have that work the same way whether x-utility is a function, or
a real command that actually does the right thing.

I know I could do it using a posix shell, by following each such usage
with the commands to put DISPLAY back to its previous value (which
could be unset, so it isn't a trivial thing to do) but I regard that as
too ugly to contemplate.

The NetBSD shell (with the fix I just reported) or bash in non-posix mode,
do just what I need (bash is not standard on NetBSD so I cannot rely on that.)

  | However, I do deal with a lot of scripts that are putatively
  | portable.  For such purposes, it is prudent to posix-ify the
  | platform as much as possible.

Agreed - but only when posix is not insane.   When it is we do the
community a disservice by simply going along with the herd.

  | I know you know about the Austin group.  Please lobby away.

I know about them, I did not know how to contact them (I've seen just
the messages in newsgroup format, and they have all e-mail addresses
edited away (I HATE spammers, they have ruined the net) and I have
no access to usenet itself any more.)

So...

  |   austin-group-l%opengroup.org@localhost

thanks for that, assuming they allow postings from non-members, I will
send them a message.

kre