-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix chamber env
and chamber export -f dotenv
#385
Conversation
a6fe5eb
to
76d59b4
Compare
This was reported in #366: `chamber` made no effort to sanitize keys for either of these commands or formats, which can result in invalid variable names being used for both of these output formats. Some of the construction of these formats have now been unified, with an optional boolean flag for `env` to preserve key case -- note that keys will still be sanitized, they just won't be converted to uppercase. Since `export -f dotenv` rewrites values using escape characters, I've made the choice to continue allowing `export -f dotenv` to always convert keys to uppercase.
This ensures that `--help` comes after our defined flags, and looks a little more consistent and professional. Might add it to other flags in a separate PR but this is a good start.
76d59b4
to
7fab801
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice.
Nothing immediately glaring at me, but a few open questions.
Thanks for doing this @mckern! Having this be consistent it amazing
Also added a note about sort.Strings() being case-sensitive.
Since I switched to using append() for env.sortedKeys() instead of using an iterator, it's easier to initialize an empty slice and let it reslice as needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have really one comment repeated about a test case for when we're validating/sanitizing shell keys.
I have no strong feelings one way or another and this LGTM as is.
Thanks!
This was reported in #366:
chamber
made no effort to sanitize keys for either of these commands or formats, which can result in invalid variable names being used for both of these output formats. This PR fixes half of the problem (invalid characters in retrieved keys when rendered viaenv
orexport -f dotenv
) but does not address the larger question of "what is a valid character when writing a key?"Some of the construction of these formats have now been unified, with an optional boolean flag for
env
to preserve key case -- note that keys will still be sanitized, they just won't be converted to uppercase. Sinceexport -f dotenv
rewrites values using escape characters, I've made the choice to continue allowingexport -f dotenv
to always convert keys to uppercase.New Flags
chamber env
has received a couple of new flags:-e, --escape-strings
,-p, --preserve-case
:--escape-strings
will allowchamber env
to print values as either safely quoted string literals or safely quoted escape sequences.--preserve-case
will forcechamber env
to respect whatever case a key originally usedBefore
After
What about backwards compatibility?
Effort has been taken to preserve the spirit of backwards compatibility with the output formats that these commands have rendered in the past. But since the formats were objectively incorrect, I'm really not worried about it.