Yes, for some reason, the shebang (#!) machinery passes ./test2.st as argument to pharo, which it seems can only be resolved if it is in the image directory (as opposed to the current shell directory).

I have no time to look at this now, but I vaguely remember that pharo mixed the concept of current working directory and image directory (at least in some places).

On 25 Jul 2014, at 21:43, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:

> Sven,
> Without putting a test.st file in /Users/daleh/gsDevKitHome/pharo, I get the following (it works if I `cp ./test.st /Users/daleh/gsDevKitHome/pharo`):
>
> nehalem:junk daleh$ pwd
> /Users/daleh/junk
> nehalem:junk daleh$ cat test.st
> #!/Users/daleh/gsDevKitHome/pharo/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/daleh/gsDevKitHome/pharo/todeClient.image st --quit
> FileStream stdout nextPutAll: 42 factorial asString; cr.
> nehalem:junk daleh$ ./test.st
> FileDoesNotExist: File @ /Users/daleh/gsDevKitHome/pharo/test.st
> FileHandle>>streamError
> FileHandle>>readStream
> FileSystem>>readStreamOn:
> FileReference>>readStream
> FileReference(AbstractFileReference)>>readStreamDo:
> STCommandLineHandler>>installSourceFile:
> STCommandLineHandler>>installSourceFiles in Block: [ :reference | self installSourceFile: reference ]...etc...
> OrderedCollection>>do:
> STCommandLineHandler>>installSourceFiles in Block: [ sourceFiles do: [ :reference | self installSourc...etc...
> BlockClosure>>ensure:
> STCommandLineHandler>>installSourceFiles
> STCommandLineHandler>>activate
> STCommandLineHandler class(CommandLineHandler class)>>activateWith:
> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: in Block: [ aCommandLinehandler activateWith: commandLine ]
> BlockClosure>>on:do:
> PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand:
> PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand
> PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument:
> PharoCommandLineHandler(BasicCommandLineHandler)>>activate in Block: [ self handleArgument: (self arguments ifEmpty: [ ...etc...
> BlockClosure>>on:do:
> PharoCommandLineHandler(BasicCommandLineHandler)>>activate
> PharoCommandLineHandler>>activate
> PharoCommandLineHandler class(CommandLineHandler class)>>activateWith:
> PharoCommandLineHandler class>>activateWith: in Block: [ super activateWith: aCommandLine ]
> WorldState>>runStepMethodsIn:
> WorldMorph>>runStepMethods
> WorldState>>doOneCycleNowFor:
> WorldState>>doOneCycleFor:
> WorldMorph>>doOneCycle
> MorphicUIManager>>spawnNewProcess in Block: [ ...
>
>
>
> On Fri, Jul 25, 2014 at 12:29 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
>
> On 25 Jul 2014, at 21:25, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
>
> > Sven,
> >
> > I'm using Pharo3.0 and it appears that the .st scripts have to be located in the same directory as the image and changes files ��... I see that you are using Pharo4.0 ...
> >
> > So is it possible to get Pharo3.0 to work on .st files in arbitary directores?
>
> Are you using the shebang or direct version ?
> In any case, I am always using absolute paths.
> Does that not work for you ?
>
> > Dale
> >
> >
> > On Thu, Jul 24, 2014 at 7:42 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
> >
> > On 24 Jul 2014, at 16:34, phil@highoctane.be wrote:
> >
> > > One question I have is how fast the load of an image and processing by an image is when compared with bash.
> >
> > Obviously, it is slower, there is a whole image that needs to be loaded, etc.
> >
> > $ cat test.st
> > #!/Users/sven/tmp/pharo4/pharo-vm/Pharo.app/Contents/MacOS/Pharo --headless /Users/sven/tmp/pharo4/Pharo.image st --quit
> > FileStream stdout nextPutAll: 42 factorial asString; cr.
> >
> > $ time ./test.st
> > 1405006117752879898543142606244511569936384000000000
> >
> > real �� ��0m0.644s
> > user �� ��0m0.516s
> > sys �� �� 0m0.067s
> >
> > So about half a second overhead.
> >
> > Sven
> >
>
>
>