Squeak does it right. I suspect your "st" script is broken.

- Bert -


On 08.10.2010, at 09:44, Chris Muller wrote:

>> Of course.  Try it and see.  This is a shell issue.  What's the syntax to
>> supply an arg containing spaces.  On Unix there are
>> two^H^H^Hthree^H^H^H^H^Hfour ways.  Escape spaces with back slashes, use IFS
>> to make space a non-separator and separate words using e.g. TAB (I think
>> this works), surround the argument with single quotes or surround the arg
>> with double quotes.
> 
> Right I did try all of those things of course (except adjusting IFS),
> but it appears that Squeak puts its own interpretation onto these
> arguments differently from the shell.  IOW, Squeak appears to be doing
> a simple subStrings operation regardless of escape-characters when
> loading up the systemAttribute array...  For example:
> 
>  st '1000 factorial'    <----- Squeak gets 2 args, '1000' and 'factorial'
>  st "1000\ factorial"    <----- Squeak gets 2 args, '1000\' and 'factorial'
> 
> Strings are a challenge because the shell does not allow single-ticks
> inside of single-ticks, but one can use Symbols:
> 
>  st '#hello asString asUppercase'   <--------- Squeak gets 3 args...
> 
> My goal is to deliver a "Smalltalk command-line".  I did find that
> your stdin works, so I can do:
> 
>  st <<printit
> 'hello' asUppercase
> printit
> 
> works.  :)
> 
> 
>>> 
>>> I actually want to allow the Linux user to specify a chunk of code
>>> (which contains spaces) on the command-line.
>>> 
>>> I tried enclosing it in ticks, but Squeak still loaded each
>>> system-attribute into its own slot.  Interestingly, it did not include
>>> the beginning or ending tick.
>>> 
>>> So, it looks like I could assemble all of the pieces, separatedBy:
>>> Character space, but that would limit the chunk to 997 "words"..
>>> 
>> 
>> 
>> 
>> 
>> 
>