Hm, it looks like you are right.  When I pass the argument directly to squeak:

  squeak my.image my.script 'hello world' &

and 'hello world' came in as a single-argument.  So I've got some bashing to do.

Thanks, and sorry for the false alarm.

 - Chris

PS - is there a Linux "best practice" or overall preference regarding
command-line arguments vs. stdin?  stdin would allow redirection of
Smalltalk scripts, as well as the convenience of raw stream input via
the keyboard (e.g., not having to worry about escape chars), so I'm
leaning that way...


On Fri, Oct 8, 2010 at 4:10 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 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"..
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>