Failures in high level script functionality on illumos #5472
Comments
Huh. How do you prepend that? It's possible that we set our PATH for the tests. And should we be prepending it, like we do /usr/xpg4/bin if it exists? Anyway, I had seen that, and I'd instead just drop the The |
These aren't available on OpenIndiana. `grep -o` is easily changed to `string`, `diff -q` imitated with `comm` and `test`. See #5472.
We set
That should work for OI, may not for other illumos distributions. Safe should be to let the user define the environment (here Other possibility is to test for features and then choosing the right binary, or approach to the binary.
Thanks. And sorry for our tools not being up-to-date with what one expects.
"GNU tools" (coreutils, GAWK, tar, ...) behave as expected, when they are available (and they are available by default on OI), they are available both by their expected name from |
Ah, okay. So... I, personally, would heavily favor the GNU tools, but then I actually prefer having lots of features over clean minimalism. But I'm not an OpenIndiana user. And given that we can't rely on the GNU tools everywhere anyway, as long as the non-GNU tools are reasonably standards-compliant, we should just deal with it. The problem here is that your Can you check if sh -c "cd ..; rm $PWD"works? That should be a usable workaround that we can just plonk in here. I don't want to call The final test tests a redirection - We could again skip this by checking |
Well, I guess it depends on what it means "to work"... You expect the {global} newman@lenovo:~/Downloads/tmp1/tmp2 $ sh -c "cd ..; rm $PWD"
rm: /export/home/newman/Downloads/tmp1/tmp2 is a directory
{global} newman@lenovo:~/Downloads/tmp1/tmp2 $ echo $?
2
{global} newman@lenovo:~/Downloads/tmp1/tmp2 $ sh -c "cd ..; grm $PWD"
grm: cannot remove '/export/home/newman/Downloads/tmp1/tmp2': Is a directory
{global} newman@lenovo:~/Downloads/tmp1/tmp2 $ echo $?
1I did not understand the case with redirection. |
Basically, yes. We expect it to remove $PWD, to test what fish does when $PWD is removed. (Well, actually that's just one bit - the cd completion tests just want to clean up, so that's not all that important. Adding a commit for that now.)
Sorry,
It's just a case of OpenIndiana having a different error message than "everything" else. This is calling It's just a bit tricky to get the tests to be okay with either. |
Otherwise this'd run afoul of OpenIndiana's "no removing $PWD" rule. Spoilsports! See #5472.
Right, that confused me. In newman@lenovo ~/D/t/tmp2> sh -c "cd ..; rmdir $PWD"; echo $status
0
newman@lenovo ~/D/t/tmp2> sh -c "cd ..; grmdir $PWD"; echo $status
0And exactly the same with Now I understand your case with redirection. I see the same thing. |
|
For those playing along at home, the remaining issues here are:
|
This tested fish-shell#1728, where redirecting a directory (`begin; something; end < .`) would cause `status` to misbehave. Unfortunately, on Illumos/OpenIndiana/SunOS, this returns a different error (EINVAL instead of EISDIR), so we can't check that with our test harness, because we can't redirect it. Since it's not important that this gives the same error across systems (and indeed we provide no way of intercepting the error!), use an invocation test instead, because that allows different output per-uname. See fish-shell#5472.
Illumos/OpenIndiana/SunOS/Solaris has an rm/rmdir that tries to protect the user by not allowing them to delete $PWD. Normally, this would be a good thing as deleting $PWD is a stupid thing to do. Except in this case, we absolutely need to do that. So instead we weasel around it by invoking an sh to cd out of the directory to then invoke an `rmdir` to delete it. That should throw off any attempts at protection (we could also have tried $PWD/. or similar, but that's possibly still protected against). This is the last failing test on Illumos/OpenIndiana/SunOS/Solaris/afunnyquip, so: Fixes fish-shell#5472.
This tested fish-shell#1728, where redirecting a directory (`begin; something; end < .`) would cause `status` to misbehave. Unfortunately, on Illumos/OpenIndiana/SunOS, this returns a different error (EINVAL instead of EISDIR), so we can't check that with our test harness, because we can't redirect it. Since it's not important that this gives the same error across systems (and indeed we provide no way of intercepting the error!), use an invocation test instead, because that allows different output per-uname. See fish-shell#5472.
Illumos/OpenIndiana/SunOS/Solaris has an rm/rmdir that tries to protect the user by not allowing them to delete $PWD. Normally, this would be a good thing as deleting $PWD is a stupid thing to do. Except in this case, we absolutely need to do that. So instead we weasel around it by invoking an sh to cd out of the directory to then invoke an `rmdir` to delete it. That should throw off any attempts at protection (we could also have tried $PWD/. or similar, but that's possibly still protected against). This is the last failing test on Illumos/OpenIndiana/SunOS/Solaris/afunnyquip, so: Fixes fish-shell#5472.
Otherwise this'd run afoul of OpenIndiana's "no removing $PWD" rule. Spoilsports! See #5472.
This tested #1728, where redirecting a directory (`begin; something; end < .`) would cause `status` to misbehave. Unfortunately, on Illumos/OpenIndiana/SunOS, this returns a different error (EINVAL instead of EISDIR), so we can't check that with our test harness, because we can't redirect it. Since it's not important that this gives the same error across systems (and indeed we provide no way of intercepting the error!), use an invocation test instead, because that allows different output per-uname. See #5472.
It turns out the default gettext on the sunny operating system with the many names interprets at least `\n` itself, so we'd end up swallowing it. This allows us to move past the interactive tests and onto the expect ones. See #5472.
|
Confirmed it works. Thanks! |
On Openindiana I see following failures in "high level script functionality" test:
For cases like this, where
grepoption is required (-ohere), which ourgrepdoes not have, we prepend/usr/gnu/binin$PATH, so GNU utilities are executed preferentially. However, from unknown reason it fails here:The text was updated successfully, but these errors were encountered: