[Pharo-project] EvaluateCommandLineHandler changes
Hi Camillo, the latest introduction of this: "check if we have an opened stdin" FileStream stdin ifNotNilDo:[ :stream| stream atEnd ifFalse: [ ^ true ]]. (I assume for piping?) Is messing with my other command line args... lets say I have another command line argument that runs tests and I do: Vm image --tests It tries to open it with the EvaluateCommandLineHandler :S... Args is: an OrderedCollection('--test') And the command line handlers after selecting the responsibles are: an OrderedCollection(EvaluateCommandLineHandler RunTestsCommandLineHandler DefaultCommandLineHandler) By now I'll try putting my handler a higher priority (1 :P), but, is this the expected behavior?
On 2012-06-28, at 21:31, Guillermo Polito wrote:
Hi Camillo,
the latest introduction of this:
"check if we have an opened stdin" FileStream stdin ifNotNilDo:[ :stream| stream atEnd ifFalse: [ ^ true ]].
(I assume for piping?)
exactly....
Is messing with my other command line args... lets say I have another command line argument that runs tests and I do:
Vm image --tests
It tries to open it with the EvaluateCommandLineHandler :S...
Args is:
an OrderedCollection('--test')
And the command line handlers after selecting the responsibles are:
an OrderedCollection(EvaluateCommandLineHandler RunTestsCommandLineHandler DefaultCommandLineHandler)
By now I'll try putting my handler a higher priority (1 :P), but, is this the expected behavior?
you're right, that's broken (AKA we should add some tests there :P) I wanted to write something different there... (super isResponsibleFor: args)
On 2012-06-28, at 22:01, Camillo Bruni wrote:
On 2012-06-28, at 21:31, Guillermo Polito wrote:
Hi Camillo,
the latest introduction of this:
"check if we have an opened stdin" FileStream stdin ifNotNilDo:[ :stream| stream atEnd ifFalse: [ ^ true ]].
(I assume for piping?)
exactly....
Is messing with my other command line args... lets say I have another command line argument that runs tests and I do:
Vm image --tests
It tries to open it with the EvaluateCommandLineHandler :S...
Args is:
an OrderedCollection('--test')
And the command line handlers after selecting the responsibles are:
an OrderedCollection(EvaluateCommandLineHandler RunTestsCommandLineHandler DefaultCommandLineHandler)
By now I'll try putting my handler a higher priority (1 :P), but, is this the expected behavior?
you're right, that's broken (AKA we should add some tests there :P)
I wanted to write something different there...
maybe the filestream test should simply be removed, then piping in commands only works when explicitely specifying the "eval" handler
:3 great. BTW, los command line handlers son la papa :). On Thu, Jun 28, 2012 at 10:03 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2012-06-28, at 22:01, Camillo Bruni wrote:
On 2012-06-28, at 21:31, Guillermo Polito wrote:
Hi Camillo,
the latest introduction of this:
"check if we have an opened stdin" FileStream stdin ifNotNilDo:[ :stream| stream atEnd ifFalse: [ ^ true ]].
(I assume for piping?)
exactly....
Is messing with my other command line args... lets say I have another command line argument that runs tests and I do:
Vm image --tests
It tries to open it with the EvaluateCommandLineHandler :S...
Args is:
an OrderedCollection('--test')
And the command line handlers after selecting the responsibles are:
an OrderedCollection(EvaluateCommandLineHandler RunTestsCommandLineHandler DefaultCommandLineHandler)
By now I'll try putting my handler a higher priority (1 :P), but, is this the expected behavior?
you're right, that's broken (AKA we should add some tests there :P)
I wanted to write something different there...
maybe the filestream test should simply be removed, then piping in commands only works when explicitely specifying the "eval" handler
What if the fileIn is just joined at the end of the argument list for every handler? That way you will be able to do echo "-eval blabla" | Vm Image or echo blabla | Vm Image -eval ls | grep fuel | vm image On Thu, Jun 28, 2012 at 10:06 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
:3 great. BTW, los command line handlers son la papa :).
On Thu, Jun 28, 2012 at 10:03 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2012-06-28, at 22:01, Camillo Bruni wrote:
On 2012-06-28, at 21:31, Guillermo Polito wrote:
Hi Camillo,
the latest introduction of this:
"check if we have an opened stdin" FileStream stdin ifNotNilDo:[ :stream| stream atEnd ifFalse: [ ^ true ]].
(I assume for piping?)
exactly....
Is messing with my other command line args... lets say I have another command line argument that runs tests and I do:
Vm image --tests
It tries to open it with the EvaluateCommandLineHandler :S...
Args is:
an OrderedCollection('--test')
And the command line handlers after selecting the responsibles are:
an OrderedCollection(EvaluateCommandLineHandler RunTestsCommandLineHandler DefaultCommandLineHandler)
By now I'll try putting my handler a higher priority (1 :P), but, is this the expected behavior?
you're right, that's broken (AKA we should add some tests there :P)
I wanted to write something different there...
maybe the filestream test should simply be removed, then piping in commands only works when explicitely specifying the "eval" handler
On Fri, Jun 29, 2012 at 8:40 AM, Guillermo Polito <guillermopolito@gmail.com
wrote:
What if the fileIn is just joined at the end of the argument list for every handler? That way you will be able to do
meant stdin :)
echo "-eval blabla" | Vm Image
or
echo blabla | Vm Image -eval
ls | grep fuel | vm image
On Thu, Jun 28, 2012 at 10:06 PM, Guillermo Polito < guillermopolito@gmail.com> wrote:
:3 great. BTW, los command line handlers son la papa :).
On Thu, Jun 28, 2012 at 10:03 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2012-06-28, at 22:01, Camillo Bruni wrote:
On 2012-06-28, at 21:31, Guillermo Polito wrote:
Hi Camillo,
the latest introduction of this:
"check if we have an opened stdin" FileStream stdin ifNotNilDo:[ :stream| stream atEnd ifFalse: [ ^ true ]].
(I assume for piping?)
exactly....
Is messing with my other command line args... lets say I have another command line argument that runs tests and I do:
Vm image --tests
It tries to open it with the EvaluateCommandLineHandler :S...
Args is:
an OrderedCollection('--test')
And the command line handlers after selecting the responsibles are:
an OrderedCollection(EvaluateCommandLineHandler RunTestsCommandLineHandler DefaultCommandLineHandler)
By now I'll try putting my handler a higher priority (1 :P), but, is this the expected behavior?
you're right, that's broken (AKA we should add some tests there :P)
I wanted to write something different there...
maybe the filestream test should simply be removed, then piping in commands only works when explicitely specifying the "eval" handler
On 2012-06-29, at 08:40, Guillermo Polito wrote:
On Fri, Jun 29, 2012 at 8:40 AM, Guillermo Polito <guillermopolito@gmail.com
wrote:
What if the fileIn is just joined at the end of the argument list for every handler? That way you will be able to do
meant stdin :)
echo "-eval blabla" | Vm Image
or
echo blabla | Vm Image -eval
ls | grep fuel | vm image
why not :) We can easily do that with another command-line class which always returns true for #isReponsible: but has a very low priority :)
But why another handler if you could put that in the CommandLineArguments? On Fri, Jun 29, 2012 at 9:06 AM, Camillo Bruni <camillobruni@gmail.com>wrote:
On 2012-06-29, at 08:40, Guillermo Polito wrote:
On Fri, Jun 29, 2012 at 8:40 AM, Guillermo Polito < guillermopolito@gmail.com
wrote:
What if the fileIn is just joined at the end of the argument list for every handler? That way you will be able to do
meant stdin :)
echo "-eval blabla" | Vm Image
or
echo blabla | Vm Image -eval
ls | grep fuel | vm image
why not :) We can easily do that with another command-line class which always returns true for #isReponsible: but has a very low priority :)
participants (2)
-
Camillo Bruni -
Guillermo Polito