bug-bash
[Top][All Lists]
Advanced

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

Re: tab and arrow keys


From: azad vishwakarma
Subject: Re: tab and arrow keys
Date: Wed, 20 Feb 2019 22:42:08 +0530

thank you so much to text me this much long explanation. its awesome and it
cleared my doubt. I am very sorry to call that a bug. I was wrong.

thank you thank you thank u soooo much.

On Tue, Feb 19, 2019 at 10:21 PM Greg Wooledge <address@hidden> wrote:

> 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
> program.
>
> 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
> finishes.
>
> 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]