[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