The script /etc/profile.d/10inputrc.csh contains the following lines: # the BackSpace key sends ^? or ^H, depending on config setenv BSNUM 14 setenv BACKSPACE `dumpkeys |& grep "^keycode $BSNUM" | awk '{print $4}'` if ($BACKSPACE == "BackSpace") then bindkey "^?" delete-char bindkey "^H" backward-delete-char else bindkey "^?" backward-delete-char bindkey "^H" delete-char endif In Mageia 2 beta 2, dumpkeys fails when run as a normal user, with the message Couldn't get a file descriptor referring to the console This results in the BACKSPACE variable being set to an empty string, and hence ^? gets bound to backward-delete-char. However, when run as root, the output from dumpkeys |& grep "^keycode $BSNUM" on my machine is keycode 14 = BackSpace Delete Delete Control_underscore Delete Delete Meta_Delete Meta_Delete Meta_Delete (some white space removed for clarity) and hence ^H gets bound to backward-delete-char. This makes it impossible to set gnome-terminal up so the backspace key works both before and after you use the su command.
CC: (none) => arnaud.patard, dmorganec, mageia, mageia, pterjan, thierry.vignaud, tmb
CC: (none) => remco
Speaking with some others it seems that dumpkeys is pretty much expected to fail. As I'm no csh expert, would you be able to find a good setup for this file? It may involve looking at the sh equiv. and formulating a working system. If you can do that, I'll happily include it. Failing that I'd be tempted to just remove the file completely.
I think you could safely remove the lines quoted above, i.e. from # the BackSpace key sends ^? or ^H, depending on config to the end of the file. In most circumstances csh will get the correct bindings from termcap/terminfo, and for the odd situation where it doesn't, the user can always fix it up themselves (it's unlikely any novice users will be using csh). The sh equivalent doesn't try to do anything about the backspace key, which suggests it isn't necessary.
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Yes, still valid.
Keywords: NEEDINFO => (none)
Any chance of applying the fix I suggested in comment 2? It's annoying to have to do this on three different machines each time I test a new release.
Keywords: (none) => Junior_job, PATCH
For me the setting in "else" is correct, so no issues when dumpkeys doesn't work. But indeed it is apparently not needed: when I disable this code and log into a VC the Backspace and Delete keys work.
CC: (none) => cjw
@martin, I have removed the lines in question from the package. Hopefully this resolves this issue for you. Updated package is initscripts-9.41-3.mga3 @other packagers Cc'ed on this report: This was slightly harder than I expected to fix. I unpacked the initscripts-mgaconf.patch.xz file, manually took out the lines in the mega patch file, repackaged the file, and mgarepo uploaded it. In case this is not the correct approach, please educate me accordingly.
Status: NEW => RESOLVEDResolution: (none) => FIXED
Hi Remco, Thanks for trying to fix this - unfortunately it doesn't seem to have worked. Having taken a quick look in the SVN repository, I think the problem is that you haven't updated the SOURCES/sha1.lst file to point to the new mega patch binary file - but maybe one of the other packagers will be able to give better advice.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Yipes... that's pretty poor of me. Please try again with -4.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
That's fixed it. Thanks for doing this!
This fix doesn't appear to have made it into Mageia-3 beta 2.
@Remco, Oh sorry, I've only just noticed now your comments here (blame the madness of the xmas period!) (In reply to comment #7) > @other packagers Cc'ed on this report: This was slightly harder than I expected > to fix. I unpacked the initscripts-mgaconf.patch.xz file, manually took out the > lines in the mega patch file, repackaged the file, and mgarepo uploaded it. In > case this is not the correct approach, please educate me accordingly. If you are not working directly in the git tree that we use to manage this tarball generation, then I wouldn't touch it, but instead add extra patches outside of it as per any other packages. When we periodically sync, we'll simply include any non-git patches into git. The process is pretty convoluted to be honest and the patching is a pain, hence why we don't update it crazy often. As the main tarball is created automatically from git repos, it will simply be overwritten when we rebase our initscripts on upstream redhat ones etc. I'll add some notes to the .spec. As for the fix, am I right in saying we should just remove the "else" section?
Can you double check I've done the right thing here? http://svnweb.mageia.org/packages?view=revision&revision=393116
@Colin, not quite, all of this should be removed: # the BackSpace key sends ^? or ^H, depending on config setenv BSNUM 14 setenv BACKSPACE `dumpkeys |& grep "^keycode $BSNUM" | awk '{print $4}'` if ($BACKSPACE == "BackSpace") then bindkey "^?" delete-char bindkey "^H" backward-delete-char else bindkey "^?" backward-delete-char bindkey "^H" delete-char endif As you noted in comment #1, dumpkeys is expected to fail, so using its output to make any decision is asking for trouble!
This bug seems to have been dropped mid-way, so I extended the patch to completely remove dumpkeys and committed to Cauldron and mga2.
CC: (none) => dan
initscripts-9.34-20.1.mga2 is in updates_testing and available to test.
To Martin Whitaker, could you test the initscripts package from the core/updates_testing media and confirm it solves your problem? Then Dan Fandrich will be able to handle the update candidate to the QA Team. Thanks!
CC: (none) => stormi
On running an update, I found that this change has already made it into core/updates in initscripts-9.34-20.2.mga2. I can confirm this version solves the issue.
Thanks