On Mon, 12 Nov 2018 at 18:02, Guillermo Polito <[email protected]> wrote:
> Hi all, > > following the meeting we had here @Inria headquarters, I'll be backporting > some of the improvements we did in the launcher this last month regarding > the encoding of environment variables. > > I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/ > > We have already studied possible alternatives with Pablo and Christophe > and we have some conclusions and we propose some changes: > > API Proposal for OSEnvironment > ========================= > > > - > *at: aVariableName * > > Gets the String value of an environment variable called `aVariableName` > It is the system reponsibility to manage the encoding. > Rationale: A common denominator for all platforms providing an already > decoded string, because windows does not (compared to *nix systems) provide > a encoded byte representation of the value. Windows has instead its own > wide string representation. > > - *[optionally] rawAt: anEncodedVariableName* > > Gets the Byte value of an environment variable called > `anEncodedVariableName`. > It is the user responsibility to encode and decode argument and return > values in the encoding of this preference. > Rationale: Some systems may want to have the liberty to use different > encodings, or even to put binary data in the variables. > > - *[optionally] at: aVariableName encoding: anEncoding* > > Gets the value of an environment variable called `aVariableName` using > `anEncoding` to encode/decode arguments and return values. > Rationale: *xes could potentially use different encodings for their > environment variables or even use different encodings in different parts of > their file system. > > Other Implementation details > ========================= > > - VM primitives returning paths Strings should be carefuly managed to > decode them, since they are actually C strings (so byte arrays) disguised > as ByteStrings. > - Windows requires calling the right *Wide version of the functions > from C, plus the correct encoding routine. This could be implemented as an > FFI call or by modifying the VM to do it properly instead of calling the > Ascii version > > I haven't been using environment variables a lot so I don't have a strong technical opinion (although at a glance it makes reasonable sense). But I wanted to say I really like the way you've presented your offline discussion, conclusions and proposal. Thanks. cheers -ben
