If I'm not mistaken, this is Pharo's eval command line handler you're
talking about. If so, it is not correct to say 'it also return the result
of that method or yourself'. To return the result (and print it to stdout)
of that method is the goal of eval command line handler.
How about making your method to return empty string, or better create your
own command line handler. I believe the minimal you need to do is to
subclass EvaluateCommandLineHandler, override class method #commandName and
override method #evaluate:. Something like this, perhaps
ProceesCommandLineHandler class >> commandName
^ 'process'
ProcessCommandLineHandler >> evaluate: aStream
Smalltalk evaluate: aStream.
Save your image, then you can call
./pharo -headless myimage.image process StandardFileStream stdout print: 42
and it'll print 42 and nothing else.
I'm not sure I understand the double quote (") character issue that \"
solves. Example?
On Thu, Jun 29, 2017 at 7:02 AM, Tim Mackinnon <tim@testit.works> wrote:
> Hi - I've been playing with using Pharo with Aws lambda and have got an
> image to launch in that environment.
>
> However now I need to better integrate Pharo with its calling environment
> - and I know there was a concerted effort to make Pharo play better which I
> should be able to leverage.
>
> So I am calling Pharo from a NodeJS wrapper (the suggested aws method
> for integrating alternative languages like Ruby, Go etc).
>
> I got this to work - however as an observation, it is rather awkward
> passing parameters to Pharo using the "eval" mechanism as other languages
> and environments frequently use the " character (particularly with Json)
> and this causes Pharo to fail if you don't \" this. I'm wondering if others
> have noted this and whether we can do this better somehow? For now a little
> nodeJS regex fu gets me past it.
>
> However my next question is about passing information back to the calling
> application.
>
> I can see that there is a stdout method on Fikestream that I can write to
> (great), however in my ./pharo eval call, which sends to a class method
> doing this - it also returns the result of that method or yourself? I guess
> this convention is great for the "eval 42 factorial" example but not so
> great of you just want to return some Json via stdout in a format of the
> calling environment?
>
> Is there something simple trick I can do to stop this extra result and
> just let me use stdout myself? Or do I have to return a Smalltalk string
> and then regex convert it to a new format in my calling language?
>
> I'm wondering if others have done this, or if anyone has some advice?
>
> It feels like a usecase that we might be able to do better somehow?
>
> Tim
>
> Sent from my iPhone
>
>
