Add encrypt-only flag for 'edit' command. #256
Conversation
Enables editing of files with only access to the public key. Already-encrypted values will not be decrypted, but new or replaced values will be encrypted as usual.
| :description => "Don't prefix edit sessions with the informative preamble" }] | ||
| :description => "Don't prefix edit sessions with the informative preamble" }, | ||
| {:name => :encrypt_only, | ||
| :description => "Don't try to decrypt before editing.", |
There was a problem hiding this comment.
What do you think about
:name => :no_decrypt,
:description => "Do not decrypt existing encrypted content. New content marked properly will be encrypted.",
:short => 'nd',
I think that matches the no_ style of the other subcommand. I don't know if the short command can be two letters, though; if not, maybe -e.
There was a problem hiding this comment.
That makes sense, I'll re-submit the pull request. I think a one-letter short command works best for command line standards.
There was a problem hiding this comment.
Ugh. Turns out that the CLI processing library, Trollop, has special handling for options starting with '--no-'. As far as I can tell, this special handling breaks the use of short options to set a flag to true. I prefer to have a short option since I'm going to be using this feature all the time, but that means the long option can't start with --no.
There was a problem hiding this comment.
I believe there is actually an error in the FAQ - this says that it only works for --no-, not --no_ - so the short would still work. It will only take a single character short option, though - maybe -n since that is not taken yet?
There was a problem hiding this comment.
The -n flag is taken by --encrypt-method, so I've used '-d' for now.
--no_decrypt would work, but the :no_preamble symbol actually gets converted to --no-preamble, so they'd look slightly different. I've found an alternate way to get the flags to look good though.
|
@benjunmun Nice! I'm curious what you think about inverting the argument, or maybe inverting the existing argument. |
Convert --encrypt-only flag to --no-decrypt to better match existing flags. Better description of feature
| decrypted_input = tokens.each_with_index.to_a.map{|(t,index)| t.to_decrypted :index => index}.join | ||
| decrypted_file_content = Eyaml::Options[:no_preamble] ? decrypted_input : (self.preamble + decrypted_input) | ||
| # The 'no_' option has special handling - bypass that and just check if a flag was set. | ||
| if Eyaml::Options[:no_decrypt_given] |
There was a problem hiding this comment.
Why does the option have _given appended here? It seems to pass the tests but I’m not able to follow why it works. Thanks.
There was a problem hiding this comment.
This was the only way I could find to have both a long and short option, and have the style match --no-preamble.
My problem is that the -d and --no-decrypt flags are treated as opposites by the library: -d is like saying --decrypt as opposed to --no-decrypt. However, in addition to the :no_decrypt option, the library also sets :no_decrypt_given, which just indicates that a flag in that family of options was set. If this was a string option, the regular option would contain the string, and the _given option would be a boolean indicating that the string was set. In this case where the flag is already a boolean option, it's the only way I could find to test if either the long or short options were set.
There was a problem hiding this comment.
Ah, so it's a Trollop implementation detail. Makes sense, now.
|
Thanks so much for this, a lot of people have been after this feature for a while! |
Enables editing of files with only access to the public key.
Already-encrypted values will not be decrypted, but new or replaced values
will be encrypted as usual.
This is an attempt to resolve #231.