I noticed an odd side effect of the different implementations of
backspace (erase) through clients such as PuTTY and SecureCRT and the
input functions like fgets (I noticed this originally in ssh-keygen).
On our AIX system, if the option to use ^? as the backspace key is
chosen, fgets will actually put the control code for 'DEL' in the buffer
(0x7f) instead of deleting the last character input. The scenario I
noticed is that someone creates a key pair, types in a path, then
decides to just accept the default, so they erase whatever they put in
there. The buffer actually contains what they wrote plus all the DEL
codes, and so the strcmp call against "" fails. So let's say
someone
wants to create a key in the current dir called "mykey", then deletes
it
to accept the defaults. The buffer then actually contains {'m',
'y',
'k', 'e', 'y', '^?', '^?', '^?',
'^?', '^?'}. This then creates the
problem that ls is smart enough to erase these characters when printing
to the terminal, thus making users think they have a file with no
filename in their current dir!
When using the ^h option, the buffer is updated correctly, but the
terminal is not when entering a key path. I looked for a possible fix
in the libc (BOS) imps for AIX, but found nothing. Since we can't rely
on our users choosing the correct backspace option, I was just planning
on writing a wrapper for fgets that cleans up any DEL cntl codes found
in the buffer before returning to the caller. I figured I'd ping the
list first though, to see if anyone else has seen this problem, or might
have a better idea then writing another function to replace the fgets
calls.
Thanks!
Jason