Guillermo Polito <guillermopol...@gmail.com> 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 > >
What is the conclusion from this and issue 22658? See PR 2238. #getEnv: is public API Stephan
