[squeak-dev] script arguments with spaces

Eliot Miranda eliot.miranda at gmail.com
Sat Oct 9 18:51:48 UTC 2010


On Sat, Oct 9, 2010 at 10:54 AM, Chris Muller <asqueaker at gmail.com> wrote:

> 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.
>

You need to use "$@", not $@, $* or "$*".  See the squeak scripts in the Cog
linux VM for an example.

#!/bin/sh
BIN=`/usr/bin/dirname $0`/lib/squeak/3.9-7
# At least on linux LD_LIBRARY_PATH's components must be absolute path names
case "$BIN" in
/*) PLUGINS="$BIN";;
*) PLUGINS="`pwd`/$BIN"
esac
# prepending is less flexible but safer because it ensures we find the
plugins
# in the same directory as the VM.
LD_LIBRARY_PATH=$PLUGINS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} exec
"$BIN/squeak" "$@"


> 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...
>

Since Squeak hasn't been used that much with stdio I would expect there not
to be any best practices.  Instead you should just go ahead and explore.  I
think the point of using stdin is that it allows interactive
experimentation.  In developing a bootstrap from a kernel image tis will
have its uses.  Being able to write pipelined commands in Squeak is fun but
arguably one needs a much better file interface to make this compelling.

>
>
> 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"..
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101009/c078b88f/attachment.htm


More information about the Squeak-dev mailing list