Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken tests in S29-os/system.t #375

Closed
zoffixznet opened this issue Jan 5, 2018 · 0 comments
Closed

Broken tests in S29-os/system.t #375

zoffixznet opened this issue Jan 5, 2018 · 0 comments
Assignees

Comments

@zoffixznet
Copy link
Contributor

zoffixznet commented Jan 5, 2018

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...

@zoffixznet zoffixznet self-assigned this Jan 5, 2018
nwc10 added a commit that referenced this issue Dec 30, 2020
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant