On 2021-01-19, Grant Edwards wrote:
>>
>> int tgetent(char *bp, const char *name);
>> int tgetflag(char *id);
>> int tgetnum(char *id);
>> char *tgetstr(char *id, char **area);
>> char *tgoto(const char *cap, int col, int row);
>> int tputs(const char *str, int affcnt, int
On 2021-01-19, Eli the Bearded <*@eli.users.panix.com> wrote:
> Putting my Unix hat on, curses is a "friendly" library around creating
> text-windowed applications. Programs like mutt use curses rather than
> raw terminal operations, programs like vi use raw terminal operations.
> Either curses or
In comp.lang.python, Greg Ewing wrote:
> On 18/01/21 3:34 am, Alan Gauld wrote:
>> The problem is terminfo is not really part of curses.
>> Curses is built on top of terminfo.
> As far as I can tell from the man pages, terminfo itself
> is just a file format. The only programmatic interfaces I
>
On 2021-01-19, Alan Gauld via Python-list wrote:
> On 18/01/2021 22:14, Random832 wrote:
>> On Fri, Jan 15, 2021, at 13:36, Alan Gauld via Python-list wrote:
>>> That could make a big difference, the putp() function specifically
>>> states that it writes to stdout.
>>
>> I think there is a reason
On 2021-01-19, Greg Ewing wrote:
> On 19/01/21 2:34 pm, Alan Gauld wrote:
>> To be fair that's a limitation of the C curses library. putp() is a
>> wrapper around tputs() even there, and you can't change what it does.
>> The gap in the curses module is that it doesn't offer the tputs()
>> option a
On 19/01/21 2:34 pm, Alan Gauld wrote:
To be fair that's a limitation of the C curses library. putp() is a
wrapper around tputs() even there, and you can't change what it does.
The gap in the curses module is that it doesn't offer the tputs()
option as an alternative.
Seems to me it would be us
On 18/01/2021 22:14, Random832 wrote:
> On Fri, Jan 15, 2021, at 13:36, Alan Gauld via Python-list wrote:
>> That could make a big difference, the putp() function specifically
>> states that it writes to stdout.
>
> I think there is a reasonable argument that this is a deficiency of the
> curses
On 2021-01-18, Random832 wrote:
> On Fri, Jan 15, 2021, at 13:36, Alan Gauld via Python-list wrote:
>> That could make a big difference, the putp() function specifically
>> states that it writes to stdout.
>
> I think there is a reasonable argument that this is a deficiency of
> the curses module.
On Fri, Jan 15, 2021, at 13:36, Alan Gauld via Python-list wrote:
> That could make a big difference, the putp() function specifically
> states that it writes to stdout.
I think there is a reasonable argument that this is a deficiency of the curses
module.
I think that the curses module should A
On 18/01/21 3:34 am, Alan Gauld wrote:
The problem is terminfo is not really part of curses.
Curses is built on top of terminfo.
As far as I can tell from the man pages, terminfo itself
is just a file format. The only programmatic interfaces I
can find for it *are* part of curses:
del_curterm(
On 2021-01-17, Grant Edwards wrote:
> On 2021-01-17, Greg Ewing wrote:
>> On 17/01/21 12:40 pm, Chris Angelico wrote:
>>> This is true. However, at some point, the boundary is crossed from
>>> Python into the C library. Something, at that point, knows. It's very
>>> common to have a flush option
On 2021-01-17, Greg Ewing wrote:
> On 17/01/21 12:40 pm, Chris Angelico wrote:
>> This is true. However, at some point, the boundary is crossed from
>> Python into the C library. Something, at that point, knows. It's very
>> common to have a flush option available, so it should be used.
>
> I'm wo
On 17/01/2021 00:02, Greg Ewing wrote:
> On 17/01/21 12:40 pm, Chris Angelico wrote:
>> This is true. However, at some point, the boundary is crossed from
>> Python into the C library. Something, at that point, knows. It's very
>> common to have a flush option available, so it should be used.
>
>
On 1/16/21, Greg Ewing wrote:
> On 17/01/21 12:40 pm, Chris Angelico wrote:
>> This is true. However, at some point, the boundary is crossed from
>> Python into the C library. Something, at that point, knows. It's very
>> common to have a flush option available, so it should be used.
>
> I'm wonde
On Sun, Jan 17, 2021 at 11:06 AM Greg Ewing wrote:
>
> On 17/01/21 12:40 pm, Chris Angelico wrote:
> > This is true. However, at some point, the boundary is crossed from
> > Python into the C library. Something, at that point, knows. It's very
> > common to have a flush option available, so it sho
On 17/01/21 12:40 pm, Chris Angelico wrote:
This is true. However, at some point, the boundary is crossed from
Python into the C library. Something, at that point, knows. It's very
common to have a flush option available, so it should be used.
I'm wondering whether the problem in this particula
On Sun, Jan 17, 2021 at 10:36 AM Greg Ewing wrote:
>
> On 16/01/21 4:17 pm, Chris Angelico wrote:
> > But somewhere along the way, you're finding that there's a problem,
> > which implies that SOMETHING is calling on C stdio. That thing,
> > surely, should be the thing responsible for flushing?
>
On 16/01/21 4:17 pm, Chris Angelico wrote:
But somewhere along the way, you're finding that there's a problem,
which implies that SOMETHING is calling on C stdio. That thing,
surely, should be the thing responsible for flushing?
The C library using stdio has no way of knowing that something
els
On 15/01/2021 21:41, Dennis Lee Bieber wrote:
> On Fri, 15 Jan 2021 13:19:26 +, Alan Gauld via Python-list
> declaimed the following:
>
>> So the native C functions work as expected.
>> Why does the Python wrapper not?
>
> Are you running Python from a plain command shell, or from some
My previous code didn't work if the terminfo entities contained delay
specifiers because the delay specifier was left in the output
datastream. The case where the terminfo description contains delays,
but the delays aren't needed can be handled by simply removing the delay
specifiers by wrapping nc
On 2021-01-16, Cameron Simpson wrote:
> On 15Jan2021 18:36, Alan Gauld wrote:
>>> One difference is that the name prompt is being written to stdout in
>>> the C version and stderr in the Python version. But I don't see why
>>> that would matter.
>>
>>That could make a big difference, the putp() f
On 2021-01-16, Greg Ewing wrote:
> On 16/01/21 7:33 am, Grant Edwards wrote:
>
>> Starting in Python 3., python's stdio file objects are _not_
>> on top of the libc FILE streams: they're directly on top of the file
>> descriptor.
>
> This sounds like rather a bad situation, because it means that
>
On 2021-01-16, Chris Angelico wrote:
> On Sat, Jan 16, 2021 at 1:36 PM Greg Ewing
> wrote:
>
>> Can something be done about this? Maybe Python stdio objects
>> should flush all the C stdio streams before writing anything?
>>
>
> Surely it should be the other way around? If you use the C stdio
>
On 2021-01-15, Grant Edwards wrote:
> On 2021-01-15, Grant Edwards wrote:
>
>> Entities that are parameterized (e.g. goto location) would need to be
>> passed through curses.tiparm() before they're decoded and printed. I'm
>> goign to try that next.
>
> The curses module doesn't expose tiparm, bu
On Sat, Jan 16, 2021 at 2:16 PM Greg Ewing wrote:
>
> On 16/01/21 3:37 pm, Chris Angelico wrote:
> > Surely it should be the other way around? If you use the C stdio
> > streams, flush them after use.
>
> 1. You might not know that you're (implicitly) using C stdio.
>
> 2. There doesn't seem to be
On 16/01/21 3:37 pm, Chris Angelico wrote:
Surely it should be the other way around? If you use the C stdio
streams, flush them after use.
1. You might not know that you're (implicitly) using C stdio.
2. There doesn't seem to be an easy way to flush C stdio from
Python any more.
--
Greg
--
ht
On 15Jan2021 18:36, Alan Gauld wrote:
>> One difference is that the name prompt is being written to stdout in
>> the C version and stderr in the Python version. But I don't see why
>> that would matter.
>
>That could make a big difference, the putp() function specifically
>states that it writes to
On Sat, Jan 16, 2021 at 1:36 PM Greg Ewing wrote:
>
> On 16/01/21 7:33 am, Grant Edwards wrote:
> > Starting in Python 3., python's stdio file objects are _not_
> > on top of the libc FILE streams: they're directly on top of the file
> > descriptor.
>
> This sounds like rather a bad situation, bec
On 16/01/21 7:33 am, Grant Edwards wrote:
Starting in Python 3., python's stdio file objects are _not_
on top of the libc FILE streams: they're directly on top of the file
descriptor.
This sounds like rather a bad situation, because it means that
any C library using stdio is going to interact b
On 2021-01-15, Grant Edwards wrote:
> Entities that are parameterized (e.g. goto location) would need to be
> passed through curses.tiparm() before they're decoded and printed. I'm
> goign to try that next.
The curses module doesn't expose tiparm, but you can use tparm
instead:
#!/usr/bin/p
On 2021-01-15, Grant Edwards wrote:
> On 2021-01-15, Alan Gauld via Python-list wrote:
>> On 15/01/2021 17:31, Grant Edwards wrote:
>>
>>> I suspect that the problem is that putp is writing to the libc
>>> "stdout" FILE stream that's declaredin . That stream
>>> layer/object has buffering that is
On 2021-01-15, Alan Gauld via Python-list wrote:
> On 15/01/2021 17:31, Grant Edwards wrote:
>
cur.putp(cls)
name = input("Hello, what's your name? ")
cur.putp(bold)
print("Nice to meet you ", name)
>
>
>>> putp(clr);
>>> putp(bold);
>>> printf("Enter a name: "
On 2021-01-15, Alan Gauld via Python-list wrote:
> On 15/01/2021 17:31, Grant Edwards wrote:
>
>> I suspect that the problem is that putp is writing to the libc
>> "stdout" FILE stream that's declaredin . That stream
>> layer/object has buffering that is invisible to Python.
>
> That would indeed
On 15/01/2021 17:31, Grant Edwards wrote:
>>> cur.putp(cls)
>>> name = input("Hello, what's your name? ")
>>>
>>> cur.putp(bold)
>>> print("Nice to meet you ", name)
>> putp(clr);
>> putp(bold);
>> printf("Enter a name: ");
>> fgets(line, sizeof(line),stdin);
>>
>> printf("He
On 2021-01-15, Grant Edwards wrote:
> I suspect that the problem is that putp is writing to the libc
> "stdout" FILE stream that's declaredin . That stream
> layer/object has buffering that is invisible to Python. Python's
> sys.stdout.flush() is flushing the Python file object's output buffers
>
On 2021-01-15, Alan Gauld via Python-list wrote:
> On 14/01/2021 16:12, Alan Gauld via Python-list wrote:
>
>> #
>> import curses as cur
>> cur.setupterm()
>>
>> bold = cur.tigetstr('bold')
>> cls = cur.tigetstr('clear')
>>
>> cur.putp(cls)
>> name = input("Hello, what's your nam
On 14/01/2021 16:12, Alan Gauld via Python-list wrote:
> #
> import curses as cur
> cur.setupterm()
>
> bold = cur.tigetstr('bold')
> cls = cur.tigetstr('clear')
>
> cur.putp(cls)
> name = input("Hello, what's your name? ")
>
> cur.putp(bold)
> print("Nice to meet you ", name)
>
On 14/01/2021 22:11, Grant Edwards wrote:
> Or use a terminfo library:
>
> https://github.com/DirectXMan12/py-terminfo
>
> It _may_ be possible to use ncurses to get the terminfo strings
> required for various functions without actually having ncurses to any
> I/O, but I've never tried that...
On 14/01/2021 23:08, Grant Edwards wrote:
> Alternatively, I think you can use the ncurses library to retrieve the control
> strings (just don't use any ncurses input/output calls), like this example
> from
> https://stackoverflow.com/questions/6199285/tput-cup-in-python-on-the-commandline:
>
>
On 14/01/2021 21:30, Barry Scott wrote:
>> During lockdown I've been digging deeper into the curses module
>> and lately into the ti family of functions that reside there.
> It seems that curses does not allow you to mix raw stdin/stdout with its
> calls.
That's true of curses after you cal
On 2021-01-14, Eli the Bearded <*@eli.users.panix.com> wrote:
> When I've wanted to do simple things like bold and clear, I've used the
> tput(1) tool. You can capture stdout from the tool and use the output
> over and over. Typically I've done this in shell scripts:
>
> #!/bin/sh
> bold=$(tput sm
On 2021-01-14, Barry Scott wrote:
> It seems that curses does not allow you to mix raw stdin/stdout with
> its calls. (got that idea from a quick web search).
That is definitely the case. Output in curses is done to an in-memory
virtual terminal screen. Optimized output is then sent (at some po
In comp.lang.python, Barry Scott wrote:
> Alan Gauld via Python-list wrote:
>> I've written a short program that is supposed to
>> - *clear the screen*,
>> - read some input
>> - display the result in a message *highlighted in bold*.
>> - get input to end the program
> It seems that curses does
> On 14 Jan 2021, at 16:12, Alan Gauld via Python-list
> wrote:
>
> During lockdown I've been digging deeper into the curses module
> and lately into the ti family of functions that reside there.
>
> I've written a short program that is supposed to
> - *clear the screen*,
> - read some i
During lockdown I've been digging deeper into the curses module
and lately into the ti family of functions that reside there.
I've written a short program that is supposed to
- *clear the screen*,
- read some input
- display the result in a message *highlighted in bold*.
- get input to end the
45 matches
Mail list logo
