Use LLStringUtil::getenv() or getoptenv() whenever we fetch a string that will
be used as a pathname.
Use LLFile::tmpdir() instead of getenv("TEMP").
As an added extra-special bonus, finally clean up $TMP/llcontrol-test-zzzzzz
directories that have been accumulating every time we run a local build!
Lacking time to properly test new LLStringUtil::getTokens() against the
present (different!) command-line scanners in LLExternalEditor::tokenize() and
LLCommandLineParser::parseCommandLineString(), just annotate as future work
the goal of unifying them... SIGH.
Much as I dislike viewer log spam, seems to me starting a child process,
killing it and observing its termination are noteworthy events.
New logging makes LLExternalEditor launch message redundant; removed.
Using a Params block gives compile-time checking against attribute typos. One
might inadvertently set myLLSD["autofill"] = false and only discover it when
things behave strangely at runtime; but trying to set myParams.autofill will
produce a compile error.
However, it's excellent that the same LLProcess::create() method can accept
either LLProcess::Params or a properly-constructed LLSD block.
LLProcessLauncher had the somewhat fuzzy mandate of (1) accumulating
parameters with which to launch a child process and (2) sometimes tracking the
lifespan of the ensuing child process. But a valid LLProcessLauncher object
might or might not have ever been associated with an actual child process.
LLProcess specifically tracks a child process. In effect, it's a fairly thin
wrapper around a process HANDLE (on Windows) or pid_t (elsewhere), with
lifespan management thrown in. A static LLProcess::create() method launches a
new child; create() accepts an LLSD bundle with child parameters. So building
up a parameter bundle is deferred to LLSD rather than conflated with the
process management object.
Reconcile all known LLProcessLauncher consumers in the viewer code base,
notably the class unit tests.
Let the user know what's wrong with external editor.
Added meaningful messages for the following errors:
* Editor not specified.
* Error parsing command line.
* Specified binary not found.
* Editor failed to run.
All the messages are translatable.
The editor can be specified:
* via "ExternalEditor" setting in settings.xml
* via LL_SCRIPT_EDITOR variable
Removed obsolete XUIEditor setting in favor of the new one.
andreykproductengine