Convention to build cmd-line interfaces with Pharo?

> What I want eventually is the following:
>
>
> $ squeak-vm.sh Pharo-1.2.image --help
> SMark Benchmark Framework, version: SMark-StefanMarr.12
>
> Usage: <vm+image> SMarkHarness [runner] [reporter] <suiteOrBenchmark>
>                               [iterations [processes [problemSize]]]
>
> Arguments:
> runner             optional, a SMarkRunner class that executes the benchmarks
> reporter           optional, a SMarkReporter class that processes
>                              and displays the results
> suiteOrBenchmark   required, either a SMarkSuite with benchmarks,
>                              or a benchmark denoted by Suite.benchName
> iterations         optional, number of times the benchmarks are repeated
> processes          optional, number of processes/threads used by the benchmarks
> problemSize        optional, depending on benchmark for instance number of
>                              inner iterations or size of used data set

> Hi:
>
> Is there any convention/standard approach to build nice cmd-line interfaces with Pharo?
>
> The first road block I encountered is the assumption that the first argument to the image on the command line is a document/script. Which fires an exception if it is not actually a loadable document.
>
> I did not see any way to disable that other than to deinstall Autostart (Autostart>>deinstall).
>
> That is fine for me, but might have unintended consequences.
> The ProjectLauncher>>startUpAfterLogin is the actual place where that assumption is hard coded.
> And, well, I don't know what the consequences are of disabling Autostart and as a consequence ProjectLauncher.
>
> So, are there other ways to get to a clean command-line interface?
>
> What I want eventually is the following:
>
>
> $ squeak-vm.sh Pharo-1.2.image --help
> SMark Benchmark Framework, version: SMark-StefanMarr.12
>
> Usage: <vm+image> SMarkHarness [runner] [reporter] <suiteOrBenchmark>
>                               [iterations [processes [problemSize]]]
>
> Arguments:
> runner             optional, a SMarkRunner class that executes the benchmarks
> reporter           optional, a SMarkReporter class that processes
>                              and displays the results
> suiteOrBenchmark   required, either a SMarkSuite with benchmarks,
>                              or a benchmark denoted by Suite.benchName
> iterations         optional, number of times the benchmarks are repeated
> processes          optional, number of processes/threads used by the benchmarks
> problemSize        optional, depending on benchmark for instance number of
>                              inner iterations or size of used data set
>
> Bye the way, Squeak 4.1 exhibits the same behavior, but I did not notice anything alike in our 3.9 image, there is works just fine.
>
> Best regards
> Stefan
>
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
>
>

>
> On 15 May 2011, at 14:57, Stéphane Ducasse wrote:
>
>> look into 1.3 because we made it better so that you can pass something that is not an cs or st and that
>> you can specify who should handle it and not get the system barking dummily at you.
> That will probably help with Pharo 1.3, thanks.
>
> Unfortunately, that does not help me as an application developer.
> I still want to maintain compatibility with Squeak and Pharo 1.2 since that is the current stable version.
>
> So, I would still appreciate some guidance on what the best approach is to handle such incompatibilities.
> Are there some common practices how to encapsulate these differences?
>

>>
>> As you may know, Squeak was inherently designed to not care about a
>> command-line and any stdio,
>> so we don't have a standartized way to handle command-line and
>> standard input/output :(
>> I don't remember what exactly was done in 1.3. Some cleanup i guess.
>
> not only cleaning, we can specify that a certain extension should be handled in a certain way without breaking
> because this is not 100% smalltalk for example.
> For example a coral script (which has a different syntax than a cs) can be loaded without breaking and breaking the laoding of cs.
>