Currently we only evaluate the last --eval <code> argument. This makes it impossible to build up a sequence of code to run via separate --eval arguments, which is often useful. Our current behavior is also at odds with Perl and Ruby which are generally considered to be good models for useful CLI behavior:
$ perl -e 'print("this\n");' -e 'print("that\n");'
this
that
$ ruby -e 'print("this\n");' -e 'print("that\n");'
this
thatIn Python, the first occurrence of -c terminates option parsing, which we do not do, so following Python here would not make sense. A more conservative choice would be erroring on multiple --eval options, which would allow us to change the behavior in the future without breaking code.
Currently we only evaluate the last
--eval <code>argument. This makes it impossible to build up a sequence of code to run via separate--evalarguments, which is often useful. Our current behavior is also at odds with Perl and Ruby which are generally considered to be good models for useful CLI behavior:In Python, the first occurrence of
-cterminates option parsing, which we do not do, so following Python here would not make sense. A more conservative choice would be erroring on multiple--evaloptions, which would allow us to change the behavior in the future without breaking code.