[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#182000: octave2.1: /usr/share/octave/site/m/startup/octaverc-2.1
From: |
Dirk Eddelbuettel |
Subject: |
Re: Bug#182000: octave2.1: /usr/share/octave/site/m/startup/octaverc-2.1.45 is useless |
Date: |
Sat, 22 Feb 2003 13:38:22 -0600 |
User-agent: |
Mutt/1.3.28i |
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