Re: Bug#182000: octave2.1: /usr/share/octave/site/m/startup/octaverc-2.1.45 is useless

[John W. Eaton]

[I'm adding octave-maintainers to the recipieent list.  --jwe]

On 22-Feb-2003, Dirk Eddelbuettel <address@hidden> wrote:

| Or I could like against 
|    /usr/share/octave/<version>/m/startup/octaverc
| 
| Do you have any strong preferences?  Arguably, distro-specific mods like the
| one I'm doing here could be construed to be 'site' specific. On the other we
| ship it for every Debian installation.

The order that Octave reads the startup files is:

  /usr/share/octave/site/m/startup/octaverc
  /usr/share/octave/2.1.45/m/startup/octaverc
  ~/.octaverc
  .octaverc

I think the Debian package commands should go in the site file, but
that means you can't override anything that might be set in the other
system-wide startup file.

Both of the system-wide startup files are empty in the current Octave
distribution, but we may eventually put some significant startup code
in the .../<version>/m/startup/octaverc file.  Whatever we put in there, it
should not affect paths or other things like that.  The commands I'm
thinking of adding are just things that we could do in an interpreted
script instead of being in the Octave binary.  So you probably
shouldn't need to override that in another rc file that comes after
those commands.  But if you think that would be useful, we could make
some changes (and also make them easier to change in the future).  For
example, in the current setup, the reading of the rc files is fixed in
the C++ code, in a function in src/octave.cc.  Instead, we could make
things more flexible by changing that so the
.../<version>/m/startup/octaverc file contains something like:

  pre_rc_file = strcat (localfcnfiledir. "/startup/pre-octaverc");
  if (exist (pre_rc_file, "file"))
    source (pre_rc_file);
  endif

  ### Other rc file commands here...

  post_rc_file = strcat (localfcnfiledir. "/startup/post-octaverc");
  if (exist (post_rc_file, "file"))
    source (post_rc_file);
  endif

  if (read_init_files)  ## Need a way to pass this into the octaverc file...
    ## handle sourcing the user init files...
  endif

(It might also be useful to have a way of introducing a new scope, so
we wouldn't have to worry about clearing temporary variables, or
clashing with other variables that already exist.)

Finally, what if we had a way to install built-in variables in the
scripting language?  Then we could move things like the initialization
of things like octave_config_info out of the C++ code and into the
startup files.

What do you think?  Would changes like this be useful?  Are they worth
making?

jwe