-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
Backtick behavior around symlinks changed from 1.7.19 to 1.7.22 #3459
Comments
Maybe this is the problem?
Can I override the behavior of ShellLauncher somehow? |
It looks like
I think this is a problem. |
I copied
|
…ession on 1.7.19 test with older 1.7.18 until jruby/jruby#3459 gets resolved
@kares how do I reproduce this? I tried an irb session on MacOS where I did:
Then in irb I ran |
not sure (haven't tried) but it definitely reproduced with |
Let us ignore postgres & ubuntu. They have nothing to do with this problem, I was just providing details. Create a file
In case you are not familiar with C: This program just displays the value of Compile it with the following command
This will give you an executable called 'running_as
Using your favorite shell, invoke it directly and via the symlink
Notice the output is different. Start
Do the same thing with jruby 1.7.22
This is blatantly not the expected behavior. Nowhere in the definition of ruby's backticks does it say "derefence a symlink". Here is ruby 1.9.3 for comparison
The cause of the bug is the usage of the method
Calling I monkey patched around this problem so I could get JRuby 1.7.22 into the production environment at my employer. |
@hydrogen18 we will try and make sure we prioritize this for the next point release but we have some pressure to get 1.7.25 out so I am punting. Thanks for the repro. This will make it much easier for us to solve this problem. I suspect your canonical theory is not correct. At least, traditionally, we have used canonical specifically detect softlinks prior to nio.2. So we have went through a lot of pain trying to detect stuff Java did not easily allow. I suspect our messy proc launching code somehow got changed and we ended up doing down a different code path. Process-launching has been one of our hardest things to support over the years and 1.7.x in particular shows its age. In 9k, the new native path is pretty much what MRI does now. |
Is this still a bug in the latest 1.7 release? |
@hydrogen18 This could be really simple. We're probably just passing the long path for argv[0] when we should be passing the unresolved path, as @hydrogen18 pointed out above. I'll have a quick look. |
Doesn't look like anyone has tried 9k, so I can confirm it works correctly:
@hydrogen18 You are trying to use 9k now, right? I mean, this still could be fixed in 1.7, but we're not really maintaining that line anymore. |
Yes actually I was just trying to figure out if I needed our monkey patch in the 1.7 branch. |
@hydrogen18 I don't know actually. We are looking at doing a 1.7.27 to wrap up that line, but I'm not sure this needs to be fixed...and if it does I'm not sure we'll bother since it works properly in 9k. |
EOL'ing 1.7.x after our next release and no one is stepping up for this. |
I'm trying to upgrade to JRuby 1.7.22 from 1.7.19. Somehow the backticks (subshell) behavior changed. It looks like symlinks are handled differently between the versions. This is causing invocation of
pg_dump
to fail.Its almost like 1.7.22 is somehow following the symlink itself and invoking the
pg_wrapper
shell script directly. Is there some configuration option around this?The text was updated successfully, but these errors were encountered: