Sure. I was going to do that yesterday, but I realized that I
didn't know how/where to do it. I assume there's a link
somewhere at www.python.org, but I haven't had a chance to look
yet.
It's already reported to the bug tracker:
http://www.python.org/sf/210599
Apparently, this has been
On 2006-02-15, Joel Hedlund [EMAIL PROTECTED] wrote:
Sure. I was going to do that yesterday, but I realized that I
didn't know how/where to do it. I assume there's a link
somewhere at www.python.org, but I haven't had a chance to look
yet.
It's already reported to the bug tracker:
Grant Edwards wrote:
I've got no complaints about the way things work, I was just
going to suggest changing the documentation to correctly
describe the way things work. Too mundane a solution?
Submit a patch, it's quick and easy and fun:
http://docs.python.org/about.html
Kent
--
On 2006-02-15, Kent Johnson [EMAIL PROTECTED] wrote:
Grant Edwards wrote:
I've got no complaints about the way things work, I was just
going to suggest changing the documentation to correctly
describe the way things work. Too mundane a solution?
Submit a patch, it's quick and easy and fun:
It didn't insert an EOF, it just caused read() to return
prematurely. You should call read() again until it receives
a _real_ EOF and returns ''.
Copy that. Point taken.
There appear to be a couple problems with this description:
1) It says that read() in blocking mode without a size
I realised there was funny indentation mishap in my previus email. My mail prog
indented the following line
signal.signal(signal.SIGWINCH, report_terminal_size_change)
while in fact in IDLE it's unindented, which makes a lot more sense:
signal.signal(signal.SIGWINCH,
On 2006-02-09, Joel Hedlund [EMAIL PROTECTED] wrote:
It didn't insert an EOF, it just caused read() to return
prematurely. You should call read() again until it receives
a _real_ EOF and returns ''.
Copy that. Point taken.
There appear to be a couple problems with this description:
1)
In article [EMAIL PROTECTED],
Grant Edwards [EMAIL PROTECTED] wrote:
2) It also says that it makes sense to continue to read a tty
after you get an EOF. That's not true. Once you get an
EOF on a tty, there's no point in reading it any more:
you'll continue to get an EOF
sys.stdin.read() will return when ... the
underyling read() call is aborted by a signal.
Not return, really? Won't it just pass an exception? I thought that was what
I was catching with the except IOError part there? I assumed that
sys.stdin.read() would only return a value properly at EOF?
On 2006-02-08, Joel Hedlund [EMAIL PROTECTED] wrote:
sys.stdin.read() will return when ... the
underyling read() call is aborted by a signal.
Not return, really?
Yes, really. On a SIGWINCH, the read() will _either_ return
currently buffered data or thrown an IOError exception. You
need to
You might want to try just setting a flag in the signal handler
to see if that prevents the I/O operations on stdin/stdout from
being interrupted.
Tried this:
source
import signal, os, sys
from terminal_info import get_terminal_size
terminal_size = get_terminal_size()
_bTerminalSizeChanged
On 2006-02-07, Joel Hedlund [EMAIL PROTECTED] wrote:
As before, the only IO case above that doesn't throw
exceptions is the uncommented one.
Yup, that's the exception. Standard practice is to catch it and
retry the I/O operation.
Hmm... I guess it's not that easy to retry IO operations
You just call the failed read() or write() again. Unless
there's some way that the read/write partially succeeded and
you don't have any way to know how many bytes were
read/written, If that's the case then Python's file object
read and write would appear to be broken by design.
Wow... I
On 2006-02-07, Joel Hedlund [EMAIL PROTECTED] wrote:
You just call the failed read() or write() again. Unless
there's some way that the read/write partially succeeded and
you don't have any way to know how many bytes were
read/written, If that's the case then Python's file object
read and
Thank you for a very quick, informative and concise response.
BTW: don't forget to attach a handler to the window-size-change
signal (SIGWINCH) so that you know when your terminal changes sizes
Do you mean something like this?
import signal, os
# terminal_info contains the example from my
On 2006-02-06, Joel Hedlund [EMAIL PROTECTED] wrote:
Thank you for a very quick, informative and concise response.
BTW: don't forget to attach a handler to the window-size-change
signal (SIGWINCH) so that you know when your terminal changes sizes
Do you mean something like this?
import
On Mon, 06 Feb 2006 15:17:43 -, Grant Edwards [EMAIL PROTECTED] wrote:
On 2006-02-06, Joel Hedlund [EMAIL PROTECTED] wrote:
[finding the terminal dimensions]
access to the termios module either. So, in the latter case
I'm back to square one, which is arbitrary guesswork.
Yes, that's
Hi all!
I use python for writing terminal applications and I have been bothered
by how hard it seems to be to determine the terminal size. What is the
best way of doing this?
At the end I've included a code snippet from Chuck Blake 'ls' app in
python. It seems to do the job just fine on my
On 2006-02-05, Joel Hedlund [EMAIL PROTECTED] wrote:
I use python for writing terminal applications and I have been
bothered by how hard it seems to be to determine the terminal
size. What is the best way of doing this?
The way used in the code you found. Alternatively, yould use
ncurses, but
Which details? We'd be happy to explain the code. Not that
you need to understand the details to use the code.
OK, why '1234' in here, and what's termios.TIOCGWINSZ, and how should I
have known this was the way too do it?
fcntl.ioctl(fd, termios.TIOCGWINSZ, '1234')
Am I interpreting C
On 2006-02-05, Joel Hedlund [EMAIL PROTECTED] wrote:
Which details? We'd be happy to explain the code. Not that
you need to understand the details to use the code.
OK, why '1234' in here, and what's termios.TIOCGWINSZ,
Second question first: TIOCGWINSZ is just a platform-defined
magic
21 matches
Mail list logo
