Jobs with pipes not working on fresh install of xonsh

[gotgenes]

I believe this is related to #1330 but am opening a new issue in case it is not.

I'm encountering this issue on OS X with xonsh 0.4.7 installed via Homebrew. I did not run through the xonfig wizard:

clasher@clasher-MBP ~/development $ xonfig
+------------------+-----------------+
| xonsh            | 0.4.7           |
| Git SHA          | None            |
| Python           | 3.5.2           |
| PLY              | 3.7             |
| have readline    | True            |
| prompt toolkit   | None            |
| shell type       | readline        |
| pygments         | None            |
| on posix         | True            |
| on linux         | False           |
| on darwin        | True            |
| on windows       | False           |
| on cygwin        | False           |
| is superuser     | False           |
| default encoding | utf-8           |
| xonsh encoding   | utf-8           |
| encoding errors  | surrogateescape |
+------------------+-----------------+

I discovered this while running the following command in xonsh:

which xonsh | sudo tee -a /etc/shells

I did not receive a prompt for a password from sudo (which I do get from Bash).

Following this I checked to see if basic piping itself was broken with

echo junk | less

This did not open less in the terminal. I now had two stuck processes; attempting to exit xonsh with Ctrl-D then became impossible

clasher@clasher-MBP ~/development $
xonsh: there are unfinished jobs
-----
[2]+ stopped: echo junk | less (66547)
[1]- stopped: which xonsh | sudo tee -a /etc/shells (66444)
-----
Type "exit" or press "ctrl-d" again to force quit.
clasher@clasher-MBP ~/development $ xonsh: For full traceback set: $XONSH_SHOW_TRACEBACK = True
PermissionError: [Errno 1] Operation not permitted
clasher@clasher-MBP ~/development $
xonsh: there are unfinished jobs
-----
[2]+ stopped: echo junk | less (66547)
[1]- stopped: which xonsh | sudo tee -a /etc/shells (66444)
-----
Type "exit" or press "ctrl-d" again to force quit.
clasher@clasher-MBP ~/development $ xonsh: For full traceback set: $XONSH_SHOW_TRACEBACK = True
PermissionError: [Errno 1] Operation not permitted

The only way to get out of xonsh was to kill those jobs using their PIDs. Following that, I could use Ctrl-D to exit.

[scopatz]

Thanks for reporting @gotgenes! I believe that we have just pushed fixes to these to master. Please feel free to try out master and let us know how it goes. Sorry about this!

[PaulReiber]

Hi Anthony

I've just rebuilt the latest master and did some quick tests

pbr@mongo ~/xonsh master $ xonfig
+------------------+-----------------+
| xonsh | 0.4.7.dev1131 |
| Git SHA | 30e0b91 |
| Python | 3.5.2 |
| PLY | 3.8 |
| have readline | True |
| prompt toolkit | None |
| shell type | readline |
| pygments | None |
| on posix | True |
| on linux | True |
| distro | Ubuntu |
| on darwin | False |
| on windows | False |
| on cygwin | False |
| is superuser | False |
| default encoding | utf-8 |
| xonsh encoding | utf-8 |
| encoding errors | surrogateescape |
+------------------+-----------------+
pbr@mongo ~/xonsh master $ env|vim -
pbr@mongo ~/xonsh master $

Note the output of "env" should have been shown by the vim program as
it was given the option "-" for which
vim usually reads its stdin until it's done, then goes fullscreen
interactive on the resulting data.

The generalization is - "any-command | vim -" should put you in vim on
the output of any-command

Hope this helps. If there are any specific other tests you'd like run
just let me know.

Kind regards,

_Paul Reiber_http://about.me/reiber

On Wed, Oct 5, 2016 at 5:52 PM, Anthony Scopatz notifications@github.com
wrote:

Thanks for reporting @gotgenes https://github.com/gotgenes! I believe
that we have just pushed fixes to these to master. Please feel free to try
out master and let us know how it goes. Sorry about this!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1801 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADlQGFdO3gsNwZYZvonMu6Weq1eVeVXks5qxEZigaJpZM4KPYLP
.

[scopatz]

vim is special cased and has some weird effects because of that. I am trying to figure out what is going wrong, but the other cases should work. Also note that when you do cmd | vim -, there are are two stdin streams. This is messing us up somehow.

[gotgenes]

@scopatz Overall it does look like this was fixed on latest master.

clasher@clasher-MBP ~/development $ xonfig
+------------------+-----------------+
| xonsh            | 0.4.7.dev175    |
| Git SHA          | 9e67c21         |
| Python           | 3.5.2           |
| PLY              | 3.8             |
| have readline    | True            |
| prompt toolkit   | 1.0.7           |
| shell type       | prompt_toolkit  |
| pygments         | 2.1.3           |
| on posix         | True            |
| on linux         | False           |
| on darwin        | True            |
| on windows       | False           |
| on cygwin        | False           |
| is superuser     | False           |
| default encoding | utf-8           |
| xonsh encoding   | utf-8           |
| encoding errors  | surrogateescape |
+------------------+-----------------+

echo junk | less brings up less as expected. There is a traceback emitted for use of sudo after the pipe, though:

clasher@clasher-MBP ~/development $ which xonsh | sudo tee -a /etc/shells
Password:Exception in thread Thread-52:
Traceback (most recent call last):
  File "/usr/local/Cellar/python3/3.5.2_2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/threading.py", line 914, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.5/site-packages/xonsh/__amalgam__.py", line 9429, in run
    proc.terminate()
  File "/usr/local/Cellar/python3/3.5.2_2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/subprocess.py", line 1782, in terminate
    self.send_signal(signal.SIGTERM)
  File "/usr/local/Cellar/python3/3.5.2_2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/subprocess.py", line 1777, in send_signal
    os.kill(self.pid, sig)
PermissionError: [Errno 1] Operation not permitted

Note I am actually still being prompted for my password, I can still enter my password, and the command will succeed. I was caught off guard, though, by the traceback, and didn't realize xonsh was actually still waiting for my password. I have filed a separate issue for this, #1806.

[mitnk]

@scopatz I'm on mac too and the piped commands hangs forever. like this one:

$ ps ax | wc -l

$ xonfig

+------------------+-----------------+
| xonsh            | 0.4.7.dev1300   |
| Git SHA          | 3f45378         |
| Python           | 3.5.2           |
| PLY              | 3.7             |
| have readline    | True            |
| prompt toolkit   | 1.0.4           |
| shell type       | readline        |
| pygments         | 2.1.3           |
| on posix         | True            |
| on linux         | False           |
| on darwin        | True            |
| on windows       | False           |
| on cygwin        | False           |
| is superuser     | False           |
| default encoding | utf-8           |
| xonsh encoding   | utf-8           |
| encoding errors  | surrogateescape |
+------------------+-----------------+

[gforsyth]

@gotgenes could you try out the latest master and see if this issue persists? Thanks!

[gotgenes]

@gforsyth Latest behavior causes less to lose the ability to register keypresses when performing the following:

echo junk | less

To gain control back of the terminal, I must execute a Ctrl+C, followed by two presses of Q.

This behavior does not seem to be exhibited when running something that takes up a screenful or more with less, like

cat some_large_file.txt | less

[gforsyth]

Hey @gotgenes, thanks. I can confirm that behavior. I'm inclined to close this out and open a new issue for it so we can keep better track of the individual problems.

Question for you, if you open a file with less that takes up more than a screenful and scroll to the bottom and then try to scroll down further, do you also lose keypresses?

[gotgenes]

@gforsyth

I'm inclined to close this out and open a new issue for it so we can keep better track of the individual problems.

Yes, I recommend marking this issue as resolved. I will file a new issue regarding the lost keypresses.