Hi,
I just installed kpcli (tried both the 2.3 from an Ubuntu distro repo, and 3.0 from here). it's great, and thank you for providing a CLI/TUI version of keepass! i do prefer CLI over the .net/mono keepass
I just wanted to offer a suggestion for possible consideration in a future version of both 2.3 and 3.0
When starting up kpcli v2.3 (from repo), if i do not have GNU readline (perl) installed, kpcli gives me the following feedback:
$ /usr/bin/kpcli
KeePass CLI (kpcli) v2.3 is ready for operation.
Type 'help' for a description of available commands.
Type 'help <command>' for details on individual commands.
* You are using: Term::ReadLine::Stub
Please install Term::ReadLine::Gnu for better functionality!
kpcli:/>
and when starting up kpcli v3.0 without readline, the 3.0 version does not even get me to its prompt, instead, just bumping me back out with the following error:
$ kpcli
No usable Term::ReadLine:: modules found.
This list tried: Term::ReadLine::Gnu, Term::ReadLine::Perl, Term::ReadLine::Perl5
$ _
But as a new user, these messages leave me dead in the water, because they do not provide me with an explicit action to take. Like, "Okay, how do I get such a "Term::ReadLine::" module? What the heck IS that? Where do I sign up?" is my next question, but the error messages do not help me.
So I wonder if the error messages could be made more helpful. For instance, in my case, I am running Ubuntu 14.04LTS. I wonder if it saw me on a Debian-based distro, it could instead give me a message telling me what action I could take:
You do not have GNU ReadLine installed. On Debian/Ubuntu systems you can rectify this by quitting kpcli, then running
$ sudo apt-get install libterm-readline-gnu-perl
and then re-running kpcli.
..and similarly for Fedora/.rpm based systems, etc.
Just food for thought, and hope it helps out the cause! Thank you again, Lester! I love kpcli! It is so nice to do everything (except generate complicated passwords) from the keyboard much more clearly, quickly and easily. For daily use, it is much better than keepass/mono.
-JS
Jeff,
I'll follow up on your feature request later, which may actually be a bug
in 3.0 (I don't have time to investigate it right now), but I wanted to
quickly address your "except generate complicated passwords" statement. I
don't understand that statement because kpcli has that feature in spades:
kpcli:/personal> new foo
Adding new entry to "/personal"
Title: foo
Username: foo
Password: ("g" or "w" to auto-generate, "i" for interactive)
You have three options there - "g" or "w" to auto-generate or "i" for
interactive password generation. More details in the help for new:
kpcli:/personal> help new
new: Create a new entry: new <optional path&|title=""></optional>
The new command is used to create a new entry.
Usage is straightforward.
For password generation, the "g" method produces a
string of random characters, the "w" method creates a
4-word string inspired by "correct horse battery staple"
(http://xkcd.com/936/), and the "i" method provides an
interactive user interface to the "g" and "w" methods.
By default, the "g" and "i" methods generate passwords that
are 20 characters long. That can be controlled by providing an
integer immediately after the "g|i" in the range of 1-50.
For example, "g17" will generate a 17 character password.
--
Lester
On Sun, Sep 27, 2015 at 12:02 AM, Jeff Stern jastern949@users.sf.net
wrote:
Related
Feature Requests:
#11hi lester,
thanks for getting back so quickly.
yes, the interactive pw generation is great. but it doesn't -- unless i've
missed something? -- have the options that the keepass.info prog has. (I'll
call that the KPI program.)
for instance, the KPI app, in its Password Generator dialog, allows one to
specify what kinds of characters will be included:
..with a check-box next to each.
I need this functionality because of the great variety of password
requirements across the websites I sign in to.
Does kpcli have the ability to specify, as above, what types of characters
will be included in a password? I could easily have missed it..
Side point: improvements to KPI
However, IMHO, the KPI app could go even further in one crucial way (and I
should submit this to them on their dev site feature request):
I noticed that although the above categories have checkboxes, so that a
generated password CAN have a certain class of characters in it, that does
not mean necessarily that it WILL.
For instance, checking "Digits" means that the user's next auto-generated
password COULD have digits in it, but it also might NOT.
One way to solve this I can think of would be if KPI had not one, but 2
checkboxes next to each category: One checkbox for "CAN HAVE" and another
checkbox for "MUST HAVE AT LEAST 1".
Another, easier way to solve it perhaps would be to still have only 1
checkbox next to each category, but change it from the current "CAN HAVE"
to the "MUST HAVE".
Anyway, if all this functionality were in kpcli, it would be awesome.
The way I get around this in KPI is to click on the Open Password Generator
dialog, then select the necessary categories, then click on the "Preview"
tab, and choose one of the passwords that DOES have all the required
character types.
This is, of course, important, because many websites have their own
requirements (e.g., "You must have at least one upper-case, one lower-case,
one digit, and one special character"..) so getting it right requires the
"MUST HAVE AT LEAST 1".
It would be nice if this additional functionality were also in kpcli --
again, unless I've missed something obvious?
thanks!
js
2015-09-27 7:20 GMT-07:00 Lester Hightower hightowe@users.sf.net:
Related
Feature Requests:
#11I added some more detail to this error message, as follows: