You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because of all the issues around system shell encoding, we need to support base64 en/de-coding of out/in-put natively within the CLI.
Outstanding question: what do we actually want this control interface to look like? Specifically, do we want to allow turning the encoding on/off independently? I think we need to in order to support reading in unencoded data.
The text was updated successfully, but these errors were encountered:
No. That I vehemently disagree with. Applying encoding like this without being asked to violates our "least surprise" principal. Any time we are doing additional special encoding, it should be very clear that it is being enabled.
Because the only two cases where this encoding is necessary are: 1) piping in PowerShell, and 2) saving results to shell variables, we agreed that it is best to have the encoding off by default.
Because of all the issues around system shell encoding, we need to support base64 en/de-coding of out/in-put natively within the CLI.
Outstanding question: what do we actually want this control interface to look like? Specifically, do we want to allow turning the encoding on/off independently? I think we need to in order to support reading in unencoded data.
The text was updated successfully, but these errors were encountered: