You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These tests are broken. In the first subtest, the brokeness is masked by the test being too loose, but the second one can be made to fail if executed by a user that doesn't have "system" perl6 installed.
What happens is after we already cwd, the perl6 binary can't find its libs, so it dies with something like:
Unhandled exception: failed to load library 'dynext/libperl6_ops_moar.so'
at <unknown>:1 (/home/zoffix/CPANPRC/rakudo/perl6.moarvm:<dependencies+deserialize>)
Don't have time to fix the tests right now, but I'd split the env and cwd tests into separate tests. Test env tests with $*EXECUTABLE, but for cwd, test them by checking echo is runnable (skipping the tests, if it isn't) and then testing CWD got changed by running shell "echo {$*DISTRO.is-win ?? '%CD%' !! '$PWD' }"
That'd test shell.... but run tests can be with like run 'cmd.exe', '/C', 'echo %CD%' for Windows and run "/bin/sh", "-c", "echo \$PWD" for others. Don't know how sanely portable that is...
The text was updated successfully, but these errors were encountered:
…laris.
It turns out that `echo $PWD` isn't *quite* portable. The test assumes that
the shell will set the environment variable PWD to the current directory as
part of its startup. This is needed, because the implementation detail being
tested here is that the command is run with a *different* current directory
from the Raku code - ie there is a `chdir` happening as part of the command
invocation, without affecting the invokee.
Solaris (these days) uses ksh93, and *that* turns out to be wonderfully
special. If the current directory is `/` or `~`, then it *does* set PWD (to
the canonical path). Otherwise it leaves PWD unchanged.
I *guess* that this is because it has to figure out the name => (dev,ino)
mapping for these two paths anyway, and it's cheap to stat("."), so it
updates PWD if it happens to find that it knows the pathname corresponding
to "."'s (dev,ino), but doesn't do any extra work if it doesn't recognise
".". I don't find this documented anywhere.
AIX appears to use an older ksh, and that *is* updating PWD.
(That's all the vendor OSes I currently have access to, to test.)
So run `pwd` instead of relying on $PWD being set. I think that this will
also work even if the shell is a Bourne Shell, as I don't believe that
there's any *requirement* for the shell to set this variable.
So Zoffix Znet was correct to write
Don't know how sanely portable that is...
in Jan 2018 in #375
These tests are broken. In the first
subtest
, the brokeness is masked by the test being too loose, but the second one can be made to fail if executed by a user that doesn't have "system" perl6 installed.What happens is after we already cwd, the perl6 binary can't find its libs, so it dies with something like:
Don't have time to fix the tests right now, but I'd split the env and cwd tests into separate tests. Test env tests with
$*EXECUTABLE
, but forcwd
, test them by checkingecho
is runnable (skipping the tests, if it isn't) and then testing CWD got changed by runningshell "echo {$*DISTRO.is-win ?? '%CD%' !! '$PWD' }"
That'd test
shell
.... butrun
tests can be with likerun 'cmd.exe', '/C', 'echo %CD%'
for Windows andrun "/bin/sh", "-c", "echo \$PWD"
for others. Don't know how sanely portable that is...The text was updated successfully, but these errors were encountered: