Re: Terminal line discipline is broken [sorta]
On Sun, 10 Jun 2001, Valentin Nechayev wrote: > Thu, Jun 07, 2001 at 12:04:10, bde (Bruce Evans) wrote about "Re: Terminal line >discipline is broken [sorta]": > > > This may be a bug in tcsh. > > Do you really think that shell should not modify signal handling policy > which he obtained as legacy from login? And application which resets > them to appropriate position is buggy? Non-interactive shells certainly shouldn't unblock/unignore blocked/ignored signals. I think it doesn't matter much for interactive shells. Login would only change the system defaults if it is broken. > My ktracing of bash (2.04) shows that it isn't really set procmask > to own values, but uses legacy value. Maybe I'm wrong, but this seems > that sh & bash are buggy, not tcsh. Bash does much more initialization for signals than sh. Maybe it knows what it is doing :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Terminal line discipline is broken [sorta]
Thu, Jun 07, 2001 at 12:04:10, bde (Bruce Evans) wrote about "Re: Terminal line discipline is broken [sorta]": > This may be a bug in tcsh. Do you really think that shell should not modify signal handling policy which he obtained as legacy from login? And application which resets them to appropriate position is buggy? > > It is very strange, but control keys [^C,^Z etc] no longer work (nop) > > in the /bin/sh and bash2 after today's build/installworld. I see this > > misbehaviour on two machines. > PAM now blocks keyboard signals when reading the password, and usually > forgets to unblock them. I use the workaround of backing out the broken > code (rev.1.4 of /usr/src/contrib/libpam/libpam_misc/misc_conv.c). > > Even more strange that /bin/tcsh doesn't > > have this problem. My ktracing of bash (2.04) shows that it isn't really set procmask to own values, but uses legacy value. Maybe I'm wrong, but this seems that sh & bash are buggy, not tcsh. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM forgets to unblock signals [was Terminal line discipline is broken [sorta]]
> That explains... Attached patch solved the problem for me. I have a functionally similar but less clean patch in BDE's court for testing. Thanks for letting me know this works - I'll commit it. M > Content-Type: text/plain; charset=koi8-r; > name="misc_conv.c.diff" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="misc_conv.c.diff" -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM forgets to unblock signals [was Terminal line discipline is broken [sorta]]
Bruce Evans wrote:
> On Wed, 6 Jun 2001, Maxim Sobolev wrote:
>
> > It is very strange, but control keys [^C,^Z etc] no longer work (nop)
> > in the /bin/sh and bash2 after today's build/installworld. I see this
> > misbehaviour on two machines.
>
> PAM now blocks keyboard signals when reading the password, and usually
> forgets to unblock them. I use the workaround of backing out the broken
> code (rev.1.4 of /usr/src/contrib/libpam/libpam_misc/misc_conv.c).
That explains... Attached patch solved the problem for me.
> > Even more strange that /bin/tcsh doesn't
> > have this problem.
>
> This may be a bug in tcsh.
Maybe...
-Maxim
Index: misc_conv.c
===
RCS file: /home/ncvs/src/contrib/libpam/libpam_misc/misc_conv.c,v
retrieving revision 1.4
diff -d -u -r1.4 misc_conv.c
--- misc_conv.c 2001/06/04 20:59:49 1.4
+++ misc_conv.c 2001/06/07 08:10:55
@@ -132,6 +132,7 @@
static char *read_string(int echo, const char *prompt)
{
struct termios term_before, term_tmp;
+char *input;
char line[INPUTSIZE];
struct sigaction old_sig;
int delay, nc, have_term=0;
@@ -191,8 +192,6 @@
if (expired) {
delay = get_delay();
} else if (nc > 0) { /* we got some user input */
- char *input;
-
if (nc > 0 && line[nc-1] == '\n') { /* terminate */
line[--nc] = '\0';
} else {
@@ -201,25 +200,27 @@
input = x_strdup(line);
_pam_overwrite(line);
- return input; /* return malloc()ed string */
+ goto cleanexit; /* return malloc()ed string */
} else if (nc == 0) {/* Ctrl-D */
char *input;
D(("user did not want to type anything"));
input = x_strdup("");
- return input; /* return malloc()ed string */
+ goto cleanexit; /* return malloc()ed string */
}
}
}
/* getting here implies that the timer expired */
+memset(line, 0, INPUTSIZE); /* clean up */
+input = NULL;
+
+cleanexit:
if (have_term) {
(void)_sigprocmask(SIG_SETMASK, &oset, NULL);
(void) tcsetattr(STDIN_FILENO, TCSADRAIN, &term_before);
}
-
-memset(line, 0, INPUTSIZE); /* clean up */
-return NULL;
+return input;
}
/* end of read_string functions */
Re: Terminal line discipline is broken [sorta]
On Wed, 6 Jun 2001, Maxim Sobolev wrote: > It is very strange, but control keys [^C,^Z etc] no longer work (nop) > in the /bin/sh and bash2 after today's build/installworld. I see this > misbehaviour on two machines. PAM now blocks keyboard signals when reading the password, and usually forgets to unblock them. I use the workaround of backing out the broken code (rev.1.4 of /usr/src/contrib/libpam/libpam_misc/misc_conv.c). > Even more strange that /bin/tcsh doesn't > have this problem. This may be a bug in tcsh. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Terminal line discipline is broken [sorta]
It is very strange, but control keys [^C,^Z etc] no longer work (nop) in the /bin/sh and bash2 after today's build/installworld. I see this misbehaviour on two machines. Even more strange that /bin/tcsh doesn't have this problem. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
