Support for the exec builtin

[vitaut]

It would be useful if xonsh supported the exec Bourne shell builtin as some programs (such as Qt Creator) rely on it which requires using a different shell for them.

Currently trying to use exec fails with FileNotFoundError:

$ exec bash
Traceback (most recent call last):
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/shell.py", line 109, in default
    self.execer.exec(code, mode='single', glbs=None, locs=self.ctx)
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/execer.py", line 110, in exec
    return exec(code, glbs, locs)
  File "<xonsh-code>", line 1, in <module>
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/built_ins.py", line 383, in subproc_uncaptured
    return run_subproc(cmds, captured=False)
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/built_ins.py", line 355, in run_subproc
    stdin=stdin, stdout=stdout)
  File "/usr/lib/python3.4/subprocess.py", line 848, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.4/subprocess.py", line 1446, in _execute_child
    raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'exec'

[scopatz]

This wouldn't be significantly different from the source-bash alias that lives in aliases.py. Pull requests welcome!

[scopatz]

Hi @vitaut - I believe that this has now been added to master with #200 via the xexec builtin. Would you mind verifying this?

[vitaut]

AFACS the xexec builtin works fine. Is there a way to make xexec override Python's exec for systems that expect a shell with the exec builtin?

[scopatz]

@vitaut yes, but it shouldn't be enabled by default. The way to do this is to stick the following in xonshrc or elsewhere:

aliases['exec'] = aliases['xexec']

This will override the Python built-in exec() function.

[vitaut]

Fair enough, I'll add it to .xonshrc.

There is one issue with passing absolute paths to exec though:

$ exec /bin/sh
Traceback (most recent call last):
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/shell.py", line 131, in default
    self.execer.exec(code, mode='single', glbs=self.ctx)  # no locals
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/execer.py", line 124, in exec
    return exec(code, glbs, locs)
  File "<xonsh-code>", line 1, in <module>
TypeError: unsupported operand type(s) for /: 'builtin_function_or_method' and 'builtin_function_or_method'

[aig787]

@scopatz it looks like even with the alias entry in .xonshrc exec still refers to the python builtin.

$ exec
<built-in function exec>

[scopatz]

Ahh yes, this is almost certainly a builtin issue since exec/bin/sh is valid Python syntax. Try the following.

del exec
aliases['exec'] = aliases['xexec']

If that doesn't work, try this:

import builtins
del builtins.exec
aliases['exec'] = aliases['xexec']

This could break many things...

[vitaut]

@scopatz Unfortunately neither workaround works with exceptions at xonsh startup in both cases.

In the first case I get exception:

Traceback (most recent call last):
  File "/home/viz/Programs/xonsh/bin/xonsh", line 3, in <module>
    main()
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/main.py", line 40, in main
    shell = Shell() if not args.norc else Shell(ctx={})
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/shell.py", line 101, in __init__
    self.ctx = xonshrc_context(rcfile=rc, execer=self.execer)
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/environ.py", line 181, in xonshrc_context
    execer.exec(rc, glbs=env)
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/execer.py", line 124, in exec
    return exec(code, glbs, locs)
  File "/home/viz/.xonshrc", line 1, in <module>
    del exec
NameError: name 'exec' is not defined
Exception ignored in: <bound method Shell.__del__ of <xonsh.shell.Shell object at 0x7fe7e4879a90>>
Traceback (most recent call last):
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/shell.py", line 110, in __del__
    teardown_readline()
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/shell.py", line 66, in teardown_readline
    import readline
  File "<frozen importlib._bootstrap>", line 2214, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2199, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 2141, in _find_spec
  File "<frozen importlib._bootstrap>", line 1917, in find_spec
  File "<frozen importlib._bootstrap>", line 1885, in _get_spec
TypeError: 'NoneType' object is not iterable

And in the second:

Traceback (most recent call last):
  File "/home/viz/Programs/xonsh/bin/xonsh", line 3, in <module>
    main()
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/main.py", line 40, in main
    shell = Shell() if not args.norc else Shell(ctx={})
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/shell.py", line 107, in __init__
    setup_readline()
  File "/home/viz/Programs/xonsh/lib/python3.4/site-packages/xonsh/shell.py", line 28, in setup_readline
    import ctypes
  File "<frozen importlib._bootstrap>", line 2214, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2203, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "<frozen importlib._bootstrap>", line 1448, in exec_module
NameError: name 'exec' is not defined

Is there a way to make xonsh interpret exec /bin/sh as a call to exec? Dividing a builtin by something is not particularly useful anyway.

[scopatz]

Is there a way to make xonsh interpret exec /bin/sh as a call to exec? Dividing a builtin by something is not particularly useful anyway.

Agreed, but there is no way to tell from the syntax that it is a builtin.

[scopatz]

I'll think about this

[kseistrup]

This exec overloading/reassignment is also causing problems with programs like mosh if $SHELL=xonsh:

$ mosh example.com
xonsh: subprocess mode: command not found: exec
Did you mean one of the following?
    ex:     Command (/usr/bin/ex)
    xev:    Command (/usr/bin/xev)
    xexec:  Alias
    rec:    Command (/usr/bin/rec)
    etex:   Command (/usr/bin/etex)
ssh_exchange_identification: Connection closed by remote host
/usr/bin/mosh: Did not find remote IP address (is SSH ProxyCommand disabled?).

If $SHELL=/bin/sh, however, mosh succeeds.

[scopatz]

Hi @kseistrup - we actually don' overload or reassign exec to anything because this would interfere with the Python builtin. The compromise is to have an xexec alias, which acts exactly like exec, but for xonsh code. (This shows up in the above where it says that 'exec' cannot be found.)

You can always reassign this yourself to exec. For example, in the xonshrc you could do:

aliases['exec'] = aliases['xexec']

Does mosh set any environment variables that would let us know that we are running in mosh?

[kseistrup]

I'm afraid that doesn't help. The answer is still xonsh: subprocess mode: command not found: exec. And it doesn't seem mosh is seeting any environment variables.

mosh is a Perl script that uses ssh for authorization agains a remote server, then runs mosh-client with the key that it gets during authorization so that local's mosh-client talks to remote's mosh-server.

[scopatz]

After some further testing I have determined that xonsh isn't even getting to the point where the xonshrc file is being read in and executed. Something else is going on here...

[scopatz]

I have opened mobile-shell/mosh#663 for this issue, @kseistrup

[scopatz]

Ok, I have now found that mosh works well if you add the following line to your .xonshrc

aliases['exec'] = aliases['xexec']

I am running completely as the same user on localhost though. We can certainly add this alias when automatically when certain SSH environment variables are present, if you'd like. When you said that this didn't help before, what problem were you seeing exactly?

[kseistrup]

Mea culpa. I tried

aliases['exec'] = aliases['xexec']

in the terminal before running mosh and found that it didn't change anything (i.e., I still get the same xonsh: subprocess mode: command not found: exec error message). But it does indeed work when I add it to ~/.xonshrc. 😄

[vitaut]

I'm going to close this and move the discussion of the absolute path support to a separate issue.

[scopatz]

Thanks @vitaut.

Also, @kseistrup, yeah that wouldn't work. You need to put this in the rc file since a new session is started when you enter mosh. ssh was eating the stdout, which is why I thought it wasn't getting run at all.