Start Audacity on the wrong version of macOS when Planet X is in Cassiopeia.

The history, in brief:
(version 1.3.14) We packaged the executable with a shell script to change environment before invoking Audacity, just so that certain libraries -- which are not loaded until AFTER startup -- would be located correctly by the dynamic loader. (Bug 290)
(version 2.0.6) To mitigate a very minor downside of the script, not the binary, being the click target in the bundle (bug 543), we got rid of the script, but make Audacity do an execve shortly after starting, a measure which now seems very suspect.
(version 2.1.3) Possibly as a consequence of that, we got the intermittent bug 1567, only on the newest version of macOS (Sierra), which held up 2.1.3.  To fix it sometimes, we compounded the strangeness of the execve with a fork and crash too, and some other work to cleanup .DS_STORE files.  We don't fix bug 1567 to our complete satisfaction, but ship 2.1.3 as good enough.
(version 2.2.0) We observe other weird behavior on Sierra:  small changes in size of the executable cause wxWidgets libraries to load from the wrong place at startup; double-click on .aup brings up empty project window.
The history, in detail:
Before version 1.3.14!  Bug 290 reported by David Favor: "(Mac) LAME: Audacity looks for LAME in a restricted folder that Mac no longer supports" http://bugzilla.audacityteam.org/show_bug.cgi?id=290
Fix made by Leland, introducing file Audacity.sh that changes environment, at  https://github.com/audacity/audacity/commit/07661c186f7e8e6d978fa35485d65364b96dfb3a (with explanation starting at http://bugzilla.audacityteam.org/show_bug.cgi?id=290#c9 and more at comment 15 and commit mentioned at comment 21; some Windows problems mentioned too, but apparently fixed then and no longer a problem)
A modification of that commit at https://github.com/audacity/audacity/commit/c576fc489395a3a4a4e5728e4b534065f82921d2 (introduces shell variable AUDACITY_EXECUTABLE)
Before version 2.0.6: P4 Bug 543 reported by Gale ""Kind" information not sufficiently visible." at http://bugzilla.audacityteam.org/show_bug.cgi?id=543
A fix just for 543 at https://github.com/audacity/audacity/commit/36361a6b86dac4b0f2b16b7017007b4cc7717c7a removed the Audacity.sh file, introduced the suspicious exeve in main()
Before version 2.1.3, the notiorious bug 1567 "Mac Sierra: LAME, FFmpeg and some plugins disappear. (intermittent)"  reported by Gale http://bugzilla.audacityteam.org/show_bug.cgi?id=1567
Gale observes that force-quitting Audacity from the tool dock can clear the problem, and Paul got the idea to do the equivalient automatically by raising a signal.
Partial fix to 1567, including the strange fork-and-crash, but keeping the execve, at: https://github.com/audacity/audacity/commit/a05d039055909d7d1dc2d4f31e1fe0659a3207dd
Other partial fixes to 1567, including certain cleanups of .DS_STORE files: https://github.com/audacity/audacity/commit/dd836f484101cec592ca9255b09384a03279820c https://github.com/audacity/audacity/commit/3ebf9fca209cdacb04d71e09300c2b46d392a27e https://github.com/audacity/audacity/commit/6b65375ee5b3990ec6764dbd71c02b7d9931b660 https://github.com/audacity/audacity/commit/856dfef30f73860821793b5b227714e393872362 https://github.com/audacity/audacity/commit/5b10c386e96b0126e2f3911e83174ab861fad6c0 https://github.com/audacity/audacity/commit/95861bf7f2354b1ee8462573200036ee9e8b8b5a
Shortly before version 2.1.3:  Another commit mentioned in the first bug, Bug 290, by James, at https://github.com/audacity/audacity/commit/0efe931df26da43198b03972ed50b4c3c88b2662
Maybe relevant too, shortly thereafter, https://github.com/audacity/audacity/commit/2fef7f34b82e1a14af4c4b27f486ce9d13fe3086
Late July 2017, during 2.2.0 development:  a strange problem observed, that some alpha versions of Audacity loaded wxWidgets libraries from the wong, system, paths instead of from the bundle.  It happened reliably in certain versions, but the problem bisected to a seemingly irrelevant change in the size of one large, static, const array of chars defining theme information.  It was also observed that merely redeclaring the arrays a non-const made the problem remit.
26 July: Steve also reports that some on the Forum observe that double-clicks on .aup files, while Audacity is not yet running, open the program with an empty window.  Not so when the program is previously open.  Paul suspects a connection with the execve too.

My suggestions for the present:

1 Do away with the strange fork, crash, and execve, which I suspect are the unusual things in our program that cause various griefs on macOs Sierra.

2 The loading of LAME and FFmpeg libraries happen AFTER startup, not during.  So we should be able to change the environment variables that influence that while Audacity runs, not necessarily before.  So there was no need for either the execve or the shell script that existed before that.

3 Perhaps do away with .DS_STORE cleanup if it isn't needed either.
Re-verify bugs 290, 543, and 1567 if we can.  (But they may be reports on obsolete OS versions, or intermittent, so verification is difficult.)

Now I think number 2 seems obvious, but in comment 15 of bug 290 Leland mentioned "runtime updates" of environment variables as being avaiable on Windows -- as if they aren't on macOS ??  Or if they are, dyld ignores them?

*** STEPS UPDATED ***

Created a wiki page at http://wiki.audacityteam.org/wiki/Bug:1702 to make it easier to keep this bug in a 'summary' state.  If this works well, possibly we should do this for all Summary bugs.

All I'll say here is that "the moon is in the seventh house and Jupiter aligns with Mars".

I have bever had a problem with this and I load on my Mac many alphas and many older versions of Audacity - and LAME and FFmpeg have always been found, and work, ok

Added bug 1703 with cross reference to this.  That one is not about libraries, but I suspect common cause, in the weird things we do at startup of 2.1.3.

(In reply to Peter Sampson from comment #4)

As explained, there was a very old fix for 290, which was re-worked to fix 543, but that is suspect for making bad side effects on Sierra.

I am reverting things to the old fix for 290, but that needs a re-test.

I re-resolve the minor Bug 543 as wont-fix now.

I hope bug 1703 is incidentally fixed.

This is a merge commit; interested devs, please read the commit comments.

There is still a question mark about whether this will interfere with code signing.

https://github.com/audacity/audacity/commit/dba49dd485d718a7ce5e42cf1cf4a7990d2e6a59

Technicalities:

It is still the case that you will start a sh process, which will call unsetenv, and then execve to overwrite the sh process with Audacity.  But I suspect execve is more harmless to do in a script than in Audacity.  That is because -- you can observe this in a debugger -- in Audacity, you may execute all sorts of things, even C++ and Objective-C code, that initialize static variables in all of the initially loaded libaries, before even reaching main().  But execve forgets all of that state, skipping whatever important things might happen in destructors, and causes all those initializations to be done again.

I am guessing that this explains some havoc, which execve called from a simple sh process won't cause.

About James's speculation about important stuff in DYLD_LIBRARY_PATH, interacting with Gatekeeper, I observed in debugging on 10.11.6 that it includes /usr/lib/system/introspection -- who knows what that is.

If you look closely at the shell script, you see it does not lose whatever is in DYLD_LIBRARY_PATH, but moves it into DYLD_LIBRARY_FALLBACK_PATH.  That is from the original 290 fix, but was not kept in the rewrite to fix 543.

Just repeating what I said in Comment #4

"the moon is in the seventh house and Jupiter aligns with Mars" - plus we've just had the eclipse and the Perseid meteor shower ..

I have never had a problem with this and I load on my Mac many alphas and many older versions of Audacity - and now two instantions of the 2.2.0 Beta - and LAME and FFmpeg have always been found, and work, ok

Always works fine for Cliff too, as he reports

So I do not believe that this is an issue that needs to remain open - but for now I will leave it for someone else to close off.

Testing on macOS Sierra 10.12.6 4a0fbf8 27Sep17
(and on the 2.2.0 Beta-1 for Mac)

I still cannot get this to occur.

Nor since the release of Beta-1 for Mac have I seen any complaints on the Forum of this occurring.

I believe this is fixed and that we should close this bug as resolved.

I agree. Never seen it happen here.

Tested again on the official 2.2.20 RC1 (signed) on my Macbook Pro macOS 10.13 High Sierra

LAME and FFmpeg found properly, automatically, in my:
a) privileged administrator account
b) normal non-privileged user account
c) totally unprivileged guest account

And no effects, generators or Analyzers missing.

Cliff has posted to say that he has no problems with this either - and I assume from the lack of reports from Bill and Steve that this all works fine on their Mac's too.

The RC1 has been out in the wild for more general testing for a few days now and we have no reports of this issue recurring - so I am going to close these as RESOLVED