-
Notifications
You must be signed in to change notification settings - Fork 254
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
blewithin
does not seem to respect as
#373
Comments
Thanks for the report. You're right, the The reason for this is that the various DSL methods are executed in a fixed order:
This is always the order; the way that you nest them does not have any effect, which I agree is somewhat counterintuitive. Changing SSHKit's behavior in this regard would be risky for us, because it would affect the commands that are executed for everyone that uses nesting. For now, I would encourage you to find a workaround. I'll leave this issue open just in case it is something the maintainers want to tackle for a future backwards-incompatible version of SSHKit. |
Thanks for the prompt response and explanation. I misunderstood the README about them being nestable and stackable in any order as meaning they would also be evaluated in that order. I'm happy finding a workaround, but it would be nice to make the execution order explicit in the README. (Apologies if it is but I didn't find it.) |
FYI, the execution order in the code is specified here: Lines 191 to 206 in 72a39a2
If someone wants to contribute a PR with an explanation for the README, please do! |
within
does not seem to respect as
within
does not seem to respect as
From the readme,
within
/as
/with
should be stackable. But this scenario, that does not work as expected:It looks like
within
always runs as the user executing the script, which is unexpected. I would have thought that it's done as the user of the enclosingas
. I've tried with the local and netssh backends and get the same results.This is with SSHKit 1.11.3 and Ruby 2.3.1 on Centos 6.
The text was updated successfully, but these errors were encountered: