Documentation RQ: How to setup environment variables such as mesa_glthread=true / migrate prefix commands?

[mjevans]

I don't and won't use Discord or any other walled garden platform, it would be better if all documentation, including Q and A / bug reports, were on publicly viewable websites. I have checked the issues (even closed ones) that I could search for obvious to me terms.

I'm trying to migrate from MultiMC / PolyMC which support *nix style wrapper commands like this:

WrapperCommand=sh -c "export mesa_glthread=true; exec $INST_JAVA \\"$@\\""

I tried variations such as: (Enable commands, wrapper=) sh -c "export mesa_glthread=true; exec $INST_JAVA $INST_JAVA_ARGS" However that command appears to include newlines which break the wrapper command, at least for the pack that I was trying first.

The pack launches correctly when I disable wrapper commands, BUT I'm unable to force mesa_glthread enabled.

It would be nice if the documentation on the Settings > Commands page showed both an example of the current launch command. Either greyed out text that vanishes when selected for editing and replaced by an edit window; or probably better for AT Launcher, the current launch command structure and also revert to that when the field is left blank; maybe add an X / reset button as clear documentation / UI.

E.G. $INST_JAVA $INST_JAVA_ARGS -- as the launch command?

ATLauncher Version: 3.4.20.2 Linux, 64 bit java, zulu-17 as the default java version

[RyanTheAllmighty]

We technically don't use any launch commands if you don't provide them, but it's a fair point to add in the default you recommended to make it a bit clearer

[mjevans]

Thank you, if you happen to know it, or where to find it easily, what is the default?

[RyanTheAllmighty]

Well there is no default. Wrapper commands just added before the actual launch command

[mjevans]

The wrapper from MultiMC / forks can subsume the launch command with the quoted "$@" (*nix shell for, all of the arguments, keep them quoted / tokenized as was).

Does that mean AT Launcher would instead include the desired environment variable with this Prefix command?

export mesa_glthread=true

Which would be a literal command before the invocation, or alternately some shells would allow the environment variable assignment immediately before the binary (unsure offhand on the rules for that, I assume if it can't find an executable before the first = that gets assigned at the next unquoted tokenization character).

mesa_glthread=true

Which would be concatonated with a separation with the actual command or otherwise parsed as an environment variable and set accordingly.

[RyanTheAllmighty]

You may be able to use %command% from what I'm seeing at https://github.com/ATLauncher/ATLauncher/blob/bba45f105239bd9ad60653f1bdabdc24a2f3a969/src/main/java/com/atlauncher/mclauncher/MCLauncher.java#L145-L172 to indicate the launch command.

This functionality was added by someone else, hence why I'm not overly familiar with it sorry

[RyanTheAllmighty]

Yeah the hover text on that wrapper command label is:

Wrapper command allow launcher using an extra wrapper program (like 'prime-run' on Linux)
Use %command% to substitute launch command
%"command"% to substitute launch as a whole string (like 'bash -c' on Linux)

[mjevans]

As a reminder, interactive sh / bash style environmental variable syntax similar to

mesa_glthread=true (implicit %command%)

Result in errors like [2022-10-31 00:55:43 AM] java.io.IOException: Cannot run program "mesa_glthread=true" (in directory "USERSDIR/instances/TFCtest"): error=2, No such file or directory

Neither of these seem to work (note the quote character as part of the whole keyword)

sh -c "export mesa_glthread=true; exec %"command"%"

sh -c "export mesa_glthread=true; exec %command%"

This is a little closer...

sh -c "export mesa_glthread=true; exec %command% "

However with the code-flow above the failure makes perfect sense; all three return paths happen right after the normal command list is added to the invocation, without the suffix. Of course it doesn't find the termination of the wrapper for %command% when the suffix is truncated.

Both the %command% and %"command"% magic string replacement arguments should be replaced in the same way the listed $INST_VAR arguments are handled. They should also be part of the replacements list under the textbox; not a (?) indicated popup that is, in the face of a lower block of text documentation, unhelpful, since the list beneath appears exhaustively inclusive.

[2022-10-31 00:48:00 AM] Launching Minecraft with the following arguments (user related stuff has been removed): [sh, -c, "export, mesa_glthread=true;, exec, '/usr/lib/jvm/zulu-17/bin/java' '-XX:-OmitStackTraceInFastThrow' ... Blob of stuff ... 'fml.mcpVersion' '20220404.173914' '--width=854' '--height=480', "] [2022-10-31 00:48:00 AM] mesa_glthread=true;: -c: line 1: unexpected EOF while looking for matching `"' [2022-10-31 00:48:00 AM] mesa_glthread=true;: -c: line 2: syntax error: unexpected end of file

Note the final list item is a zero-length single quoted string that is the result of the single space character at the end of the command which is required to make %command% a whole word.

The parser should just scan the entire wrapper command for any occurrence of any of the magic strings. A single pass blind replacement. It shouldn't try to tokenize, figure out quote boundaries, nothing fancy like that.