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: Tue, 24 Feb 2015 20:00:00 +0000

On 21 January 2015 at 17:40, John W. Eaton <address@hidden> wrote:
> On 01/21/2015 12:11 PM, Carnë Draug wrote:
>>
>> 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)
>
>
> In the meantime, I checked in a separate patch in addition to Rik's that has
> the same effect:
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/f3ac54ac2c6a
>

This did not fix it because it only checks if the session is interactive
(or forced interactive), and that is only dependent on availability of
stdin and stdout.  When we have a script file with a shebang line, it will
think it's an interactive session and print startup notice anyway.

>
> In any case, I agree that we should also avoid the startup message unless we
> are interactive or forced interactive.  And that reading input from a script
> file should probably not be considered an interactive session (unless that
> has some other consequence, like closing stdin and not allowing user
> interaction; I can't remember if that is the case).
>

I started a non-interactive session (by hardcoding interactive to false)
and was still able to use the input(), puts(), and display() functions.
I am guessing we can set interactive to false for those cases.

>
> So if there is a cleaner
> solution than the combination of Rik's patch and mine, please go ahead and
> use it.
>

I think I have done this now [1].  During input check we decide if this is
to run like an octave program, or if we want to have a session in the end.
This takes into account the persist.  This is then used to set the value
of interactive.  The reason of the extra variable is because we check if
we have a script file by checking "optind" and we want to make use of that
later.

Also, as mentioned before, I made some changes to the logic of interactive
and forced_interactive [2] so that interactive really means whether the
session is interactive (instead of maybe it is interactive, but requiring
double check with forced_interactive).


Finally, should we be reading .octaverc if we are running an Octave program?
It is not nice to start every program with:

    pkg unload all;
    clear all;
    close all;

Does this make sense? I would imagine that someone writing an Octave program,
would expect to start from a clean sheet.

Carnë

[1] http://hg.savannah.gnu.org/hgweb/octave/rev/f81a1da191e4
[2] http://hg.savannah.gnu.org/hgweb/octave/rev/1c9ed5b4c73d
X-RMAIL-ATTRIBUTES: --------





reply via email to

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