-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Possible pty detection bug #303
Comments
**** (mbravo) posted: here's my traceback (occurs with 1.0.0 when piping output to grep): Traceback (most recent call last): File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/main.py", line 537, in main commands[name](*args, **kwargs) File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/decorators.py", line 75, in inner_decorator return func(*args, **kwargs) File "/Users/mbravo/Documents/mgmt/fabric/playkot/fabfile.py", line 130, in mem_alldb run('free') File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/network.py", line 304, in host_prompting_wrapper return func(*args, **kwargs) File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py", line 916, in run return _run_command(command, shell, pty, combine_stderr) File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py", line 840, in _run_command combine_stderr) File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py", line 726, in _execute rows, cols = _pty_size() File "/Library/Python/2.6/site-packages/Fabric-1.0.0-py2.6.egg/fabric/operations.py", line 50, in _pty_size buffer) IOError: [Errno 25] Inappropriate ioctl for device on 2011-03-07 at 02:05pm EST |
Joel Eidsath (joel@counsyl.com) posted: I see the same issue. Running python 2.6.5 and fabric 1.0.0 on an Ubuntu 10.04 box. The issue seems to come up on all remote hosts that I have tested it on (Ubuntu and Centos). Here's a sample fabfile that reproduces the bug reliably:
Here is the output:
on 2011-03-17 at 02:43pm EDT |
Joel Eidsath (joel@counsyl.com) posted: And here's a patch which fixes the problem for me. on 2011-03-17 at 03:07pm EDT |
Derrick Petzold (derrickpetzold) posted: fyi I also ran into this and the patch fixed it. on 2011-04-06 at 07:18pm EDT |
Morgan Goose (goosemo) posted: Do you have a branch with said patch in it? on 2011-04-06 at 11:24pm EDT |
Joel Eidsath (joel@counsyl.com) posted: The inability to do the following seems like a lot bigger problem than just a "wart": fab somecommand | tee output.txt How exactly are we supposed to log the results of fab commands? At least change the code to ignore all IOErrors (like patch does) until this can be resolved more gracefully. on 2011-08-17 at 12:21am EDT |
Jeff Forcier (bitprophet) posted: "Wart" is a designation commonly used to mean "seriously ugly", as in "this is something that stands out to almost all users as very broken or lacking and is a frequent source of frustration". On this tracker specifically, it's used as the highest priority and as an indicator that such issues should be taken care of ASAP if possible. So switching from Normal to Wart was an upgrade of priority (specifically, it's been reported even more widely lately and is clearly affecting more than a handful of users.) I understand your frustration, but taking a demanding tone is rarely productive when dealing with volunteers. You'd get way more sympathy from me (and probably others) with "this still affects me and isy making my life difficult -- any update on release? Would it make sense to implement a stopgap solution?" instead of being huffy about it :) on 2011-08-17 at 11:12am EDT |
Joel Eidsath (joel@counsyl.com) posted: I did not mean to come across as demanding -- written text on the internet rarely communicates our feelings as well as the same words would would over dinner or a pint of beer, and I'd appreciate it if you interpreted mine with a spirit of charity. I wasn't asking anyone to do any work for me and did not mean to be taken that way. I wrote the patch above and apply it on all my builds. The problem is gone for me. It's only an issue for your other users. As an aside, 'wart' generally means "blemish, or imperfection" unless you are referring to the Papilloma virus. Maybe no one but me will ever be confused by this, but you guys are the only ones the internet with this usage: Google Search: "wart bug tracking" on 2011-08-17 at 12:17pm EDT |
Jeff Forcier (bitprophet) posted: Joel Eidsath wrote:
Fair enough. I was keying off the phrases "How exactly" and "At least" which both tend to come across as kind of complain-y. But you're right that text communication tends to confuse things.
That's surprising, because I had the vague sense that I'd heard other folks use it in the same way that we are; otherwise I'm not sure why I would have defaulted to using it. I still think it fits: it's something that stands out as being ugly. Not sure what other word would be simple and still imply "highest priority" or "keep an eye out for solutions for this currently unsolvable and shitty problem". Open to suggestions :) we're switching to Github Issues which is as good a time as any to change terminology. (Though this is the first time I remember somebody thinking Wart was a downgrade instead of an upgrade, FWIW.) on 2011-08-17 at 12:34pm EDT |
Caused #303, and also breaks inside bpython, as it happens.
Description
IRC user
djill_
encounters problems in 1.0 (but not 0.9) when piping Fabric output totee
, e.g.fab [options] [task names] | tee [filename]
.This is his traceback:
That says to me that it's a bug in how we try to update the remote pty based on the local one; if one's stdout/stderr is going to a shell pipe and not a terminal, that could definitely be causing that IOError.
Hopefully a quick fix; though given that it's an IOError with "invalid argument" (which is kind of generic) we may need to find a way of testing beforehand and skipping the pty stuff, instead of simply adding a try/catch.
EDIT: Michael Bravo has a similar/same issue when piping Fabric to
grep
, though his error wasIOError: [Errno 25] Inappropriate ioctl for device
(on the exact same line). Not sure if that's an argument for or against the test-first vs catch-IOErrors approach...Originally submitted by Jeff Forcier (bitprophet) on 2011-03-07 at 10:25am EST
Attachments
Relations
The text was updated successfully, but these errors were encountered: