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

[Dirk Eddelbuettel]

On Sat, Feb 22, 2003 at 01:23:56PM -0600, John W. Eaton wrote:
> [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.

Earlier today in a reply off the bug system, I realised that the 'site' file
/usr/share/octave/site/m/startup/octaverc is the same file (and hence with 
a potential conflict) between two packages: octave2.0 and octave2.1.  That
doesn't work.  I think that led to my error of appending the version string,
which avoids the conflict, but creates, as the bugreport correctly
identifies, a no-op as the file is never read by octave, due to the changed
name. 

I have changed this to have Debian's /etc/octave2.1.conf as a soft link to
/usr/share/octave/$(VERSION)/m/startup/octaverc, and 2.1.45-2, or 2.1.46-1,
will have it.  As there is no harm or malfunction, I won't make a fresh
package just because of this.

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

That sounds like a nice generalisation.

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

Definitely nice-to-have things, but I'd put them at a lower priority than
the (impressive) targets you set out as ideas for octave 3.0.

Dirk

-- 
Prediction is very difficult, especially about the future. 
                                             -- Niels Bohr