mk-table-sync produces error when using --askpass

[GoogleCodeExporter]

If this is a problem report, what steps will reproduce the problem?
1. A master-slave configuration 
2. Run mk-table-sync with the following options from a Windows machine
using ActivePerl: perl -w mk-table-sync --execute --test --askpass
--synctomaster [slavehost]

What is the expected output? What do you see instead?
Results of the sync operations.
Instead I get the following error: Use of uninitialized value in
concatenation (.) or string at mk-table-sync line 5037.

What information do you get from mk-<toolname>--version?
mk-table-sync  Ver 1.0.10 Distrib 2442 Changeset 2439

What is your MySQL, Perl, DBI, and DBD::mysql version?
MySQL 5.0.51b (both master and slave)
ActivePerl 5.8.820
DBI 1.602
DBD::mysql 3.0002

What is your operating system/distribution?
MySQL servers are both running on Windows 2003 Server SP2.
My desktop, on which I'm running maatkit, is running Windows XP SP3.

If you think it'll be useful, please run the tool with MKDEBUG=1 and
capture the full output in a file, then attach the file.  For example,
MKDEBUG=1 mk-<toolname> [options] > debug.txt.  Is there anything in this
file that you think we should pay special attention to?  Please gzip the
file if it's large.

Please provide any additional information below.
I've also tried some of the other examples that are listed in the synopsis
of the mk-table-sync documentation. They all produce the same error. When I
omit --askpass, I just get the "Access denied for user..." error.

Also, I'm wondering, why is the --password [password] option not enabled in
this tool, while it is on mk-table-checksum, for example?

Original issue reported on code.google.com by eds...@gmail.com on 22 Oct 2008 at 12:12

[GoogleCodeExporter]

Are you saying that it never gets to the point of asking you for a password?  
Or,
that once you enter the password, it goes on to do other work and then has an 
error?

The --password option in mk-table-checksum is a vestigial tail back to the days 
when
it only dealt with a single server.  Now that DSN syntax is introduced, it's not
needed; you can add a 'p' part to any DSN.

Original comment by baron.schwartz on 23 Oct 2008 at 10:55

• Added labels: Tool-mk_table_sync

[GoogleCodeExporter]

It never gets to the point of asking for a password.

Thanks for the explanation on the --password option.

Original comment by eds...@gmail.com on 23 Oct 2008 at 11:19

[GoogleCodeExporter]

I'm looking into this.

Original comment by dan...@percona.com on 25 Oct 2008 at 6:00

• Changed state: Started

[GoogleCodeExporter]

This problem might be specific to Windows/ActivePerl. On Linux it is working 
for me:
perl -w mk-table-sync --execute --test --askpass --synctomaster h=127.1,P=12346
Enter password for 127.1: 
# Syncing A=utf8,P=12346,h=127.1,p=...
# DELETE REPLACE INSERT UPDATE ALGORITHM DATABASE.TABLE
...

I'll have try this later on my Windows machine.

Original comment by dan...@percona.com on 25 Oct 2008 at 6:16

[GoogleCodeExporter]

I have reproduced this problem both on Linux and Windows:
perl -w mk-table-sync --execute --test --askpass --synctomaster localhost
Use of uninitialized value in concatenation (.) or string at mk-table-sync line 
5037.

It only happens when the slave host is given like "localhost" and not as a DSN:
h=localhost

If you could please, re-try it on your machine and specify the slave host like
h=slavehost and let me know if that works.

According to the POD, just "slavehost" should work, so I'll look into why it is 
not.

Original comment by dan...@percona.com on 27 Oct 2008 at 4:44

[GoogleCodeExporter]

Well this was an interesting problem, but it should be fixed now as of r2461. 
Could
you please download this latest rev of mk-table-sync and tell me if it works 
for you?
(It's working for me.)

I thought at first that DSNParser wasn't handling the bareword (localhost) 
correctly.
It does handle barewords, but until now it did not handle barewords mixed with
explicit DSN parts; example: localhost,A=utf8

We were not specifying any extra, explicit DSN parts, but the script itself was
because of this option:
 --utf8
negatable: yes; default: yes
Enable UTF-8 options in Perl and MySQL.

That's enabled by default which causes the script to append ",A=utf8" to 
whatever
host/DSN is given on the command line, resulting in a mixed bareword + explicit 
DSN
prop that the DSNParser module did not handle correctly.

This could have been a bigger problem if, instead of localhost, one gave
"host.domain.com" which would have become "host.domain.com,A=utf8" which, 
ultimately,
would have become the wrong DSN: h=undef,P=undef,...,A=utf8. In other words:
DSNParser would clobber any bareword, losing any given bareword host except
'localhost' because h=undef is basically synonymous with 'localhost'.

And finally, this problem manifested itself with --askpass because the prompt 
for
that prints the h DSN part, which was clobbered and therefore undefined. Now 
that
DSNParser correctly sets the bareword host to the h DSN part, the --askpass has
something to print.

Fun stuff.

Original comment by dan...@percona.com on 28 Oct 2008 at 4:08

[GoogleCodeExporter]

First I tried specifying the slavehost like "h=slavehost" and it worked, then I
downloaded the latest rev and now just "slavehost" works as well.
Thanks! 

Original comment by eds...@gmail.com on 28 Oct 2008 at 10:43

[GoogleCodeExporter]

You're welcome. Glad to hear that it is working as expected now.

Original comment by dan...@percona.com on 29 Oct 2008 at 12:56

• Changed state: Fixed

[GoogleCodeExporter]

nevernow,

Have you downloaded and tried mk-table-sync r2461 or newer?

Original comment by dan...@percona.com on 5 Nov 2008 at 1:47

• Changed state: Started

[GoogleCodeExporter]

Marking this issue as fixed. mk-table-sync Changelog updated.

Original comment by dan...@percona.com on 12 Nov 2008 at 2:38

• Changed state: Fixed