You learn something new every day!
After your explanations, this situation makes perfect sense to me now. I
was attempting to quickly clone a database to basically rename it since
mysql removed the rename command a while ago (it was dangerous apparently).
It's pretty awesome that you guys took the time to explain this to me
instead of just blowing me off. Thank you very much.
-Jason
On Thu, Jul 11, 2013 at 11:04 AM, Greg Wooledge <wool...@eeg.ccf.org> wrote:
> On Thu, Jul 11, 2013 at 10:47:12AM -0700, Jason Sipula wrote:
> > I still think this is a bash issue. After the command terminates, you
> must
> > restart your bash session to return to normal functionality. Nothing
> typed
> > into the terminal displays but it does receive it.
>
> If the terminal has been messed up (which happens frequently when programs
> exit abnormally), then you'll need to run "reset" or some other command
> to reset the terminal.
>
> > Perhaps I'm
> > misunderstanding what bash's job is... I was under the impression the
> shell
> > was responsible for displaying text in the terminal.
>
> That's incorrect. The terminal itself is responsible for displaying text
> in the terminal. Bash simply reads commands from a file descriptor and
> runs them. When the commands are running, they interact directly with
> the terminal, while bash goes to sleep.
>
>
> On Thu, Jul 11, 2013 at 07:47:47PM +0200, John Kearney wrote:
> >
> > This isn't a but in bash.
> > firstly once a program is started it takes over the input so the fact
> > that your password is echoed to the terminal is because myspl allows
> it
> > not bash, and in mysql defense this is the normal behaviour for
> command
> > line tools.
>
> Well. The issue is really that he's trying to run two separate instances
> of "mysql -p" in the same terminal at the same time. They're competing
> for the same input stream, and that never works well.
>
> There is no "normal behavior" among programs that accept a password for
> authentication. Some of them open /dev/tty directly. Some of them
> read from standard input. Some of them accept a password in a command
> line argument, or in an environment variable -- both of which are bad.
>
> > Secondly both mysqldump and mysql start at the same time and can
> > potentially be reading the password also at the same time.
>
> (You described multiple stdin readers here. I won't repeat that part.)
>
> > basically you should give the password on the command line to mysql.
> > something like
> > read -sp "Password:" Password
> > mysqldump -u someuser --password ${Password} -p somedb | mysql -u
> > someuser --password ${Password} -p -D someotherdb
>
> First: use more quotes. "$Password", not ${Password} or $Password.
>
> Second: passing the password (which is presumably supposd to remain
> secret) on the command line allows it to be visible to every user on
> the system. On 99% of Unix systems in the world, anyway. There are
> undoubtedly some small number where user can't run "ps -ef", or where
> they get limited output from it, but you shouldn't assume.
>
> There may be some setups where this solution is adequate, once it's
> been quoted correctly. In most setups, it is unsafe. It's up to Jason
> to decide whether his setup can permit this.
>
> I'd ask a mysql list for advice with this. It's not something that can
> be generalized across applications.
>
