But it's open source and I can't expect someone do this for me so I scratch my own itch.īeta Was this translation helpful? Give feedback. Actually, even having a CLI way to talk to the running GUI app like the browser extension does would be nice. I agree, that's something I'd appreciate keepassxc-cli having out-of-box. and something else I clearly have not thought / cared about. The downside of this approach is that for security you'd have to implement database locking on timeout and other events like the GUI version does. And I don't think working in a shell productively is possible without completion for the tools one uses frequently. No one actually expects a CLI program to behave the way you suggest. Anyway, that's how things supposed to work by design. Again, it is more complicated to solve externally, than internally.ĭepends on the shell. I am not sure if you have written CLI completion scripts. Also as completing entries' names would be possible you wouldn't need globbing while using your CLI tool interactively. Which is of course the proper way of doing this. You just tell about it and break.īTW, with this approach 2nd feature could be nicely implemented using programmable shell completion. There's no way you can handle an error anyway. You just reprint whatever comes out of keepassxc-cli's stderr. However, from my side, that means parsing text, and seeing all the possible problems and deciding which is which.įrom keepassxc's side, it means carefully designing the (specific) interaction / use case. For instance, a UNIX socket for communicating with the wrapper and a CLI tool. the cli) tooīeta Was this translation helpful? Give Not sure if I understand your 4th case correctly, but why not write a wrapper to have your CLI instance running in 'open' mode as a daemon? Once started that wrapper handles CLI's std and exposes whatever interface to the rest of your environment. keepassxc-cli locate followed by keepassxc-cli show, it might be more user-friendly to just give me hints, and take hints yourself (i.e. While, it is true, for 3, I could do e.g. Possible Solution ContextĬLI tools from GUI should be done as. If that means you would output non-error information on stderr (which, I cannot think of besides the db unlock password prompt), I think it's a contract worth breaking for this case. "If you can write to /dev/tty", then send all output there, and password-only to stdout.Īssuming that keepassxc-cli show is the API some program would bind to ask for information, including passwords, then IMHO stdout should be "reserved" for that communication.Send the prompt stream (and a possible "db password error") on stderr and the password, and only the password, on stdout, or. After "figuring out", the user might wonder why is his password wrong.With the additional issue of keepassxc not producing any output, this will only confuse an unexpecting user. In the normal case, not echoing typed characters is okay. But that's already forwarded so nothing to see here What happens from here on, is complicated for two reasons: # No one said all examples can make a lot of sense ~$ bery-sekur-program-wants-pass-stdin <(keepassxc-cli show -attributes Password db.kdbx 'entry with spaces ' )
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |