octave-maintainers
[Top][All Lists]
Advanced

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

Re: eliminating start-up message for non-interactive sessions


From: Carnë Draug
Subject: Re: eliminating start-up message for non-interactive sessions
Date: Wed, 21 Jan 2015 17:11:29 +0000

On 21 January 2015 at 01:38, Rik <address@hidden> wrote:
>
> Your suggestion made a lot of sense so I implemented it in this cset
> (http://hg.savannah.gnu.org/hgweb/octave/rev/6ba5f1ff041e).  It still
> prints the start-up message if you use input redirection to feed Octave a
> script, but I don't think many people do that.  It certainly handles the
> shebang case and the --eval CODE case.
>

Hi Rik

I was thinking of taking a different approach at this which covers the
case of having the code sent to STDIN.  Instead of disabling the display
of the message when there is --eval or script file, only display the
message for interactive sessions and change he value of interactive
when there is a script and code to eval.  Here it is (inlined because it
is so simple)


--- a/libinterp/octave.cc       Tue Jan 20 13:43:29 2015 -0500
+++ b/libinterp/octave.cc       Wed Jan 21 16:40:14 2015 +0000
@@ -789,8 +789,9 @@
   // a redirected file.
   bool stdin_is_tty = gnulib::isatty (fileno (stdin));

-  interactive = (! embedded && stdin_is_tty
-                 && gnulib::isatty (fileno (stdout)));
+  interactive = ((! embedded && stdin_is_tty
+                  && gnulib::isatty (fileno (stdout)))
+                 && ((code_to_eval.empty () && (argc - optind) == 0)
|| persist));

   if (! interactive && ! forced_line_editing)
     line_editing = false;
@@ -822,7 +823,7 @@
 int
 octave_execute_interpreter (void)
 {
-  if (! inhibit_startup_message)
+  if ((interactive || forced_interactive) && ! inhibit_startup_message)
     std::cout << octave_startup_message () << "\n" << std::endl;

   octave_prepare_hdf5 ();


The "(argc - optind) == 0)" part is meant to identify a script file
and is already used in octave_process_command_line().  But should this
checks be done a bit earlier?  Should we be setting the value of
"interactive" based on code_to_eval, script_file, and persist already
at the end of octave_process_command_line() ?

Also, about setting a value for interactive, shouldn't interactive be set
to true independent of whether it was forced or not?  If a distinction
between the two is required, it should be done by checking forced_interactive,
and not having to check the two everytime the value of interactive is
required.  Does that make sense?

Carnë



reply via email to

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