[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-
From: |
Rin Okuyama |
Subject: |
Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z |
Date: |
Thu, 23 Nov 2017 11:14:37 +0900 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 2017/11/23 5:47, Chet Ramey wrote:
In bash-4.4/readline-7.0, there is a new public function:
rl_pending_signal(), which will return the value of _rl_caught_signal.
There's no good public way to call _rl_signal_handler(). If you don't
want to mess with calling a semi-private readline function, you can
just call rl_getc(), since the first thing it does is check for and
handle any pending signals.
Hmm, in the 1st ifdef block in this function,
On 2017/11/22 19:07, Rin Okuyama wrote:
int getc_wrapper(FILE *fp) {
fd_set fds;
int fd = fileno(fp);
int ierr;
if (external_fd >= 0) {
do {
FD_ZERO(&fds);
FD_SET(fd, &fds);
FD_SET(external_fd, &fds);
#ifdef HAVE_LIBREADLINE
extern int _rl_caught_signal;
void _rl_signal_handler(int);
if (_rl_caught_signal)
_rl_signal_handler(_rl_caught_signal);
#endif
ierr = select(external_fd + 1, &fds, 0, 0, NULL);
...
} while (!FD_ISSET(fd, &fds));
}
#ifdef HAVE_LIBREADLINE
int rl_getc(FILE*);
return rl_getc(fp);
#else
return getc(fp);
#endif
}
_rl_signal_handler() cannot be replaced with rl_getc(fp) neither with
fp = stdin, stdout, nor stderr. If so, the caller waits input from tty.
In order to avoid this side effect, we probably need some trick like:
#ifdef HAVE_LIBREADLINE
FILE *fp = fopen("/dev/null", "r");
(void)rl_getc(fp);
(void)fclose(fp);
#endif
This hack works fine, but the previous version may be better...
Also, I found that the problem is not peculiar to macOS; gnuplot does
not suspend by Control-z on NetBSD 8-current. Could you implement some
public function to call _rl_signal_handler() by any chance? It would
help me a lot.
rin
- [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Rin Okuyama, 2017/11/21
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Chet Ramey, 2017/11/21
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Rin Okuyama, 2017/11/22
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Chet Ramey, 2017/11/22
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z,
Rin Okuyama <=
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Chet Ramey, 2017/11/22
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Rin Okuyama, 2017/11/23
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Chet Ramey, 2017/11/24
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Rin Okuyama, 2017/11/26
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Chet Ramey, 2017/11/27
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Rin Okuyama, 2017/11/28
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Chet Ramey, 2017/11/28
- Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z, Rin Okuyama, 2017/11/29