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
sudo() doesn't play nice with shell syntax (&&, ;, etc) such as what cd() does #459
Comments
ctx.cd
and ctx.sudo
doesn't works together
Thought there was an issue for this already, but not seeing it. Thanks for the report! The primary issue here is that by default, commands are transparently sent to a real shell for execution (without a PTY, via As you've noted, the first obvious solution (listed in I haven't sat down and given the alternatives a hard think yet, so suggestions are welcome. (Note that wanting to explore alternatives doesn't mean a hard ruling-out of the subshell option, just that if we go there I want to be sure it's the least crummy path to take.) The only one that immediately springs to mind is the old chestnut of "drop
Due to all these problems, it'd be ideal if this was purely opt-in and not the default method of using
|
I knew it was not so easy.... To avoid file creation and associated issues which your solution, can we send command via stdin to avoid escaping problems ? Like this example: import subprocess
cmd = "cd /home && pwd && whoami"
shell_cmd = ['sudo', '-i']
p = subprocess.Popen(shell_cmd, stdin=subprocess.PIPE)
p.communicate(cmd)
shell_cmd = ['/bin/sh']
p = subprocess.Popen(shell_cmd, stdin=subprocess.PIPE)
p.communicate(cmd) May also help for other use cases like sending ssh commands ? By reading the code I see some potential issues:
|
That's actually a great idea, I'll have to take a poke and see how feasible it is. Off the top of my head, though, our use of Certainly it appears to work by hand, I guess since
(We'd use the same |
Another later idea as I run across this during the run up to Fabric 2...can we trivially solve this by using the list form of argv in our exec calls? (aka #2) I never really use that mode of subprocess munging but IIRC it often incidentally gives you greater control over tokenization, so if the average sudo implementation doesn't try to re-tokenize what we give it, could potentially work. Of course, this assumes sudo is handing it off to a shell internally or something, otherwise we're back to square one. But it's worth looking into before trying the file redirection or stdin ideas above. Also, if we go that route, it may need to be in tandem with |
Can someone suggest a workaround for now? I have something like:
Edit: I am now doing this but it is not that elegant:
|
I've tried your workaround and find it works if I modify your example like this:
Just move the double quotation marks in front of the Anyway, thanks a lot for your workaround, it do solve my problem. Hope this bug could be fix in the near future. |
I just ran in this issue. I have a suggestion that can serve as a temporary workaround. Instead of command_prefixes, have command_wrappers. Each wrapper would have a %s where the next command gets inserted. (If no %s is present, default to prefixing to ease transition.) Another point: Many of my sudo commands would be simpler if I could add the -i flag... Can this be added to the sudo.* environment? |
Have exactly the same problem since fabric1, today have ported my code from fabric 1 to fabric 2 and found out that is still not fixed |
A hint: At least on most real-life Linux systems, when wrapping the commands into a temporary shell script, you can avoid the disk I/O overhead if you write the shell script to /dev/shm if that directory exists. On systems where /dev/shm does not exist, you can still fall back to /tmp. |
Same issue -- converting a fabric1 script to fabric2, all good so far except this issue.
Since |
Belatedly sticking this in my priority queue as I get back into things here. I'm honestly not sure why I had it marked as bugfix since most solutions outlined are "feature sized". Not like it matters when these tickets stick around for so long |
Currently fabric2 has a problem with `cd` context manager and `sudo` command. To work around the issue I implemented a customcontext manager that keeps the cd paths as an array (stack). If stack contains items then the top path is fed into fabric.cd when running commands with use_sudo=False. If use_sudo is True then we modify the command executed and wrap it into `bash -c "cd {path} && {command}"`. This should be reverted to rely on builtin `cd` after the issue gets resolved in upstream. Also: - Implement hide as context manager on fabric2
Are there any chances for workaround to get merged ? |
If the extra feature of the sudo command is not needed just use run with c.cd(dir):
c.run(f'sudo -u {user} command') |
Why is sudo not including the -i flag? In fabric3, I was doing this to run a gcloud command and the gcloud command was getting picked up in the remote user's PATH just fine:
But in modern fabric, that command fails because sudo is not causing the user's PATH to be set. I have to do this to make the same command work now:
By hacking the library and adding -i here in context.py:
the original command line from my fabric3 implementation just works with no changes. |
This issue is a bit of a nuisance, what needs to happen that we can get a PR that will be merged? (What criteria does the pull request need to fullfill? I am willing to look into it, and propose alternative solution if there is a chance that a fix is actually adopted into an release, otherwise we would just have to work around this with another dirty hack |
As
cd
is a shell builtin, it can't be executed as asudo
command. When I do that:The last command fail.
After a quick look in the source, sudo command appears to be:
with the cd prefix the executed command is
where
cd
is unknow insidesudo
.To fix the issue, new
sudo
command could be:but not sure of all the consequences of this behaviour.
The text was updated successfully, but these errors were encountered: