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.
