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

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

[Octave-bug-tracker] [bug #40444] On Windows, config & history files etc


From: Andrew Janke
Subject: [Octave-bug-tracker] [bug #40444] On Windows, config & history files etc. should go to %APPDATA%
Date: Sat, 9 Mar 2019 03:20:28 -0500 (EST)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36

Follow-up Comment #17, bug #40444 (project octave):

One more vote for config going in %APPDATA% here. Speaking as someone who's
worked in university computer labs and large businesses, your users really
want that app config to be roaming.

>From what I've seen, Windows apps generally store config data in %APPDATA%,
and app cached data in %LOCALAPPDATA%.

Mike wrote:

> If a user saves their startup path to octaverc (e.g. with 'savepath'), that
might include local directories and drives that are only present on one
system. That should only happen in a local configuration file, not a roaming
file. 

In an institution/IT environment that has roaming profiles, the onus is on a
combination of the users and IT staff to not do this. The user profile is
configured to set up drive mappings so there is a consistent drive letter
environment for the user across machines. Users are trained to stick with
those commonly-available drives, and when something breaks due to them using a
local drive, a quick conversation with IT will clear it up (usually ending in
"don't do that").

> If Octave supports reading octaverc from %APPDATA% only, how would you add a
startup configuration that only applies to one machine? 

Add this to your roaming octaverc:


my_local_octaverc = [ getenv('LOCALAPPDATA') '\Octave\octaverc_local' ];
if exist ( my_local_octaverc )
  run (my_local_octaverc)
endif


Same trick that bash users do to have machine-specific bashrcs when they have
a synced ~/.bashrc.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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