OUTBASH_PORT is only set for interactive shells

[xilun]

OUTBASH_PORT is currently set through a rcfile, and a rcfile is only for interactive shells

/usr/bin/env could be used in other cases (or in all cases)

[xilun]

Actually the best way with bash -c seems to be to prepend e.g. "export OUTBASH_PORT=4242 ; " to the option of -c. This covers e.g. outbash -c "wcmd echo foobar; wcmd echo 2000", translated to bash -c "export OUTBASH_PORT=4242 ; ""wcmd echo foobar; wcmd echo 2000", whereas with env it would only apply to the first wcmd.

[xilun]

An alternative way would be to wrap the whole bash command with another one like that:

outbash -c "echo kikoo \$OUTBASH_PORT"
=>
bash.exe -c "env OUTBASH_PORT=4242 bash -c \"echo kikoo \\\$OUTBASH_PORT\""

This is slightly better because multiple commands in a -c force bash to continue to run, waiting for each command, including the last one, while a single one seems optimized as an exec. The proper optimization should be to tail exec the last command (in which case there would be no reason to prefer this bash -c within bash -c hack), but GNU bash does not seem to do that.

Anyway, for now I think I'll go with "export OUTBASH_PORT=4242 ; ", because in the inception case proper escaping would be required.

Edit: the inception solution also uses 2 more exec, so it's not clear it is that much better... Edit2: but the inception solution works for arbitrary command lines, not only those with a '-c' option.

[xilun]

So I think I'll go for the generalized inception solution, because it works better regardless of the options you pass to bash (for example with the current implementation login shells also do not get OUTBASH_PORT...)

Edit_999999: hm calling env is not really necessary => one less extra exec.

[xilun]

Commit fb6f0b1 fixes this issue.