[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tab and arrow keys

From: Greg Wooledge
Subject: Re: tab and arrow keys
Date: Tue, 19 Feb 2019 11:51:23 -0500
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, Feb 19, 2019 at 09:24:38AM -0500, Chet Ramey wrote:
> On 2/19/19 3:24 AM, azad vishwakarma wrote:
> > hi there
> > while changing password with terminal/bash, it accepts tab and arrow keys
> > along with characters,symbols and spacebar. But when we try to login into
> > the system *"TAB and ARROW key" *perform their own usual task. So we can't
> > enter the password and it tells that password is incorrect.i tried it with
> > ubuntu and kali linux and i got the same problem.
> What program are you using to change your password? It's probably not bash,
> and that program is where any change would need to be made.

To expand on this: there are many programs involved, and each one plays
a separate role.

First, you have your terminal (most likely a terminal emulator).  This may
be the Linux console, which is built into the Linux kernel, or it may be
an xterm, konsole, gnome-terminal, rxvt-unicode, aterm, etc.  That's one

Then, you have bash, or some other shell, which runs inside a terminal and
accepts commands that you type.  When you type a command and press Enter,
your shell tries to execute your command.  The shell is the second program.

Finally, you have whatever program you actually executed -- for example,
"passwd" or "yppasswd" to change your system password from a shell in
a terminal.  When a shell executes a program like this, the program is
communicating directly with your terminal.  The shell steps completely
out of the picture, and does not get involved until the other program

How passwd handles something like the Tab or Enter key is entirely up
to the passwd program.  You could use the terminal layer to change
the underlying meaning of a Tab key (for example, you could bind tab
to the "intr" function, so it would act the way Ctrl-C normally does in
this terminal), but that's about it.

Now, this leads the other part of your question.  Apparently your
terminal-based program is faithfully letting you use tabs and arrow keys
and so on in your passwords, but your graphical login is *not* letting
you use those keys.

So, the question is really: what result are you actually looking for?

If you want your graphical login program (there are several different
ones) to be able to handle a Tab character in a password, then you should
file a bug report with the graphical login program.  It's clearly not a
problem in bash or in passwd or whatever you used that was successfully
able to use the Tab character.

Now, arrows are more complicated.  The problem is that there isn't
actually a "right arrow character", at least not in the same way that
there is a universally understood "tab character".  When you press an
arrow key in a terminal emulator (in, say, X11), the terminal emulator
receives two events from the windowing system: a "KeyPress event" and a
"KeyRelease event", each with the associated "keysym" for this key (e.g.
"keysym Right" for the right arrow key).

When the terminal emulator receives the KeyRelease event, it looks
up that keysym in its internal memory and maps it to a sequence of
bytes which it sends to whatever application is receiving input from
the terminal.  This sequence is potentially different for each kind of
terminal being emulated.  For example, in xterm, the right arrow key maps
to the sequence ESC [ C.  In a Konsole or VT100 terminal, it's ESC O C.
In a VT52 terminal, it's just ESC C.

Suppose passwd is the program currently reading input from your terminal,
and you press the right arrow key.  If you're running it in an xterm, then
you might be putting the characters ESC [ C into your password, assuming
passwd is doing what we expect.

Now suppose later you open a Konsole, and you try to change your password.
You're asked to enter the current password first, but in this terminal,
the right arrow key sends ESC O C instead of ESC [ C, so your password
doesn't match.

Do you consider this a bug?  If so, in which program?  In the terminal
emulator?  It's simply passing the bytes along.  We live in a world where
there are many different kinds of terminals, and they don't agree on
the escape sequences for "special" keys.  If your objective is to get
every terminal to agree on those, you will fail.  Sorry.

In passwd, for not recognizing that this is a terminal escape sequence
and yelling at you for trying to use it in a password?  Do you expect
passwd to recognize every possible escape sequence for every nonstandard
key in every terminal emulator in the entire world?  That seems like a
tall order.  I suppose you could argue that *any* password containing
an ESC character should be rejected.  You could try filing that bug with
the maintainers of passwd.  I'm curious to see what they would say.

Personally, my advice to you would be: do not try to use Tabs or Arrow
keys (or Home, Insert, Delete, Page Up, Page Down, Print Scrn, F1, F2,
or any other "special" key) in a password.  Stick to the regular ASCII
character set.  There are plenty of punctuation characters there that
you can use, and they'll work on every terminal.

In any case, this is not an issue that bug-bash can help you with,
because bash is the one program that's definitively *not* involved in
setting a password or in logging in with either a traditional text or a
graphical login program.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]