Bug 76070 - getkey hangs with no wait message, also needs to be able to ignore control characters
Summary: getkey hangs with no wait message, also needs to be able to ignore control ch...
Status: CLOSED DUPLICATE of bug 76071
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts   
(Show other bugs)
Version: 7.3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-16 15:42 UTC by Benjamin Delfin
Modified: 2014-03-17 02:31 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-10-16 15:42:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Benjamin Delfin 2002-10-16 15:42:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)

Description of problem:
When getkey is invoked with a wait period but no wait message, it core dumps.  
Also, there should be an option to allow getkey to ignore Control-C and Control-
D characters.  It's inability to avoid these characters can cause problems when 
dealing with the Linux Progress Patch.  When we used getkey to check for a 
keypress in order to reset a machine's environment and reboot, it would always 
do so when using the Linux Progress Patch, whether or not the key was actually 
pressed.  Finally, a NULL character passed to getkey will be interpreted as a 
successful match against it's list of characters.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Type "getkey -c 5 d" and wait.

Actual Results:  You get garbage characters, repeated 5 times, followed by a 
segmentation fault.

Expected Results:  It should have waited 5 seconds for the d key, then ended 

Additional info:

Comment 1 Bill Nottingham 2002-11-12 05:55:54 UTC

*** This bug has been marked as a duplicate of 76071 ***

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