As far as I see it, you use the two in distinct cases: - save alone is exclusively used for copying an image. There is no point in no quitting in this case. - execution+save is used either to start a server process (hence noquit is desired), or to setup an image (hence, quit is desired). I think favoring the server process is possibly the more common case. On the other hand, you are right in that it is not uniform with respect to the first case, but I think it is not unreasonable. Doru On Tue, Feb 18, 2014 at 3:55 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

true Tudor.

Do you know why the default behaviour is inverted for that case?

sebastian <https://about.me/sebastianconcept>

o/

On Feb 18, 2014, at 11:47 AM, Tudor Girba <tudor@tudorgirba.com> wrote:

You can find the answer to your question in the class comment:

Usage: st [--help] [ --quit ] <FILE> --help list this help message --quit if specified, the image exits without saving after evaluating FILE --save if specified, save the image after evaluating FILE <FILE> a file containing valid Pharo expressions

Documentation: The ST command line handler runs Pharo code stored in a file without quiting.

Example:

pharo Pharo.image st code.st # By default files ending in .st are recognized and evaluated pharo Pharo.image code.st

Doru

On Tue, Feb 18, 2014 at 3:27 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

...

Hi there,

can someone clarify this for me?

lets say you execute in the terminal:

pharo-vm-nox some.image save awesome.image --delete-old

it starts, saves the image and deletes the old one and quits returning control to terminal

but if you do:

pharo-vm-nox some.image ImageBuilder.st save awesome.image --delete-old

it stays forever open

I was taking a look at this but what is 'quit' option? can someone explain the behaviour of this please?

STCommandLineHandler>>end | quit |

quit := self commandLine hasOption: 'quit'.

(self commandLine hasOption: 'save') ifTrue: [ Smalltalk snapshot: true andQuit: quit ].

quit ifTrue: [ self exitSuccess ].

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

1. It’s worth mention that for starting a server image you can also install/hook to the #startUp: message in the right class with the benefit of not relying in an external script that might generate a problem not tested by the image builder or CI environment (which is what I’m doing BTW)

Can you precise what you mean by image builder / CI environment?

2. it currently doesn’t work. You can send an .st script alright and the save will be ignored (so you have to do that in two commands not one)

Yes, I wanted to tell you that you cannot execute multiple commands at once. I think that is your original cause of errors (note this is partially document in the --help). Additionally, yes, the current CLI is very permissive, aka trailing arguments are just ignored and not reported.

3. You don’t have a server if you don’t have its image prepared first. So, to be “reasonable" you have to (a) break the flow of the experience and (b) break the consistency with the default script behaviour.

I don't understand what you mean here. If you run a script, you can control everything in there: - installing sofware - saving the image - quiting the image So technically you don't need the save command or anything, you rely on Pharo. The other option is to rely on several separate external commands, which will give you a more bash-like behavior. Typically this is what we do on jenkins to avoid the tedious task to maintain external scripts: - install new software with the #configuration command - save the image with a different name - start the server using the #eval command

Both at the same time. If you want to decree that the current behaviour is reasonable you have to do both: disregard the flow of the experience and the consistency of the pharo script-ish default behaviour. But that only after you fix the bug