octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #65607] cluttering text output when using path


From: Hartmut
Subject: [Octave-bug-tracker] [bug #65607] cluttering text output when using path() with echo on
Date: Thu, 18 Apr 2024 05:54:08 -0400 (EDT)

URL:
  <https://savannah.gnu.org/bugs/?65607>

                 Summary: cluttering text output when using path() with echo
on
                   Group: GNU Octave
               Submitter: hardy
               Submitted: Thu 18 Apr 2024 09:54:08 AM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Regression
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: 9.1.0
         Discussion Lock: Any
        Operating System: Any
           Fixed Release: None
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Thu 18 Apr 2024 09:54:08 AM UTC By: Hartmut <hardy>
I have observed the following behavior with the current Octave 9.1 release.
When I run this demo code (from the Octave console or from within an m-file):


echo off
echo off all
clc
path(path,''); % -> no text on console = OK
echo on
% NOW COMES THE BUG:
path(path,''); % -> a lot of text on console = bug


Then I see very much text output on the Octave console. And in my
understanding this text output should NOT be there, because "echo on" is only
supposed to turn the text output on for the current script and not for
sub-functions. (Also Matlab does not produce this nasty long text output.)

Here is what I get as text output on my Octave installation:


+ echo on
+ % NOW COMES THE BUG:
+ path(path,''); % -> a lot of text on console = bug
+ autoload ("__fltk_check__", "__init_fltk__.oct");
+ if (__have_feature__ ("FLTK") && __have_feature__ ("OPENG
L") && have_window_system () && ! (ismac () && __event_mana
ger_enabled__ ())) register_graphics_toolkit ("fltk"); endi
f
+ autoload ("__have_gnuplot__", "__init_gnuplot__.oct");
+ if (__have_gnuplot__ ()) register_graphics_toolkit ("gnup
lot"); endif
+ autoload ("__player_audioplayer__", "audiodevinfo.oct");
+ autoload ("__player_get_channels__", "audiodevinfo.oct");

+ autoload ("__player_get_fs__", "audiodevinfo.oct");
+ autoload ("__player_get_id__", "audiodevinfo.oct");
+ autoload ("__player_get_nbits__", "audiodevinfo.oct");
+ autoload ("__player_get_sample_number__", "audiodevinfo.o
ct");
+ autoload ("__player_get_tag__", "audiodevinfo.oct");
+ autoload ("__player_get_total_samples__", "audiodevinfo.o
ct");
+ autoload ("__player_get_userdata__", "audiodevinfo.oct");

+ autoload ("__player_isplaying__", "audiodevinfo.oct");
+ autoload ("__player_pause__", "audiodevinfo.oct");
+ autoload ("__player_play__", "audiodevinfo.oct");
+ autoload ("__player_playblocking__", "audiodevinfo.oct");

+ autoload ("__player_resume__", "audiodevinfo.oct");
+ autoload ("__player_set_fs__", "audiodevinfo.oct");
+ autoload ("__player_set_tag__", "audiodevinfo.oct");
+ autoload ("__player_set_userdata__", "audiodevinfo.oct");

+ autoload ("__player_stop__", "audiodevinfo.oct");
+ autoload ("__recorder_audiorecorder__", "audiodevinfo.oct
");
+ autoload ("__recorder_get_channels__", "audiodevinfo.oct"
);
+ autoload ("__recorder_get_fs__", "audiodevinfo.oct");
+ autoload ("__recorder_get_id__", "audiodevinfo.oct");
+ autoload ("__recorder_get_nbits__", "audiodevinfo.oct");
+ autoload ("__recorder_get_sample_number__", "audiodevinfo
.oct");
+ autoload ("__recorder_get_tag__", "audiodevinfo.oct");
+ autoload ("__recorder_get_total_samples__", "audiodevinfo
.oct");
+ autoload ("__recorder_get_userdata__", "audiodevinfo.oct"
);
+ autoload ("__recorder_getaudiodata__", "audiodevinfo.oct"
);
+ autoload ("__recorder_isrecording__", "audiodevinfo.oct")
;
+ autoload ("__recorder_pause__", "audiodevinfo.oct");
+ autoload ("__recorder_record__", "audiodevinfo.oct");
+ autoload ("__recorder_recordblocking__", "audiodevinfo.oc
t");
+ autoload ("__recorder_resume__", "audiodevinfo.oct");
+ autoload ("__recorder_set_fs__", "audiodevinfo.oct");
+ autoload ("__recorder_set_tag__", "audiodevinfo.oct");
+ autoload ("__recorder_set_userdata__", "audiodevinfo.oct"
);
+ autoload ("__recorder_stop__", "audiodevinfo.oct");
+ autoload ("audioformats", "audioread.oct");
+ autoload ("audioinfo", "audioread.oct");
+ autoload ("audiowrite", "audioread.oct");
+ autoload ("bzip2", "gzip.oct");
+
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("fminbnd");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("fminsearch");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("fminunc");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("fsolve");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("fzero");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("lsqnonneg");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("pqpnonneg");
+ ## Discard result to avoid polluting workspace with ans a
t startup.
+ [~] = __all_opts__ ("qp");
+
+
+
+
+
>>


I observed this unwanted behavior under Windows (10) as well as under Linux. I
have seen it in the Octave GUI as well as in the CLI.

Many older Octave version show this very same behavior (I tested Octave 5.1.0
until the current 9.1.0). BUT my oldest Octave version, Octave 4.2.2, does NOT
show this unwanted behavior.

This behavior bothers me, because it makes using the external toolbox cvxr
very "noisy" on the console.

Is there an easy way so we can fix this in Octave? (Or at least a workaround?)







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65607>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

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