-
Notifications
You must be signed in to change notification settings - Fork 73
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
infinity cycle in screen initialization, when pdcurses app is used as pager #256
Comments
But now, I look on
the all parameters are ignored :-/ Is there possibility how to use input from some specified stream instead just Minimally the following code is partially wrong:
There should be STDOUT_FILENO used, because for you, the dimensions are interesting for output. |
If it isn't then this function should likely check the input parameter and return ERR if it isn't NULL / stdin.
|
No, there is not any check. Unfortunately, for using pspg for MSWin I need fully implemented This is fundamental functionality for pager. On second hand, the complex application written primary for ncurses like |
Um. An interesting point... I had not really considered the use for that redirection in PDCurses, which does not follow the At least for input, I think we can get this to work. The It occurs to me that one might have redirected
Right now, that works with if( SP->opaque->input_fp)
fread() from SP->opaque->input_fd;
else if( !isatty( STDIN_FILENO))
fread() from STDIN;
else /* it's a for-real terminal */
read the character using the platform-dependent code; If that makes sense to you, I don't think it would be difficult to implement it, first for VT (which, I gather, is your current focus). We could then add it to other platforms. We also have the question of what it means if you redirect the output. I don't have an answer for that one yet. The question has yet to arise. If it does, it will warrant discussion under a new issue. In the meantime, I agree with @GitMensch that we should return |
It makes at least sense to me ;-)
Currently redirecting the output raises an error because col/lines is zero or the type does not match, see |
ne 18. 12. 2022 v 17:32 odesílatel Simon Sobisch ***@***.***>
napsal:
If that makes sense to you, I don't think it would be difficult to
implement it, first for VT (which, I gather, is your current focus). We
could then add it to other platforms.
It makes at least sense to me ;-)
:-)
I'll check it immediately
We also have the question of what it means if you redirect the output. I
don't have an answer for that one yet.
I was wrong, there is redirected input (in this case)
When you use write pager, like "less" or "more", you cannot to read from
stdin, but you have to read from tty
example:
classic app mode - `pspg -f xxx` .. both stdin, stdout are attached to tty
pager mode - `cat xxx | pspg` .. stdin is attached to pipe, but interactive
input should be redirected to tty.
The pattern how to solve is using newterm function instead initscr, where
you can explicitly specify input stream,
Theoretically, it can be the same with output too.
Regards
Pavel
… Currently redirecting the output raises an error because col/lines is zero
or the type does not match, see PDC_scr_open(). This has come up before
"multiple times", related are also #15
<#15> and #50
<#50>.
—
Reply to this email directly, view it on GitHub
<#256 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEFO4YWSA6FBCYU6W2VHELWN44BDANCNFSM6AAAAAATCODGOM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Yup, that's what I'm seeing. The situation is more complicated than my proposed remedy suggests. For the initial issue raised by Pavel, we should have no serious problem. We will read from the actual terminal when we want (for example) to find out how many lines and columns the terminal has, and read from the file specified by Input file redirection complicates this, because we lose access to the terminal. We send a command to inquire about the screen size, and the terminal replies, but we don't "see" it because our input is coming from the redirected input. A bit of searching for how one gets a file descriptor to the "real" terminal hasn't turned up anything useful yet. I assume there's a way to do it, though, and will continue looking. Interestingly, one can get output redirection to work by simply modifying the line const int stdout_fd = 0; in the Properly speaking, what we need is some sort of if( isatty( STDOUT_FILENO)) /* stdout is a tty; use stdout */
return( STDOUT_FILENO);
else if( isatty(STDERR_FILENO)) /* stdout isn't a tty, but stderr is; use stderr */
return( STDERR_FILENO);
else /* both are redirected, and we're out of options */
perror( "Both stdout and stderr are redirected"); In Windows, we'd use if( FILE_TYPE_CHAR == GetFileType( GetStdHandle( STD_OUTPUT_HANDLE))) to test for tty-ness. (I think. Just gave it a try under Wine, and it failed. But Wine's console support isn't perfect.) |
changing STDIN to 2 - redirect to stderr - and to tty allows to start pspg in pager mode. But it crashes on assert
|
Sorry, I've mixed issues here. The idea was to support redirected output by changing The issue you initially raised (and which it sounds as if is still your focus) is what to do if To address a further issue you didn't raise (sorry!), I can't think of a use case for |
here is minimalistic very ugly hack patch. With this patch, the pspg can be used as pager. Unfortunately, it fully breaks keyboard - only basic ascii keys (pspg commands) works. I think so reason is missing settings for input stream (I opening stream just for any key):
So probably there are not any other dependencies, and reading from tty device should to work. |
Thank you. You're right, it doesn't quite work, but I think it may be putting us on the right track. The idea of duplicating |
út 20. 12. 2022 v 20:20 odesílatel Bill Gray ***@***.***>
napsal:
Thank you. You're right, it doesn't quite work, but I think it may be
putting us on the right track. The idea of duplicating stderr and opening
it for reading had not occurred to me... actually, I'd always thought of
stderr (and stdout) as being things you wrote to, not read from.
I read about this trick when I wrote pspg. It is not my idea. The stream by
itself is not important, you need to connect the correct device.
pspg uses code (and similar code is used by less, more, ... )
```
bool
open_tty_stream(void)
{
#ifndef __APPLE__
f_tty = fopen("/dev/tty", "r+");
#endif
if (!f_tty)
{
f_tty = fopen(ttyname(fileno(stdout)), "r");
if (!f_tty)
{
if (isatty(fileno(stderr)))
f_tty = stderr;
}
else
close_f_tty = true;
}
else
close_f_tty = true;
return f_tty != NULL;
}
```
Now this code is well tested (and used) on almost all Unix- like systems,
and in almost all situations.
… —
Reply to this email directly, view it on GitHub
<#256 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEFO4YAX3L6QZGMWP67D23WOIBIJANCNFSM6AAAAAATCODGOM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I am able to run
I am not able to test other platforms, and I am sure, so this patch is not well integrated to pdcurses well. Just it shows, so there is an possibility to work correctly, and necessity changes are not too big. I tested it on VT because Linux and VT is my native platform, but I did this work as initial step for porting |
…t manages this by sending output to stderr, so if you redirect stderr in Windows, or both stdout and stderr in Linux or MacOS, it'll still fail. Motivated by issue #256, which is about input (so this doesn't actually address that issue.)
…y in the VT platform at present). A partial fix for issue #256. If this works, we can extend it to the other platforms.
…o test the ability to redirect input in newterm() (see preceding commit) for the fix to issue #256.
…256) pointed out that it should use STDOUT_FILENO.
Finally got around to fixing (I'm fairly sure) your original issue : Also, the fix I made applies only to VT and Linux framebuffer/DRM at present; once we've confidence in it, it should be easy enough to extend it to other platforms. |
pá 6. 1. 2023 v 3:43 odesílatel Bill Gray ***@***.***> napsal:
Finally got around to fixing (I'm fairly sure) your original issue : newterm(
(ignored), stdout, non-stdin) will now work. Still need to pull your code
in from your above comment to allow one to do 'traditional' command-line
input redirection, though.
Also, the fix I made applies only to VT and Linux framebuffer/DRM at
present; once we've confidence in it, it should be easy enough to extend it
to other platforms.
Unfortunately it doesn't work, because not the input from tty doesn't work.
0x00007f4fe6dc6021 in __GI___libc_read (fd=5, buf=0x84cae0, nbytes=4096) at
../sysdeps/unix/sysv/linux/read.c:26
Downloading 0.00 MB source file
/usr/src/debug/glibc-2.36-8.fc37.x86_64/io/../sysdeps/unix/sysv/linux/read.c
26 return SYSCALL_CANCEL (read, fd, buf, nbytes);
(gdb) bt
#0 0x00007f4fe6dc6021 in __GI___libc_read (fd=5, buf=0x84cae0,
nbytes=4096) at ../sysdeps/unix/sysv/linux/read.c:26
#1 0x00007f4fe6d4eee6 in _IO_new_file_underflow (fp=0x80e3b0) at
/usr/src/debug/glibc-2.36-8.fc37.x86_64/libio/libioP.h:947
#2 0x00007f4fe6d4ff06 in __GI__IO_default_uflow (fp=0x80e3b0) at
/usr/src/debug/glibc-2.36-8.fc37.x86_64/libio/libioP.h:947
#3 0x00007f4fe6ed1555 in check_key (c=0x7ffd2a5eb0b8) at ../vt/pdckbd.c:53
#4 0x00007f4fe6ed1acc in PDC_get_key () at ../vt/pdckbd.c:386
#5 0x00007f4fe6ed202a in PDC_get_key () at ../vt/pdckbd.c:517
#6 0x00007f4fe6ebddef in wgetch (win=0x836010) at ../pdcurses/getch.c:541
#7 0x000000000042d0d6 in get_ncurses_event ***@***.***=0x7ffd2a5eb620,
***@***.***=0x7ffd2a5eb22e,
I tested last version, and now it starts and doesn't hangs on
initialization, but the input is broken
when I use pspg in pager mode, it doesn't work ever. when I use pspg in
classic mode, it works, but using mouse click hangs in read
So last changes fixes issue with start, but now, it works worse than before
Regards
Pavel
… —
Reply to this email directly, view it on GitHub
<#256 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEFO435JIYSQ3MKNTP66BTWQ6BFVANCNFSM6AAAAAATCODGOM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
pá 6. 1. 2023 v 5:11 odesílatel Pavel Stehule ***@***.***>
napsal:
pá 6. 1. 2023 v 3:43 odesílatel Bill Gray ***@***.***>
napsal:
> Finally got around to fixing (I'm fairly sure) your original issue : newterm(
> (ignored), stdout, non-stdin) will now work. Still need to pull your
> code in from your above comment to allow one to do 'traditional'
> command-line input redirection, though.
>
> Also, the fix I made applies only to VT and Linux framebuffer/DRM at
> present; once we've confidence in it, it should be easy enough to extend it
> to other platforms.
>
Unfortunately it doesn't work, because not the input from tty doesn't work.
0x00007f4fe6dc6021 in __GI___libc_read (fd=5, buf=0x84cae0, nbytes=4096)
at ../sysdeps/unix/sysv/linux/read.c:26
Downloading 0.00 MB source file
/usr/src/debug/glibc-2.36-8.fc37.x86_64/io/../sysdeps/unix/sysv/linux/read.c
26 return SYSCALL_CANCEL (read, fd, buf, nbytes);
(gdb) bt
#0 0x00007f4fe6dc6021 in __GI___libc_read (fd=5, buf=0x84cae0,
nbytes=4096) at ../sysdeps/unix/sysv/linux/read.c:26
#1 0x00007f4fe6d4eee6 in _IO_new_file_underflow (fp=0x80e3b0) at
/usr/src/debug/glibc-2.36-8.fc37.x86_64/libio/libioP.h:947
#2 0x00007f4fe6d4ff06 in __GI__IO_default_uflow (fp=0x80e3b0) at
/usr/src/debug/glibc-2.36-8.fc37.x86_64/libio/libioP.h:947
#3 0x00007f4fe6ed1555 in check_key (c=0x7ffd2a5eb0b8) at ../vt/pdckbd.c:53
#4 0x00007f4fe6ed1acc in PDC_get_key () at ../vt/pdckbd.c:386
#5 0x00007f4fe6ed202a in PDC_get_key () at ../vt/pdckbd.c:517
#6 0x00007f4fe6ebddef in wgetch (win=0x836010) at ../pdcurses/getch.c:541
#7 0x000000000042d0d6 in get_ncurses_event ***@***.***=0x7ffd2a5eb620,
***@***.***=0x7ffd2a5eb22e,
I tested last version, and now it starts and doesn't hangs on
initialization, but the input is broken
when I use pspg in pager mode, it doesn't work ever. when I use pspg in
classic mode, it works, but using mouse click hangs in read
it is strange - using mouse wheel is ok, but mouse click breaks
synchronizations, and it falls to infinity cycle of read
So last changes fixes issue with start, but now, it works worse than before
you can try to use pspg for check
pspg -f tests/pg_class.txt # -- classic mode
cat tests/pg_class.txt | pspg -- pager mode
There are PDCurses.md about compilation pspg with pdcurses
Regards
Pavel
…
Regards
Pavel
> —
> Reply to this email directly, view it on GitHub
> <#256 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAEFO435JIYSQ3MKNTP66BTWQ6BFVANCNFSM6AAAAAATCODGOM>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
Ah, hang on, I see what you mean... I was being quite dense here; it's nowhere near as simple as what I added. A workaround you might consider : the WinGUI, SDL1/2, and X11 ports ought to work with paging programs without much trouble. They look for keyboard/mouse events via the Win32 API or SDLn or X11 libraries, rather than reading from For example, I patched --- a/demos/testcurs.c
+++ b/demos/testcurs.c
@@ -162,6 +162,13 @@ int main(int argc, char *argv[])
case 'z':
report_mouse_movement = TRUE;
break;
+ case 'i':
+ {
+ char buff[80];
+
+ if( fgets( buff, sizeof( buff), stdin))
+ printf( "Got '%s'\n", buff);
+ }
default:
break; and ran WinCon says "Redirection is not supported" (this is a known issue, and causes grief in some situations.) I think the DOS port would work, since it reads keys and mouse via BIOS rather than So for your original goal of getting |
There is little bit unhappy written initialization. Almost all code is called from With patch the pdcurses works with pspg well in both modes:
|
should be fully fixed by 9c16db9 |
I try to use pdcurses in application with redirected
stdin
(cat file| myapp
)there is some pseudocode like
This code works only when f_tty is same like stdin. In other cases It hangs in cycle
PDC_get_rows
returns always-1
Setting correct
resize_term(size.ws_row, size.ws_col)
doesn't helpbacktrace is:
The text was updated successfully, but these errors were encountered: