nickson@comp.vuw.ac.nz (Ray Nickson) (07/13/89)
ENVIRONMENT: bash 1.01 or 1.02 on an HP300 running MORE/BSD4.3
(although I believe it applies to any BSD system).
SYMPTOM: in the command-line editor, some commands don't work.
BUG: there is a conflict between the shell's interpretation of certain
keystrokes and the terminal driver's. In my case, ^C, ^\, ^Z and ^Y are
bound (by stty) to INTR, QUIT, SUSP and DSUSP, so these keys (^Y in
particular) are not available for the shell.
FIX: we should save and zero the special characters before preparing
the terminal for command-line editing, and restore them when running
subprograms or editing. The following cdiff for version 1.02 has been
tested in the above environment and appears to work; a similar patch
to readline.c in 1.01 should also work.
BTW: perhaps we should think about doing a full `tty sanity check and
restore' like tcsh does???
-rgn
--
nickson@comp.vuw.ac.nz ...!uunet!vuwcomp!nickson + 64 4 721000x8142
--------------------cut here--------------------
*** lib/readline.c.orig Wed Jul 12 15:17:01 1989
--- lib/readline.c Thu Jul 13 10:22:14 1989
***************
*** 1483,1494 ****
int original_tty_flags = 0;
struct sgttyb the_ttybuff;
/* Put the terminal in CBREAK mode so that we can detect key presses. */
rl_prep_terminal ()
{
int tty = fileno (rl_instream);
!
/* We always get the latest tty values. Maybe stty changed them. */
ioctl (tty, TIOCGETP, &the_ttybuff);
--- 1483,1498 ----
int original_tty_flags = 0;
struct sgttyb the_ttybuff;
+ struct tchars the_tchars;
+ struct ltchars the_ltchars;
/* Put the terminal in CBREAK mode so that we can detect key presses. */
rl_prep_terminal ()
{
int tty = fileno (rl_instream);
! static struct tchars new_tchars = { -1, -1, -1, -1, -1, -1};
! static struct ltchars new_ltchars = { -1, -1, -1, -1, -1, -1 };
!
/* We always get the latest tty values. Maybe stty changed them. */
ioctl (tty, TIOCGETP, &the_ttybuff);
***************
*** 1503,1508 ****
--- 1507,1517 ----
}
the_ttybuff.sg_flags |= CBREAK;
ioctl (tty, TIOCSETN, &the_ttybuff);
+ /* save the special characters so we can use them for shell bindings */
+ ioctl (tty, TIOCGETC, &the_tchars);
+ ioctl (tty, TIOCGLTC, &the_ltchars);
+ ioctl (tty, TIOCSETC, &new_tchars);
+ ioctl (tty, TIOCSLTC, &new_ltchars);
}
/* Restore the terminal to its original state. */
***************
*** 1513,1518 ****
--- 1522,1530 ----
the_ttybuff.sg_flags = original_tty_flags;
ioctl (tty, TIOCSETN, &the_ttybuff);
readline_echoing_p = 1;
+ /* restore special characters to saved values */
+ ioctl (tty, TIOCSETC, &the_tchars);
+ ioctl (tty, TIOCSLTC, &the_ltchars);
}
#endif /* SYSV || HPUX */
bfox@AUREL.CALTECH.EDU (Brian Fox) (07/13/89)
Date: Thu, 13 Jul 89 10:36:45 +1200 From: Ray Nickson <nickson@comp.vuw.ac.nz> ENVIRONMENT: bash 1.01 or 1.02 on an HP300 running MORE/BSD4.3 (although I believe it applies to any BSD system). SYMPTOM: in the command-line editor, some commands don't work. BUG: there is a conflict between the shell's interpretation of certain keystrokes and the terminal driver's. In my case, ^C, ^\, ^Z and ^Y are bound (by stty) to INTR, QUIT, SUSP and DSUSP, so these keys (^Y in particular) are not available for the shell. ERROR: This is NOT a bug. This is a design decision. You are welcome to explain why it is necessary to change the users mind about what keys are special to the kernal. Brian Fox
bet@ORION.MC.DUKE.EDU (Bennett Todd) (07/13/89)
I used to use ecsh on our systems; I am gradually converting users over to bash. The biggest problem with ecsh is that it constantly did major tty setting and resetting, and this tickled a bug in the SunOS 4.x tty driver, which locked the console fatally requiring rebooting when someone typed ^S. The situation, as far as I could tell, was that due to output buffering ecsh would get the tty back while the previous command's output was draining. The ^S would have been processed, leaving the tty's output frozen, and ecsh would change the tty settings leaving no character capable of restoring output. I was unable to find anything that could be done either on the console or from another machine via rlogin to unlock the console. I tried unsuccessfully to modify ecsh to prevent it from having this problem. Bash doesn't currently have this problem. Bash might not necessarly acquire this problem if you modify it as Ray requested; it is a possibility to beware however. -Bennett bet@orion.mc.duke.edu
nickson@comp.vuw.ac.nz (Ray Nickson) (07/14/89)
Date: Wed, 12 Jul 89 21:27:20 PDT
From: bfox@aurel.caltech.EDU
Date: Thu, 13 Jul 89 10:36:45 +1200
From: Ray Nickson <nickson@comp.vuw.ac.nz>
...
BUG: there is a conflict between the shell's interpretation of certain
keystrokes and the terminal driver's. In my case, ^C, ^\, ^Z and ^Y are
bound (by stty) to INTR, QUIT, SUSP and DSUSP, so these keys (^Y in
particular) are not available for the shell.
ERROR:
This is NOT a bug. This is a design decision. You are welcome
to explain why it is necessary to change the users mind about
what keys are special to the kernal.
I initially suspected this was a deliberate decision, and managed to
convince myself otherwise. I regret (and apologize for) calling it a
bug.
Notwithstanding this, I still feel that most users would prefer `my'
semantics, and intend to communicate with Brian via private email to
discuss this. I'll leave it up to Brian as to whether he thinks it's
enough of an issue to discuss on the list.
Once again, I really like bash, and hope my comments aren't perceived
as a critisicm of it. I wouldn't be devoting time to it if I didn't
think it was good software; nothing short of desparation would tempt
me to hack tcsh source!!!
The beauty of such well-written free software is that we can `agree to
disagree' if necessary and all easily maintain our `own' versions.
-rgn
--
nickson@comp.vuw.ac.nz ...!uunet!vuwcomp!nickson + 64 4 721000x8593