octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Rik
Subject: Re: Conflicting start-up options: --eval and script.m
Date: Sat, 03 Jan 2015 19:11:15 -0800

On 01/03/2015 09:57 AM, John W. Eaton wrote:
> On 12/30/2014 12:38 PM, Rik wrote:
>> 12/30/14
>>
>> I'm looking to solve bug #35318: Unclear precedence between --eval, script
>> file, and stdin  (https://savannah.gnu.org/bugs/?35318).  I don't think the
>> fix will be hard; it is more a matter of deciding what behavior we want.
>

There has been some more discussion and work that has taken place on the
bug report site at https://savannah.gnu.org/bugs/?35318.  Briefly, I
implemented full mutual exclusivity of the three arguments, and then backed
it off to just exclusivity between a script file and --eval code because
there were issues in figuring out whether redirected input was actually
occurring.


> If I understand correctly, the redirection should be handled by the
> shell, so Octave will only see the arguments, not a "< FILE".  The shell
> sees that and hooks up stdin to FILE.

This is indeed what happens.  The "< FILE" argument is eaten by the shell
and we use isatty (stdin) to see whether we are hooked to a terminal
(interactive) or a file (redirected input or pipe).

>
> Some of the arguments are handled immediately (like printing the version
> number) and some (like --eval) are deferred until later because they
> can't be handled until the Octave interpreter is fully initialized, and
> doing that properly requires seeing which options have been given (for
> example, --norc or --no-line-editing).
>
> Also, and again if I understand correctly, getopt will process all
> options (plus optional arguments for those options) first, and rearrange
> the remaining arguments so that they are left until the end.  So unless
> we use our own special version of getopt, I don't think there is a way to
> preserve the order of non-option arguments mixed in with the --eval
> options.  If we want that, then the easiest way would be to have a
> separate "--file FILE" option, but I don't really see the point of doing
> that.  I think it's better to keep things simple.
>
> However, I don't see anything wrong with allowing multiple script files
> on the command line so that you can write
>
>   octave -q -f foo.m bar.m
>
> and have the contents of both foo and bar processed.

getopt doesn't seem to re-order the arguments on my machine, but more
importantly it breaks off option processing when it detects the first
non-option argument.  Instead, any further arguments are passed as input
arguments (ARGV) to the script mentioned.  This is actually pretty
important because you want to be able to call a script and give it
arguments like so:

octave -q -f data_processing_script.m FILE1.dat FILE2.dat FILE3.dat

To add processing for

octave -q -f foo.m bar.m

seems difficult and probably easier to just ask people to combine foo.m and
bar.m into foobar.m and run that.

>
> Also, if documented, it seems OK to me for Octave to process all --eval
> code before going on to script files and command line files.  Instead of
> disallowing --eval mixed with command line files or redirection, wouldn't
> that be a relatively straightforward change from the previous behavior?

This change would be straightforward.  Currently all the eval code is
joined together and run as a block before looking for a script file to
run.  But it would have to be well documented and it might still be simpler
to disallow it.  People will probably understand that

octave --eval 'code' script.m

will run the eval'ed code first and then then script.  But they will then
expect that

octave script.m --eval 'code'

will run the script file first and then the eval'ed code which it won't
do.  Because option processing has stopped this will run script.m with ARGV
of {'--eval', 'code'}.

>
> Also, I just noticed the following behavior.  Given
>
>   octave -q -f file_a < file_b
>
> Octave will process the contents of file_a and stop.  However, . 
>
>   octave -q -f --persist file_a < file_b
>
> will process the contents of file_a and then go on to stdin.  This makes
> some sense, but was surprising to me at first.  I really expected
> --persist to only affect interactive behavior.  So we could make one
> small additional change, which is to always proceed to processing stdin
> if it is not connected to a terminal (i.e., Octave is not interactive).
>  With these proposed changes, things like
>
>   octave -q -f --eval "code_a" file_a --eval "code_b" file_b < file_c
>
> would first evaluate all --eval option code, then process all the given
> files in order.  This makes sense to me and the behavior is easy to
> describe.
>

The behavior with '--persist' is just odd and violates the principle of
least surprisal for UI design. 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.


--Rik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]