Sun 04 Jan 2015 03:19:51 AM UTC, comment #12:
Well, one thing that would be easy would be to add the .NOTPARALLEL directive to Makefile.am in doc/interpreter. This forces the directory in question to be built with the equivalent of 'make -j1'.
|
Sat 03 Jan 2015 05:53:05 PM UTC, comment #11:
Andreas' analysis is certainly correct. I put in some printf statements to stderr and in a group of make subprocesses spawned at the same time only one of the instances has isatty true. This could be because isatty is not re-entrant, or it could be that stdin isn't getting dup'ed to the child processes, or there is a race condition.
In any case, I don't think many people try to invoke octave with both a redirect and an --eval or script file. I don't want to spend more time on this bug than it is worth so I simply took out the tests in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/65f4d9e1206c).
|
Sat 03 Jan 2015 03:58:14 PM UTC, comment #10:
It's described here: https://www.gnu.org/software/make/manual/html_node/Parallel-Input.html#Parallel-Input
We should somehow check for the "broken pipe" condition.
|
Sat 03 Jan 2015 03:25:55 PM UTC, comment #9:
@Andy: Yes I was parallel building using "make -j4", and I can confirm using "make" lets the doc build as expected.
I also can confirm that running your "Makefile_check" with two jobs triggers the error in the second job:
|
Sat 03 Jan 2015 02:18:09 PM UTC, comment #8:
I made some checks
when run from "make -j3" with multiple independent targets returns one false, two true.
Run attached Makefile with "make -j2 -f Makefile_check" to trigger the bug.
(file #32752)
|
Sat 03 Jan 2015 01:51:08 PM UTC, comment #7:
@Pantxo: You were parallel building with "make -j4" or something, right?
I can see this too but only with parallel build. Is it possible that
+verbatim
bool stdin_is_tty = gnulib::isatty (fileno (stdin));
-verbatim-
returns false if called from make during a parallel build?
|
Sat 03 Jan 2015 11:38:23 AM UTC, comment #6:
Hi,
I can't build the doc anymore:
@Rik: I suppose this is due to your last changeset. Do you have an idea how should the command line call to "run-octave" be tweaked in order to have it work again?
|
Sat 03 Jan 2015 02:19:25 AM UTC, comment #5:
I made the 3 options of --eval CODE, script file, and '< script' mutually exclusive in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/18377fc879d0). Closing report.
|
Sat 20 Apr 2013 08:29:44 PM UTC, comment #4:
Changing status and retitling for clarity.
|
Wed 11 Apr 2012 06:29:22 PM UTC, comment #3:
Okay. I see the issue now. I think it would be clearer if --eval and supplying a file or raw code on stdin were mutually exclusive options. I'll take a look at that.
|
Wed 11 Apr 2012 05:15:17 PM UTC, comment #2:
no change (using current tip of April 11).
Note that this is not about staying in octave or not, but about whether 'disp(e)' is executed.
|
Wed 11 Apr 2012 06:46:07 AM UTC, comment #1:
This works for me. I tested both versions in both Bourne sh and in tcsh and they exit without staying in Octave. This is for a recent tip (4/10/12).
Could you reverify that this behavior still exists for you? Also, to make sure it is nothing in your .octaverc try adding '-f' to the command line so it reads
|
Mon 16 Jan 2012 07:40:16 PM UTC, original submission:
The help on command line options has
`--eval CODE'
Evaluate CODE and exit when done unless `--persist' is also
specified.
but octave does not exit when invoked with a script file, such as
It does exit when the script is invoked from stdin:
I suggest a phrase like 'and exit if FILE is empty' as help text.
|