Re: Conflicting start-up options: --eval and script.m

[Andreas Weber]

Am 04.01.2015 um 04:11 schrieb Rik:

> ... I attempted to make the two options mutually
> exclusive, but there are issues with Makefiles and the building of the
> documentation.  Now, we could make the documentation build single-threaded
> (make -j1) and then the mutual exclusivity could be re-instated.

The .NOTPARALLEL directive would indeed avoid the isatty problem in our
build system but not beeing able to use octave with a detached stdin (as
it happens in make -j4)[1] would be IMHO a big drawback for the user.

I regularly use Octave in Makefiles where it processes dozens of
different logfiles and many of the targets could be run parallel so I
typically use "make -j8" on my Phenom X6.

Can't we just document the modified behaviour without making them mutual
exclusivity.

If I get that correct this could be:

--eval "code" pairs are processed first and are concatenated from left
to right until the first non option parameter is detected.

Afterwards the first remaining parameters is treated as script, all
other parameters are arguments for the script and passed to it via argv.

Afterwards stdin is read (always, not only with persist) and executed.


Some examples:
* octave -q -f --eval "code_a" file_a foo bar < file_c

  Would evaluate "code_a", then file_a with argv = {"foo", "bar"} and
then read and process file_c.


Typical mistakes:
* octave -q -f --eval "code_a" file_a --eval "code_b"

  Would evaluate "code_a", then file_a with argv = {"--eval", "code_b"}

* octave -q -f file_a file_b

  Would execute file_a with argv = {"file_b"}


[1]
https://www.gnu.org/software/make/manual/html_node/Parallel-Input.html#Parallel-Input