Looks like you're targeting Python 3. There is no such thing called PermissionError in Python 2.7.

I was surprised when you said it'll print the error messages at startup because I've never seen that behavior when loggers are uninitialized.

Here's what I get when there is a parsing error in /etc/myclirc.

No handlers could be found for logger "mycli.config"
Version: 1.5.2
Chat: https://gitter.im/dbcli/mycli
Mail: https://groups.google.com/forum/#!forum/mycli-users
Home: http://mycli.net
Thanks to the contributor - Chris Anderton
mysql root@localhost:django_poll>

It looks like, as of Python 3.2, logging writes to sys.stderr using a StreamHandler in the event that logging isn't configured. In Python 2, we'd have to add a NullHandler in order to silence that annoying No handlers could be found... message.

I think that most users expect command-line apps to write user-facing error messages to stderr. I'd hate for our Python 2 users to not see a potentially helpful error message. So, I suggest that we use the print() function to write to sys.stderr for all rc-related file reading/parsing (instead of using the logging library). @amjith What are your thoughts on that?

By the way, thanks for pointing out the PermissionsError. I'll fix that.

It looks like, as of Python 3.2, logging writes to sys.stderr using a StreamHandler in the event that logging isn't configured.

Python 3 really makes it easy to do the right thing.

I think that most users expect command-line apps to write user-facing error messages to stderr. I'd hate for our Python 2 users to not see a potentially helpful error message. So, I suggest that we use the print() function to write to sys.stderr for all rc-related file reading/parsing (instead of using the logging library). @amjith What are your thoughts on that?

Yes!! I completely agree. We should make choices that are most intuitive for the user. So, let's use print statements there.

An interesting side effect of this change is now I'm aware of an inefficiency. I noticed that when I launched mycli I got the Error parsing... message three times. Further investigation revealed we're reading it once for pager, once for prompt and once for connection details.

Optimizing that should help a little bit with startup time. :)

Changes look good and it works without a hitch. I'm a bit hesitant about the parsing error being printed at startup. ConfigObj can't parse some of the INI file extension that might be valid for mysql but not valid for ConfigObj. So people can't change those lines to be ConfigObj compliant. This means we'll be printing that error message every time they start mycli. Which seems excessive.

Since this is only an issue when we're reading my.cnf files, can we log those messages to the log file instead of stdout?

This means, errors in RC files will be printed to stdout, but errors in my.cnf files will be logged to the log file.

I can't think of a better solution. Suggestions welcome.

@amjith I agree. I'll have config.py check to see if there is a parent logger (which means logging is initialized) to know whether to print to stderr or write to the logging file. That means:

• All *.cnf-related errors will be written to the log file, not printed to stderr.
• The first pass (which I'll work on optimizing later) on the myclircs will print errors to stderr. Subsequent passes will write to the logging file.

@amjith Ok, I've added those changes. There is some optimizing to reading config files that could be done, but this doesn't seem like the appropriate pull request for that. Let me know what you think of the changes.

Looks good. 👍

You're right the optimization are a digression to this PR. We can do it on a different PR.