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 <wool...@eeg.ccf.org> 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. >
