I can answer the question of "how do they even manage to both read the password?"
A device file named /dev/tty exists. Linux (and more modern Unix) kernels arrange for /dev/tty to be different for every process that has a controlling TTY. That's all of the interactive processes, you'd have to go out of your way to write a program that doesn't have a controlling TTY. The "TTY" column of ps -l -p $$ will show you what your shell's TTY is. ps -el "TTY" column will show you the controlling TTY of all processes.
You can think of /dev/tty as a way to get what would ordinarily be stdin, but from the keyboard associated with the controlling TTY. You can try this out with the command cat < /dev/tty > spork in an Xterm window. Whatever you type, up to the terminating control-D, will end up in file "spork".
A lot of FTP and SSH clients use /dev/tty for password input, to avoid having a password show up in the environment or other crannies. Interactive clients can do open("/dev/tty", O_RDWR) no matter what the actual controlling TTY is, and get a file descriptor that in essence, is connected to the keyboard. Various system calls can be used to turn off echoing. You can test this by using a bash shell Xterm and running stty -echo. You'll have to type blind, but commands like ls, ps, etc clearly get to the shell and work. You can turn TTY echoing back on via stty echo.
It appears (as per Rahul Patil above), that you can set a password in a file, .my.cnf. That file could include these lines:
[client]
password="my_password"
or maybe something like:
[mysql]
password="my_password"
user=root
The .my.cnf file appears to be extremely flexible in specifying parameters and values common to many clients of MySQL.
~/.my.cnfor you can use-pPassword? stackoverflow.com/questions/9293042/…-p MySecretPasswordwould show in the output ofpsand the history, amongst other places.