Bug 35254 - miscompiled: term keys (not even BS/DEL/^H) not working
miscompiled: term keys (not even BS/DEL/^H) not working
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: bash (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-08 17:55 EDT by j. alan eldridge
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-08 17:55:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description j. alan eldridge 2001-04-08 17:55:28 EDT
Only tested in X. No terminal keys functional. Suspect misconfiguration[0]
or missing libs on build machine[1].  Replaced with bash-2.04-21[2] from
rawhide, which works fine.

[0]I haven't checked the src rpm spec file for weirdness yet. Will followup
if anything noteworthy turns up. (It's kinda hard to miscompile bash, since
it takes so much of its configuration into its own hands, but I guess
anything's possible.)

[1]FWIW nslookup on wolverine exhibits the same
annoying-to-the-point-of-uselessness problem with control keys. 

[2]This uses the same shared libs, per ldd output, as the wolverine
package, further supporting suggestion of a misconfigured build machine.
Comment 1 j. alan eldridge 2001-04-08 18:13:51 EDT
****NOTE**** I was NOT clear above. Please read following before responding.

The problem does not exist on the bash command line. The problem only exists
when executing the "read" builtin.  It *does* seem to be terminal dependent. 

I'm closing this and will reopen an issue once I really know what's going on.
Sorry for the false alarm.

Note You need to log in before you can comment on or make changes to this bug.