(In my opinion, changing the C++ code mentioned in comment #3, using the information given in comment #5, along the reasoning of comment #2, would be most appropriate here. But since I am not experienced in doing changes to the C++ parts of Octave, I'll need to wait if someone else likes to improve Octave's C++ code in this respect.)

@Rik: It's the cvx library itself that calls path() as well as echo().

I tried to find a workaround (on cvx's m-code, but the same question is also relevant if we want to change Octave's load-path.cc code), but did not come very far because of the following question:

How can one detect the "echo state" of Octave at all? I could not find any Octave-command to detect if this code runs currently on the "echo on" mode or in the "echo off" mode. Does anyone know how to detect this?

I personally use "echo" not very often, at all. But currently I am using an external m-code library called cvx (https://cvxr.com/cvx/). This library is designed for Matlab, but runs sufficently well in Octave. And this cvx library uses "echo" extensivly to turn on or off the console output of other included (m-code and mex code) numerical solver libraries (SDPT3, SeDuMi).

So probably this Octave behavior of "echo" is mostly a "Matlab compatiblity" issue, when people (as currently me) run code that was originally designed for Matlab, and now the code behaves  differently when used with Octave.

If this excessive text output really only happens when "echo on" is used together with "path", would then the following approach be a feasible code change in Octave, in order to improve its Matlab compatiblity?

• at the point in the code of "path", shortly before/after the PKG_ADD scripts are called:
• save the current state of "echo"
• echo off
• PKG_ADD stuff
• restore the previously saved state of "echo"

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?)