On 12/12/08, Ludovic Rousseau <ludovic.rouss...@gmail.com> wrote: > >> > > >> > I understand this... But having too many options is also makes it > >> > difficult for people to use the tool. > >> > > >> > >> I'm a firm believer in the 'explorer' approach to command line utilities. > >> This means that the tools should always work and do something useful with > >> minimal options and allow to tweak and expand the functionality in a > >> consistent way as you learn. > > > > I disagree. When the subject is complex and/or sensitive and/or > > none-reversible the above does not apply. Token management is complex, > > sensitive and sometimes none-reversible. > > > I agree with Martin here. A list-like command should list all objects > from all slots of all tokens -- by default -- without having to > specify each token and slot. The user can ask more specific/restricted > output using options.
There are two issues here: 1. Add more and more standalone options. (For example separate option to list slots with token and without). 2. Having more output by default from query. You did not address the first issue... So I guess you agree with the second one. Listing all slots is better than having opensc specific code (all virtual slots of one token), but then if you specify --login to this option and you don't have the same PIN for all tokens, you start increasing the login failure counter... Running this command a few more times and you lock few tokens. > Of course the output should be clear to indicate the token and slot > information of each object. Maybe something like the getinfo.py [1] > tool. > > What could be none-reversible when using a "display all objects" command? One example: pkcs11-tool --list-objects --login --pin '11111111' These tools must be consistant... and a solution of --list-objects without --login works using a specific slot and --list-objects without --login list all slots is none consistant. Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
