Details

    Description

      mysql as well as mysqldump (and presumedly all the other tools) silently ignore the --port option if no host is given or it is localhost.

      This happens because localhost is treaded specially, and instead a socket connection is made. So the problem here, is that giving --port does not force --protocol=tcp, which would fix this problem.

      There are several things that are wrong with this:

      a) it is not described with the --port option in the man pages of the respective tools
      b) a user input is silently discarded, not even a warning is printed
      c) This is really surprising.
      d) It is documented somewhere, but not in the obvious places
      e) There is already a bug report on this in oracles bug tracker since ages https://bugs.mysql.com/bug.php?id=55796

      Well, I'm running out of steam coming up with more letter reasons. But this behavior is really annoying. When would I as the user want to have an explicit `--port` argument be ignored if I give it? I mean, if mysql where able to deduce somehow that the port is going to the same mysql instance as the socket it can find - fine - but I would be very surprised if it could without connecting to both.

      Attachments

        Issue Links

          Activity

            Elkin Andrei Elkin added a comment -

            serg: to the No, I am really puzzled.

            I have thought an option in a configuration file is different from the same option on the command line only for the timing of their parsing.
            E.g --port can be specified in 3 locations (and each have a number of option repeats) as in

            mysql --defaults-file=file_def --defaults-extra-file=file_extra --port=effective_value

            and the effective_value would prevail.

            If it's correct so far, what makes the command line version of the option so special?

            Elkin Andrei Elkin added a comment - serg : to the No, I am really puzzled. I have thought an option in a configuration file is different from the same option on the command line only for the timing of their parsing. E.g --port can be specified in 3 locations (and each have a number of option repeats) as in mysql --defaults-file=file_def --defaults-extra-file=file_extra --port=effective_value and the effective_value would prevail. If it's correct so far, what makes the command line version of the option so special?
            Elkin Andrei Elkin added a comment -

            Actually there's a 4th location aka the built-in default (to be "parsed" the first).

            Elkin Andrei Elkin added a comment - Actually there's a 4th location aka the built-in default (to be "parsed" the first).

            Command line version of the option is special, because it's what user sees and types. The old behavior is perfectly logical and correct and doesn't need any changes from that point of view. On the contrary, when one option magically modifies some other option value — this is usually confusing and illogical and rarely works well.

            What we're doing here is increasing user friendliness for inexperienced users. Such a user types

            mysql --port=3456
            

            and expects mysql to actually use this port. A setting from the config file doesn't match this use case, if you write a config file, you could (and should) as well put the protocol=tcp there.

            Yes, unfortunately this fix breaks the existing simple and clear logic of option handling and makes --port on the command line special. We don't do it lightly, but this is one of the very common sources of confusions indeed. So, probably, deserves the exception.

            serg Sergei Golubchik added a comment - Command line version of the option is special, because it's what user sees and types. The old behavior is perfectly logical and correct and doesn't need any changes from that point of view. On the contrary, when one option magically modifies some other option value — this is usually confusing and illogical and rarely works well. What we're doing here is increasing user friendliness for inexperienced users. Such a user types mysql --port=3456 and expects mysql to actually use this port. A setting from the config file doesn't match this use case, if you write a config file, you could (and should) as well put the protocol=tcp there. Yes, unfortunately this fix breaks the existing simple and clear logic of option handling and makes --port on the command line special. We don't do it lightly, but this is one of the very common sources of confusions indeed. So, probably, deserves the exception.
            Elkin Andrei Elkin added a comment -

            serg, bnestere: All right, I realize now the backward compatibility concern! Would it make sense to planning the command-line exception into
            a general rule with warnings when then the configuration-file options clash? E.g my.cnf [client]'s lonely port = 3456 (no --protocol) would start warning with the patch to override the socket default protocol in 10.7 with tcp as the warning would say.

            Elkin Andrei Elkin added a comment - serg , bnestere : All right, I realize now the backward compatibility concern! Would it make sense to planning the command-line exception into a general rule with warnings when then the configuration-file options clash? E.g my.cnf [client] 's lonely port = 3456 (no --protocol) would start warning with the patch to override the socket default protocol in 10.7 with tcp as the warning would say.
            dwt Martin Häcker added a comment - - edited

            Interesting that this bug report just cropped up again in my inbox, just when I was bitten by this bug again last week.

            This case had a ~/.mycnf file, that specified `host=localhost`, but I tried connecting with a command-line that specified `--protocol=socket --socket=/some/path` - yet the socket and protocol was ignored, and again the connection was made to a different host. I had to add `--host=` to explicitly declare undeclare the host to get rid of this problematic behavior.

            I really do think that you need to document the interdependency of these options and how they lead to ignore later command line arguments. I also think that it would be far more logical to have later options actually overwrite earlier options, especially if they are given through another means (in this case `.mycnf` vs command line).

            Here is what I would have expect:

            • host specified in .mycnf, `--protocol=socket --socket=$path` - that declaration should win, no warning generated
            • host, protocol, socket specified all on the command line - a warning is warranted, last option should still win.

            What do you think and why?

            dwt Martin Häcker added a comment - - edited Interesting that this bug report just cropped up again in my inbox, just when I was bitten by this bug again last week. This case had a ~/.mycnf file, that specified `host=localhost`, but I tried connecting with a command-line that specified `--protocol=socket --socket=/some/path` - yet the socket and protocol was ignored, and again the connection was made to a different host. I had to add `--host=` to explicitly declare undeclare the host to get rid of this problematic behavior. I really do think that you need to document the interdependency of these options and how they lead to ignore later command line arguments. I also think that it would be far more logical to have later options actually overwrite earlier options, especially if they are given through another means (in this case `.mycnf` vs command line). Here is what I would have expect: host specified in .mycnf, `--protocol=socket --socket=$path` - that declaration should win, no warning generated host, protocol, socket specified all on the command line - a warning is warranted, last option should still win. What do you think and why?

            People

              bnestere Brandon Nesterenko
              dwt Martin Häcker
              Votes:
              2 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.