Feature request: Command Line Options

[hkramski]

I would like to have a cmd line option to provide the database password (or a file containing the password) and another option to start openMittsu in (auto-)connected mode. Maybe also the database path as a parameter.

If cmd line options were introduced, there should also be a --help handler.

TIA Heinz

[blizzard4591]

This was implemented two commits ago, sorry for not responding earlier. There should be output from --help, and the current options are:

• --openmittsu-nopassword
• --openmittsu-password-file
• --openmittsu-database-file
• --openmittsu-autoconnect
• --openmittsu-minimize

I hope this helps :)

[hkramski]

Hi, thanks a lot, great work! However. I can't get --openmittsu-password-file to work - tried every combination of nothing / cr / lf / crlf and file encoding I could think of. Which exact format is expected for a password?

Regards, Heinz

[blizzard4591]

The entire file is read at once and used as the password, so a file containing just the password in UTF-8 or similar, no Byte-Order Mark, should work (I tried it using Notepad, New File, enter the password, save).

Of course, things like BOMs should not break everything, I hope to revisit this quick and dirty implementation soon.

[blizzard4591]

Should be fixed with commit 9d988ea19d7026eec2f467e97aa48118be2ed481. Please test whether it works now :)

[hkramski]

I'm now at r352.9d988ea-1 but my issue still exists.

I think the problem is not a BOM but an additional linefeed (0x0a) at the end of the password line. In contrast to notepad++ on Windows, all Linux editors (tried Vim, Emacs, Kate) seem to add one even if you do not press Enter after entering your password, and echo "pw" > pw.txt also adds a linefeed character. As a workaround, you can use echo -n "pw" > pw.txt , which gets you a working password file. I can happily live with that workaround, but perhaps reading up to and not including any carriage returns or linefeeds is a more robust solution.