From @moritz

<moritz> r​: say $*EXECUTABLE_NAME
<camelia> rakudo-jvm 3699aa​: OUTPUT«perl6-j␤»
<camelia> ..rakudo-parrot 3699aa​: OUTPUT«./rakudo-inst/bin/perl6-p␤»
<camelia> ..rakudo-moar 3699aa​: OUTPUT«perl6-m␤»

It's certainly wrong that rakudo-parrot includes relative paths, but
rakudo-moar and rakudo-jvm don't.

Now which way is correct?

For tests that invoke the compiler again as a subprocess, the
rakudo-parrot output is much more useful.

One could also argue that $*EXECUTABLE_NAME should contain an IO​::Path
object (and maybe be renamed to $*EXECUTABLE in the process), or that
there should be some other way to obtain a command line suitable for
invoking the current compiler (remember that for niecza, it's not a
single command (or at least used to be), but rather 'mono
path/to/Niecza.exe').

The current behavior leads to spectest failures in
t/spec/S32-list/roll.t on rakudo-m and rakudo-j.

From @FROGGS

FROGGS r​: say $*EXECUTABLE
camelia rakudo-jvm 11d748​: OUTPUT«IO​::Path</home/p6eval/rakudo-inst/bin/perl6-j>␤»
camelia rakudo-parrot 11d748​: OUTPUT«IO​::Path</home/p6eval/rakudo-inst-2/bin/perl6-p>␤»
camelia rakudo-moar 11d748​: OUTPUT«IO​::Path</home/p6eval/rakudo-inst/bin/perl6-m>␤»
FROGGS r​: say $*EXECUTABLE_NAME
camelia rakudo-jvm 11d748​: OUTPUT«perl6-j␤»
camelia rakudo-moar 11d748​: OUTPUT«perl6-m␤»
camelia rakudo-parrot 11d748​: OUTPUT«perl6-p␤»

S29-os/system.t and others test $\ast EXECUTABLEalready,though$*EXECUTABLE_NAME is not the most useful thing anymore, which means it is not tested and might wnt to vanish.

@FROGGS - Status changed from 'new' to 'resolved'