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

My alias-expanding sudo hangs with 0.8.1 #2893

Closed
t184256 opened this issue Oct 21, 2018 · 12 comments
Closed

My alias-expanding sudo hangs with 0.8.1 #2893

t184256 opened this issue Oct 21, 2018 · 12 comments

Comments

@t184256
Copy link
Contributor

t184256 commented Oct 21, 2018

In xonsh 0.8.1 with --no-rc I can do sudo ls | less and it works fine.

With a .xonshrc consisting of the following lines only:

# make sudo expand aliases
def sudo_expanding_aliases(args, stdin=None):
    /usr/bin/env sudo @(aliases.eval_alias(args))
aliases['sudo'] = sudo_expanding_aliases
del sudo_expanding_aliases

/usr/bin/env sudo ls | less works as expected, while sudo ls | less hangs hard since 0.8.1, C-C or C-\ do not help.

Couldn't find any relevant recent changes at the first glance, were there any?

@scopatz scopatz added the bug label Nov 8, 2018
@scopatz
Copy link
Member

scopatz commented Nov 8, 2018

Thanks for reporting @t184256! Actually, on 0.8.0, I am getting sudo ls | less hanging with that alias, so I don't think that 0.8.1 broke it in any real way.

I think that the main issue here is that stdout in the alias isn't be redirected correctly.

@scopatz scopatz added question and removed bug labels Nov 8, 2018
@scopatz
Copy link
Member

scopatz commented Nov 8, 2018

I think this is the right way to write such an alias:

def sudo_expanding_aliases(args, stdin=None, stdout=None): 
    p = !(/usr/bin/env sudo @(aliases.eval_alias(args))) 
    for line in p: 
         stdout.write(line) 
    return p.returncode

aliases['sudo'] = sudo_expanding_aliases 
del sudo_expanding_aliases 

@scopatz
Copy link
Member

scopatz commented Nov 8, 2018

We should probably have sudo, env and a few others always expand aliases too, though.

@t184256
Copy link
Contributor Author

t184256 commented Nov 29, 2018

I've tried your suggestion way and it doesn't play nice with interactive commands like vi. Went back to #2618 (comment)

@scopatz
Copy link
Member

scopatz commented Dec 19, 2018

Let us know if there is anything specific we can do

@t184256
Copy link
Contributor Author

t184256 commented Dec 22, 2018

I am very sorry, I don't know how to put it into a specific request. Honestly, I want sudo to expand aliases in a way that "Just Works" (tm).

Currently my version hangs hard on my example, while your version hangs on any interactive command, alias or not, displaying a lone ^Z.

Is anything I can do to provide more info on this? Could you fix my version? What do others use?

@scopatz
Copy link
Member

scopatz commented Jan 31, 2019

Yeah, I am honstely pretty confused about what is going on here

@t184256
Copy link
Contributor Author

t184256 commented Feb 7, 2019

Does 0.8.10 alias work bring anything new to the table?

@scopatz
Copy link
Member

scopatz commented Feb 7, 2019

It probably does, but I haven't had a chance to look at this issue specifically.

@anki-code

This comment was marked as outdated.

@anki-code
Copy link
Member

anki-code commented Mar 24, 2021

I've taken a short look into this.

  1. At this time the alias resolving is working only for the first argument. And in xonsh the command bash ls (where ls is alias ls --color) is working like in bash (without resolving) i.e bash ls is bash ls instead of bash ls --color.

  2. I've also tried ExecAlias to solve this but without success (with feat: Added ability to get arguments list in ExecAlias #4201 and feat: Ability to call the program by name from callable alias with the same name without the infinite loop error #4218):

aliases['sudo'] = 'sudo @(aliases.eval_alias($args))'    # ExecAlias
sudo ls | less
# no response
  1. The start point to research is here.

UPD: this is my old try to solve this and it's mostly outdated but I leave it here for education of a stranger who digging here.

I tried to solve this issue by manipulating with predictors.

This alias is working with piping into capturable tools like grep:

from xonsh.commands_cache import predict_false, predict_true

def sudo_expanding_aliases(cmd, stdin=None, stdout=None, stderr=None):
    curr_sudo_predictor = __xonsh__.commands_cache.threadable_predictors['sudo']
    try:
        __xonsh__.commands_cache.threadable_predictors['sudo'] = predict_true
        if r := ![sudo echo -n]:  # to get password prompt in uncapturable mode
            if __xonsh__.commands_cache.predict_threadable(cmd):
                __xonsh__.commands_cache.threadable_predictors['sudo'] = predict_true
                p = !(sudo @(aliases.eval_alias(cmd)))
                p.end()
                for line in p:
                    stdout.write(line)
                if p.errors:
                    for line in p.errors.splitlines():
                        stderr.write(line + '\n')
                __xonsh__.commands_cache.threadable_predictors['sudo'] = curr_sudo_predictor
                return p.returncode
            else:
                __xonsh__.commands_cache.threadable_predictors['sudo'] = predict_false
                r = ![sudo @(aliases.eval_alias(cmd))]
                __xonsh__.commands_cache.threadable_predictors['sudo'] = curr_sudo_predictor
                return r.rtn
    finally:
        __xonsh__.commands_cache.threadable_predictors['sudo'] = curr_sudo_predictor

aliases['sudo'] = sudo_expanding_aliases
del sudo_expanding_aliases

sudo ls / | grep bin
# bin
# sbin

But this alias is not working with uncapturable tools like less.

@anki-code
Copy link
Member

anki-code commented May 12, 2021

I'm going to close this as duplicate #2618

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants