On Tue, Jan 20, 2015 at 12:35 PM, Sven Van Caekenberghe sven@stfx.eu wrote:
Hi Eliot,
On 20 Jan 2015, at 20:38, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Jan 20, 2015 at 8:00 AM, Sven Van Caekenberghe sven@stfx.eu
wrote:
Command line arguments enter the image level via
VirtualMachine>>#getSystemAttribute:
At that point they are already Strings.
ByteString, according to the primitive. So if the shell supplies e.g.
UTF-8 strings for command-line parameters, which the VM sees as bytes, then the ByteString instances answered by getSystemAttribute: would need decoding, right?
In your case, they must already be wrong at that point.
Not necessarily. The getSystemAttribute: primitive doesn't do
decoding. Perhaps it should.
Yes, probably. I just tried on Mac OS X, Pharo 4:
$ export FOO=élève-Français
$ echo $FOO élève-Français
$ ./pharo Pharo.image eval 'OSPlatform current environment at: #FOO' 'élève-Français'
$ ./pharo Pharo.image eval '(OSPlatform current environment at: #FOO) asByteArray utf8Decoded' 'élève-Français'
The question is, is this true for all platforms ? Windows ?
I'm trying to test this in Pharo 3. I get
KeyNotFound: key #FOO not found in PlatformIndependentEnvironment PlatformIndependentEnvironment(OSEnvironment)>>at: in Block: [ KeyNotFound signalFor: aKey ] UndefinedObject>>ifNil: PlatformIndependentEnvironment(OSEnvironment)>>at:ifAbsent: PlatformIndependentEnvironment(OSEnvironment)>>at: UndefinedObject>>DoIt OpalCompiler>>evaluate OpalCompiler(AbstractCompiler)>>evaluate: SmalltalkImage>>evaluate: EvaluateCommandLineHandler>>evaluate: in Block: [ ... BlockClosure>>on:do:
Does the environment access depend on NativeBoost?
On 20 Jan 2015, at 16:51, Hilaire hilaire@drgeo.eu wrote:
Le 20/01/2015 16:34, Sven Van Caekenberghe a écrit :
No they are not - Strings and Characters in Pharo are using plain
Unicode encoding internally.
Thanks for the update, and the reference link.
Hilaire
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
-- best, Eliot