Trouble with mysql passwords

[StFS]

If I connect to a mysql database using:

$ usql
\connect mysql://[email protected]:3306/mydb_name

I get prompted to enter a password, which I do, and I am able to connect.

However if I put the following in ~/.usqlpass :

mysql:our-very-long.servername.with.rds.amazonaws.com:3306:mydb_name:myuser:mylongasspassword

and then try to connect with:

usql mysql://our-very-long.servername.with.rds.amazonaws.com:3306/mydb_name

I get prompted with this:

error: mysql: 1045: Access denied for user 'myuser'@'my.isp.sumthin.sumthin.com' (using password: YES)
Enter password:

If I enter my password I am connected and stuff works.

I'm wondering whether this is possibly because my password has special characters. I've tried to find some way to escape it in the .usqlpass file but I haven't had any luck yet.

What characters (if any) need to be escaped in the .usqlpass file? And how do I escape them?

[StFS]

I am also wondering whether there is any way for me to alias a connection string in usql. So instead of having to specify the full qualifier of the db: protocol://host:port/db_name I would be able to do usql myalias instead.

[kenshaw]

I'll check and see if there's an issue with the usqlpass code. Yes, I think a feature for some kind of better connection alias names would be good. If you have an idea, let me know. I've held off implementing anything since the usqlpass functionality works for most of what I use usql for.

[StFS]

Ideas? Sure! Well thought out? Probably not ;)

One idea would be to do a bit of a drastic change and introduce a new config file. That way, the old ~/.usqlpass functionality would still work but this would be added on top.

I would have a new config file and would place it in ~/.config/usql/ (an alternative would be to have a directory called ~/.usql/ and put the config file (or possibly multiple files if needed) there. I'm not a huge fan of hidden config files littering the root of my home directory so that's why I suggest this. The ~/.config/ directory is a convention based on the XDG Base Directory Specification.

As for the name and format of the config file itself, I'd probably go for the format that a lot of CLI tools use, one of which is the aws-cli. Although AWS splits their config up into two files (config and credentials), I don't think that's really necessary here. I would say just having one config file: ~/.config/usql/config would be fine. The format of this file is a simple INI file (here's a go library that can parse that) that would use the "sections" to define the connection aliases. So here would be an example of a config file:

[default]
# this wouldn't be an actual alias but perhaps some configuration that would be common to all connections
# but this config could be overwritten in each connection below if needed
output = json

[my_production_db]
driver = mysql
host = myproddb.mycompany.com:3306
username = myproduser
# password not included for prod, should prompt every time

[my_dev_db]
driver = mysql
host = mydevdb.mycompany.com:3306
username = mydevuser
password = mynotsosecretdevpassword
# we could override the default JSON output in each connection group
output = csv

Then, when running usql you'd be able to do something like the following:

$ usql --profile=my_dev_db

which would use the configuration from the my_dev_db group in the config file (along with all the default values that were not overridden in the selected profile).

So that's at least one idea... unfortunately I don't have experience writing GO so it would take me quite a lot of time (which I unfortunately don't have much of) to write a PR for this.

[snwflake]

~~while I'd like proper alias functionality as well, the root of this issue is still unsolved.~~

~~~/.usqlpass~~

mariadb:10.10.0.1:3306:dbuser:dbname:password

usql mariadb://[email protected]/dbname
error: mysql: 1045: Access denied for user 'dbuser'@'10.10.0.10' (using password: NO)
Enter password:

~~Major difference to StFS's output seems to be that usql doesn't even attempt to use a password.~~

Edit: user error, specifying the port on the connection works, alternatively setting the port to * in .usqlpass