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

[John W. Eaton]

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.

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.

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.

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?

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.

jwe