Red Hat Bugzilla – Bug 217454
add getkey flag to echo the key that was pressed
Last modified: 2014-03-16 23:04:23 EDT
getkey should have a flag that makes it echo the key that was pressed.
This could be used to allow rc.sysinit to have multiple entries like "Press 'I'
to enter interactive startup."
Created attachment 142243 [details]
patch against getkey.c from initscripts-8.45.6
Not sure what you mean by 'this could be used'... it's normally echoed anyway.
Not to stdout. This patch lets you do stuff like:
echo "Do you wanna? [Y/N]"
ch=$(getkey -k YN)
if [ "$ch" == "Y" ]; then
Can't you just use 'read' for that?
(The reason getkey is used in rc.sysinit is so it can read something without
Right. So if you wanted to have multiple options at startup, say:
Press 'I' to enter interactive startup.
Press 'T' to start in text mode.
You'd need to be able to differentiate between 'I' and 'T' being pressed.
Perhaps, though, something more robust could be written to do a proper startup menu.
I'd prefer something else. 'T' wouldn't necessarily work right, other than
calling 'telinit' at the end of rc.sysinit.
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
I think we agree that the feature I was proposing here is still a good idea, but
this implementation is not the best way to do it.