bugGNU Octave - Bugs: bug #36477, use XDG dirs instead of HOME

 
 

bug #36477: use XDG dirs instead of HOME

Submitted by:  Jon McCann <mccann>
Submitted on:  Wed 16 May 2012 03:20:01 AM UTC  
 
Category:  Configuration and Build System Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Confirmed Assigned to:  Mike Miller <mtmiller>
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 10 Jun 2019 11:37:46 AM UTC, comment #35:

(Sorry I had very little time the last months to follow this discussion, but I'll try to pick up again)

@Markus, comment #33:
AFAIK C:\Users\<username>\Documents\octave\  is meant for what the name implies, i.e., work documents, not so much for settings.
All files in %APPDATA% are user-editable, although the subdir is hidden.

On another note (somewhat related here):
Am I right to read in the docs that an .octaverc file can be read in any directory where Octave would start? Do we have a way to indicate Octave in which subdir to start? I tried an .octaverc file containing just "bbb = 6;" in C:\Users\Philip\MyDocs and told the GUI to start there, but after startup variable bbb is unknown. Octave seems to stubbornly only invoke the .octaverc in my %USERPROFILE% (= C:\Users\Philip\).

Philip Nienhuis <philipnienhuis>
Project Member
Sun 10 Mar 2019 06:54:46 PM UTC, comment #34:

Thank you very much! I have seen in some places that MAX_PATH + 1 is more correct.

wchar_t path[MAX_PATH + 1];

Anonymous
Sun 10 Mar 2019 04:49:23 PM UTC, comment #33:

Thanks, looks like that is working. I think we should also add the flag CSIDL_FLAG_DONT_VERIFY, and the 'free (local_app_data)' is still needed. I'll fix that up and push this soon.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Sun 10 Mar 2019 03:51:00 PM UTC, comment #32:

With the attached modifications to your patch, the default-octave target finished building successfully (without the need to change the Windows API level).
When starting up Octave on Windows 10 1809, I see the following in the Command Window:

debug: load new startup file: C:\Users\Markus\AppData\Roaming\octave\octaverc
>>

While that seems reasonable to me, I haven't followed the discussion well enough to decide whether this is the correct path.
Personally, I would expect the start up file to be at C:\Users\Markus\Documents\octave\octaverc (i.e. below CSIDL_PERSONAL).
My impression is that files in %APPDATA% or %LOCALAPPDATA% shouldn't be edited by users directly. These are locations that are "more internal" to programs and get only used behind the scenes.

(file #46491)

Markus Mützel <mmuetzel>
Project Member
Sun 10 Mar 2019 11:10:48 AM UTC, comment #31:

I raised the question of whether we want to drop support for Windows XP on the mailing list here:
http://octave.1599824.n4.nabble.com/Minimum-version-of-Windows-for-default-branch-td4691942.html

Markus Mützel <mmuetzel>
Project Member
Sun 10 Mar 2019 09:06:26 AM UTC, comment #30:

@Anonymous: Could you please report your findings at bug #54662. I was left under the impression that Octave CLI won't start on Windows XP due to an unknown reason.

In the mean time, I tried to link to the missing libraries by adding the following to configure.ac:

diff -r ad0b74e52f95 configure.ac
--- a/configure.ac        Sat Mar 09 22:09:25 2019 +0100
+++ b/configure.ac        Sun Mar 10 09:59:37 2019 +0100
@@ -1267,6 +1267,26 @@
   ;;
esac

+## Windows-specific module used for get_user_config_directory function
+case $host_os in
+  msdosmsvc | mingw*)
+    AC_CHECK_HEADERS([objbase.h],
+      [LIBS="-lole32 $LIBS"],
+      [AC_MSG_ERROR([Missing OLE32 required to build for Windows target.])],
+      [#include <windows.h>])
+  ;;
+esac
+
+## Windows-specific module used for get_user_config_directory function
+case $host_os in
+  msdosmsvc | mingw*)
+    AC_CHECK_HEADERS([knownfolders.h],
+      [LIBS="-luuid $LIBS"],
+      [AC_MSG_ERROR([Missing UUID required to build for Windows target.])],
+      [#include <windows.h>])
+  ;;
+esac
+
## Cygwin kluge for getrusage.
AC_CHECK_FUNCS([getrusage])
case $host_os in

However, the build still fails ultimately. I see the following message from the linker (and similar ones repeatedly) in the logs:

/bin/bash ./libtool  --tag=CXX   --mode=link x86_64-w64-mingw32-g++  -fopenmp -Wall -W -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -version-info 7:0:0 -no-undefined -bindir /home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/bin -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib  -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib  -Wl,-rpath-link,/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/qt5/lib -Wl,--export-all-symbols -o liboctave/liboctave.la -rpath /home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib/octave/6.0.0 liboctave/liboctave_la-liboctave-build-info.lo liboctave/liboctave_la-version.lo liboctave/array/libarray.la  liboctave/external/ranlib/libranlib.la liboctave/external/libexternal.la liboctave/numeric/libnumeric.la liboctave/operators/liboperators.la liboctave/system/libsystem.la liboctave/util/libutil.la liboctave/wrappers/libwrappers.la libgnu/libgnu.la -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -lsuitesparseconfig -larpack -lqrupdate -lfftw3 -lfftw3f -llapack -lblas -lxerbla -lreadline -ltermcap  -lpcre    -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/qt5/lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/lib/gcc/x86_64-w64-mingw32/7.4.0 -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/lib/gcc/x86_64-w64-mingw32/7.4.0/../../../../x86_64-w64-mingw32/lib/../lib -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/lib/gcc/x86_64-w64-mingw32/7.4.0/../../../../x86_64-w64-mingw32/lib -lm -lgfortran -lmingw32 -lmoldname -lmingwex -lmsvcrt -lquadmath -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -luuid -lole32 -lpsapi -lgdi32  -lm    -lws2_32 -lws2_32   -ladvapi32  -lws2_32 -lws2_32 -L/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib -liconv -R/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib   -luuid -lole32 -lpsapi -lgdi32  -lm
mv -f libinterp/.deps/liboctinterp_la-build-env-features.Tpo libinterp/.deps/liboctinterp_la-build-env-features.Plo

*** Warning: linker path does not have real file for library -luuid.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libuuid and none of the candidates passed a file format test
*** using a file magic. Last file checked: /home/osboxes/Documents/Repositories/Octave/mxe-octave-3/usr/x86_64-w64-mingw32/lib/libuuid.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

I checked that the file is there at the indicated directory. But don't know how to proceed further.

Markus Mützel <mmuetzel>
Project Member
Sun 10 Mar 2019 04:00:24 AM UTC, comment #29:

Thankfully core Octave engine libraries "liboctave-7.dll" and "liboctinterp-7.dll" of octave-5.1.0-w32 are currently working in Windows XP. As a good news I also can execute octave-cli in Windows XP replacing opengl32.dll with the same file from Octave 4.4. So dropping user support is as simple as building mxe-octave with -D_WIN32_WINNT=0x0601 :)

Anonymous
Sat 09 Mar 2019 09:25:53 PM UTC, comment #28:

We don't link with ole32 yet.

Markus Mützel <mmuetzel>
Project Member
Sat 09 Mar 2019 09:20:59 PM UTC, comment #27:

I didn't know either. But found it thanks to your previous comment.

That change got me a little bit further. Compilation succeeded but linking failed with:

liboctave/system/.libs/libsystem.a(libsystem_la-oct-env.o): In function `octave::sys::env::do_get_user_config_directory[abi:cxx11]() const':
/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/tmp-default-octave/octave-6.0.0/liboctave/system/oct-env.cc:250: undefined reference to `__imp_CoTaskMemFree'
liboctave/system/.libs/libsystem.a(libsystem_la-oct-env.o):oct-env.cc:(.rdata$.refptr.FOLDERID_LocalAppData[.refptr.FOLDERID_LocalAppData]+0x0): undefined reference to `FOLDERID_LocalAppData'

Markus Mützel <mmuetzel>
Project Member
Sat 09 Mar 2019 08:50:33 PM UTC, comment #26:

Oh, thank you, I didn't realize that was already in configure.ac!

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Sat 09 Mar 2019 08:49:12 PM UTC, comment #25:

I am currently trying to build with the following change to configure.ac:

diff -r 7506884fc158 configure.ac
--- a/configure.ac        Sat Mar 09 20:30:24 2019 +0100
+++ b/configure.ac        Sat Mar 09 21:48:46 2019 +0100
@@ -1234,14 +1234,14 @@
     AC_MSG_CHECKING([for required _WIN32_WINNT])
     AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
         #include <windows.h>
-        #if _WIN32_WINNT < 0x0403
+        #if _WIN32_WINNT < 0x0600
         #error "Wrong version"
         #endif
         ]], [])],
       [AC_MSG_RESULT([none])],
-      [AC_DEFINE(_WIN32_WINNT, 0x0403,
-        [Define to 0x0403 to access InitializeCriticalSectionAndSpinCount.])
-       AC_MSG_RESULT([0x0403])])
+      [AC_DEFINE(_WIN32_WINNT, 0x0600,
+        [Define to 0x0600 to access SHGetKnownFolderPath.])
+       AC_MSG_RESULT([0x0600])])
   ;;
esac

Markus Mützel <mmuetzel>
Project Member
Sat 09 Mar 2019 08:32:54 PM UTC, comment #24:

Sure. Is _WIN32_WINNT something that should be set in mxe-octave so it applies globally to the builds of all dependencies? Or should Octave define it in configure.ac if it isn't already set by the user?

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Sat 09 Mar 2019 08:15:51 PM UTC, comment #23:

We had reports that Octave won't start on Windows XP anyway. I am not aware of any reports that it won't start on Windows Vista or Server 2008.
Would it be OK to set _WIN32_WINNT to 0x0600 (that is _WIN32_WINNT_VISTA)?

The respective part of the header is:

#if NTDDI_VERSION >= 0x06000000
  typedef enum {
    KF_FLAG_DEFAULT = 0x00000000,
#if NTDDI_VERSION >= 0x06010000
    KF_FLAG_NO_APPCONTAINER_REDIRECTION = 0x00010000,
#endif
    KF_FLAG_CREATE = 0x00008000,
    KF_FLAG_DONT_VERIFY = 0x00004000,
    KF_FLAG_DONT_UNEXPAND = 0x00002000,
    KF_FLAG_NO_ALIAS = 0x00001000,
    KF_FLAG_INIT = 0x00000800,
    KF_FLAG_DEFAULT_PATH = 0x00000400,
    KF_FLAG_NOT_PARENT_RELATIVE = 0x00000200,
    KF_FLAG_SIMPLE_IDLIST = 0x00000100,
    KF_FLAG_ALIAS_ONLY = 0x80000000
  } KNOWN_FOLDER_FLAG;

  DEFINE_ENUM_FLAG_OPERATORS (KNOWN_FOLDER_FLAG);

  STDAPI SHGetKnownFolderIDList (REFKNOWNFOLDERID rfid, DWORD dwFlags, HANDLE hToken, PIDLIST_ABSOLUTE *ppidl);
  STDAPI SHSetKnownFolderPath (REFKNOWNFOLDERID rfid, DWORD dwFlags, HANDLE hToken, PCWSTR pszPath);
  STDAPI SHGetKnownFolderPath (REFKNOWNFOLDERID rfid, DWORD dwFlags, HANDLE hToken, PWSTR *ppszPath);
#endif

Markus Mützel <mmuetzel>
Project Member
Sat 09 Mar 2019 07:14:17 PM UTC, comment #22:

Thanks. Can we build mxe-octave with -D_WIN32_WINNT=0x0601 from now on?

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Sat 09 Mar 2019 06:52:29 PM UTC, comment #21:

I applied the xdg.patch on top of hg id ea4a36fd48b6 and tried to cross compile.
Compilation failed with the following error:

/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/tmp-default-octave/octave-6.0.0/liboctave/system/oct-env.cc: In member function 'std::__cxx11::string octave::sys::env::do_get_user_config_directory() const':
/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/tmp-default-octave/octave-6.0.0/liboctave/system/oct-env.cc:244:56: error: 'KF_FLAG_DONT_VERIFY' was not declared in this scope
       if (SHGetKnownFolderPath (FOLDERID_LocalAppData, KF_FLAG_DONT_VERIFY,
                                                        ^~~~~~~~~~~~~~~~~~~
/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/tmp-default-octave/octave-6.0.0/liboctave/system/oct-env.cc:244:56: note: suggested alternative: 'CSIDL_FLAG_DONT_VERIFY'
       if (SHGetKnownFolderPath (FOLDERID_LocalAppData, KF_FLAG_DONT_VERIFY,
                                                        ^~~~~~~~~~~~~~~~~~~
                                                        CSIDL_FLAG_DONT_VERIFY
/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/tmp-default-octave/octave-6.0.0/liboctave/system/oct-env.cc:244:11: error: 'SHGetKnownFolderPath' was not declared in this scope
       if (SHGetKnownFolderPath (FOLDERID_LocalAppData, KF_FLAG_DONT_VERIFY,
           ^~~~~~~~~~~~~~~~~~~~
/home/osboxes/Documents/Repositories/Octave/mxe-octave-3/tmp-default-octave/octave-6.0.0/liboctave/system/oct-env.cc:244:11: note: suggested alternative: 'SHGetFolderPath'
       if (SHGetKnownFolderPath (FOLDERID_LocalAppData, KF_FLAG_DONT_VERIFY,
           ^~~~~~~~~~~~~~~~~~~~
           SHGetFolderPath
make[5]: *** [Makefile:24299: liboctave/system/libsystem_la-oct-env.lo] Error 1

To be honest I don't know which Windows version our mingw compiler builds for. But maybe using SHGetFolderPathW would work indeed.

Markus Mützel <mmuetzel>
Project Member
Sat 09 Mar 2019 06:50:26 PM UTC, comment #20:

👍

New bug for caching downloaded packages: bug #55873.

Andrew Janke <apjanke>
Sat 09 Mar 2019 06:42:02 PM UTC, comment #19:

@apjanke Sure, there may already be an open bug about changing the default user installation prefix for packages.

Personally I use ~/.local/share/octave/${V}/packages and ~/.local/lib/octave/${V}/packages as the installation prefix on my system (where V is derived from OCTAVE_VERSION).

Caching downloaded packages would be an entirely new feature, sounds good to me, feel free to report that as a separate wishlist bug.

Message recieved from you and Carlo about ~/Library on macOS, will not use that at all.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Sat 09 Mar 2019 05:14:46 PM UTC, comment #18:

Regarding comment #10 the following also can be used for compatibility with older Windows systems.


WCHAR path[MAX_PATH];
SHGetFolderPathW(nullptr, CSIDL_LOCAL_APPDATA, nullptr, 0, path);

Anonymous
Sat 09 Mar 2019 08:27:31 AM UTC, comment #17:

On an XDG-specific note: if you're switching to $XDG_CONFIG_DIRS, would it also be appropriate to switch to storing pkg-installed packages under $XDG_DATA_HOME/octave instead of ~/octave? And maybe cache pkg downloads under $XDG_CACHE_HOME?

Andrew Janke <apjanke>
Sat 09 Mar 2019 08:25:51 AM UTC, comment #16:

Err, "bug-notification emails".

Andrew Janke <apjanke>
Sat 09 Mar 2019 08:21:33 AM UTC, comment #15:

Aha. Just catching up on my big-notifications email this evening. Heading over there next.

Andrew Janke <apjanke>
Sat 09 Mar 2019 08:00:31 AM UTC, comment #14:

Andrew, there's a bit of discussion about Windows over in bug #40444, see there.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 09 Mar 2019 07:45:00 AM UTC, comment #13:

> . This patch loads a new startup file, following the conventions of XDG_CONFIG_HOME on GNU/Linux and Unixy systems, and uses %LOCALAPPDATA% on Windows systems.


Maybe this should be %APPDATA% instead of %LOCALAPPDATA%?

%APPDATA% is the AppData dir in the user's roaming profile. %LOCALAPPDATA% is the AppData dir in the machine-local portion of the user's profile. I thought application configuration files are generally stored in %APPDATA% so they are automatically synced across multiple machines. (Useful in places where users don't have their own dedicated computer, like university computer labs.)

Andrew Janke <apjanke>
Sat 09 Mar 2019 07:33:07 AM UTC, comment #12:

> On macOS, I think there is a separate standard hierarchy, and I can include that as well here. I've seen some references to a standard location of ${HOME}/Library/Preferences. So that would make the startup file ${HOME}/Library/Preferences/octave/octaverc.
>
> @apjanke Does that look right to you?


Yes, ~/Library is the default location for the hierarchy of config files and persistent program state on macOS. Application state (like the Qt window location and widget arrangement) would go in `~/Library/Application Support`.

However, I'd recommend sticking with the Unix-y `~/.config/octave` or `~/.octaverc` for Octave on macOS.

The ~/Library hierarchy is mostly used by native Mac apps that are built using Apple frameworks, and they use plists and other Mac-y mechanisms. Most software I've seen come over from Linux keeps the `~/.config/myapp` or `~/.myapp*` pattern, and it doesn't cause any problems.

I don't think that Octave has a Mac developer that could provide expertise in using the `~/Library` hierarchy. I'm certainly not advanced enough: I don't really know what to do there, or what formats are appropriate for use in it. (I don't even know if using rc files instead of .plist files in ~/Library/Preferences is technically supported.) And the documentation I've seen on this file hierarchy seems to really leverage Apple frameworks for interaction with it, instead of defining the dir tree and file formats at a low level.

(At this point I have to confess to using ~/Library/Application Support myself in Octave.app - but that seemed to be the Rightest place for it in what is trying to be more of a native Mac app. $XDG_DATA_HOME would have been just as right, I think...)

And the source code would be simpler and easier to maintain just using the `~/.config/octave` mechanism on both Unix platforms. Since macOS seems to be the distant third-place platform for Octave power users and developers, I don't think a split bodes well for the fate of platform-specific codebase, even if it's not big.

Plus, ~/.octaverc is a convenience for multi-platform users: that way they can sync their Octave preferences across machines by just syncing ~/.config or ~/.octaverc across machines. Switching to ~/Library would require a more complicated configuration linking different local filesystem locations to a shared backing file depending on the platform.

And all the "howto" articles or bug reports online that explain how to edit or fix your Octave config or app state on Linux would still be applicable to Mac users, too.

There are no advantages I'm aware of to using ~/Library unless you're also using Apple's macOS app development frameworks as well.

So, I'd vote for not using ~/Library, and continuing to just treat Macs as a Unix-y system here.

Andrew Janke <apjanke>
Thu 07 Mar 2019 08:21:31 AM UTC, comment #11:

Re comment #9 :

As for macos, I don't think

  ${HOME}/Library/Preferences/octave/octaverc

would be easy to find for macos users,
the ${HOME}/Library folder is invisible and can
only be reached from the terminal or via
hidden Finder tricks that are not known to
most users.

So I don't think that is a good location
for a file that the user is expected to be
able to edit directly.

Carlo de Falco <cdf>
Project Member
Wed 06 Mar 2019 10:56:28 PM UTC, comment #10:

Attached is a first draft at resolving this bug. This patch loads a new startup file, following the conventions of XDG_CONFIG_HOME on GNU/Linux and Unixy systems, and uses %LOCALAPPDATA% on Windows systems.

  • Can someone who builds for Windows regularly test this patch for me? I have no idea if what I threw together is right. If it works, you should see a message "debug: load new startup file: ...", and the path to that file should look sane. If you then create that file, and put a "disp" or something in it, it should work as expected.
  • @jwe I would appreciate any thoughts about how I am creating new library functions here. My idea is to have one new function in liboctave called "get_user_config_directory" that returns the platform-dependent base directory for config files, and another function, maybe "get_octave_config_directory" that returns the "/octave" subdir of the former, but I'm not sure where I want to place that one. There will also probably be future additions for returning a vector of configuration directories (both XDG and Windows define multiple configuration locations that could be read in sequence).

(file #46450)

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Wed 06 Mar 2019 07:24:05 PM UTC, comment #9:

On macOS, I think there is a separate standard hierarchy, and I can include that as well here. I've seen some references to a standard location of ${HOME}/Library/Preferences. So that would make the startup file ${HOME}/Library/Preferences/octave/octaverc.

@apjanke Does that look right to you?

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Wed 06 Mar 2019 07:22:38 PM UTC, comment #8:

I plan to start working on this for Octave 6.

My plan is to introduce a new user startup file that will be in the appropriate directory for application preferences for each system type. On GNU/Linux and Unixy systems, that will be ${XDG_CONFIG_HOME}/octave/octaverc, or ${HOME}/.config/octave/octaverc if XDG_CONFIG_HOME is not set.

On Windows, this will be %LOCALAPPDATA%\octave\octaverc.

The original startup file ${HOME}/.octaverc will still be loaded after loading this new standard startup file, and of course ${PWD}/.octaverc will still be supported as well. At this point, ${HOME}/.octaverc becomes a kind of special case of ${PWD}/.octaverc.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Fri 01 Nov 2013 05:01:39 PM UTC, comment #7:

See also bug #40444 that relates to an analogous request for Windows systems.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 13 Dec 2012 04:17:22 PM UTC, comment #6:

>Do you want the one to make a plan? Can you provide a patch?

Can you point me where .octaverc and .octave_hist are written?

Eric Heintzmann <eheintzmann>
Mon 10 Dec 2012 04:28:31 PM UTC, comment #5:

> What is planned now about FreeDesktop XDG basedir specification for GNU Octave?


Nothing is planned, but it looks like a good idea. Do you want the one to make a plan? Can you provide a patch?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Sun 09 Dec 2012 08:34:00 AM UTC, comment #4:

>At least in Debian Wheezy, looking at all my environment
>variables, the only XDG variable I see is XDG_DATA_DIRS which is
>the less useful for us


There's no need to read the environment variable yourself : most language provide a library to use XDG folder:
with glib/GTK just replace g_get_home_dir() by
g_get_user_config_dir()

Eric Heintzmann <eheintzmann>
Sat 08 Dec 2012 09:45:17 PM UTC, comment #3:

>but is anyone really following this specification?

GNOME,KDE, GTK and many upstream apps support this spec.

Eric Heintzmann <eheintzmann>
Sat 08 Dec 2012 06:26:26 PM UTC, comment #2:

I'm very much in favour of this but is anyone really following this specification? At least in Debian Wheezy, looking at all my environment variables, the only XDG variable I see is XDG_DATA_DIRS which is the less useful for us. From their specification there's default values that should be used when their value is not used.

I meant to have proposed a ~/.octave directory rather than having a .octave_packages, .octaverc and .octave_hist files. But what tI was looking at the GNU Coding standards and didn't saw reference a reference to anything.

Carnë Draug <carandraug>
Project Member
Sat 08 Dec 2012 12:35:08 PM UTC, comment #1:
Eric Heintzmann <eheintzmann>
Wed 16 May 2012 03:20:01 AM UTC, original submission:

It seems like at least ~/.octaverc and ~/.octave_hist are stored in the home directory. It would be better to use the locations defined in the XDG Base Directory Specification.

https://live.gnome.org/GnomeGoals/XDGConfigFolders
http://standards.freedesktop.org/basedir-spec/latest/

Jon McCann <mccann>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #46491:  bug36477_xdg_v2.patch added by mmuetzel (4KiB - application/octet-stream)
file #46450:  xdg.patch added by mtmiller (4KiB - text/x-patch)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by apjanke (Posted a comment)
  • -email is unavailable- added by cdf (Posted a comment)
  • -email is unavailable- added by mtmiller
  • -email is unavailable- added by mtmiller
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by eheintzmann (Posted a comment)
  • -email is unavailable- added by mccann (Submitted the item)
  • -email is unavailable- added by mccann
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-06-09 mtmiller Assigned toNone => mtmiller
    2019-03-10 mmuetzel Attached File- => Added bug36477_xdg_v2.patch, #46491
    2019-03-06 mtmiller Attached File- => Added xdg.patch, #46450
        Carbon-Copy- => Added jwe
    2019-03-06 mtmiller Carbon-CopyRemoved 80942 => -
    2019-03-06 mtmiller Carbon-Copy- => Added apjanke
    2017-08-08 mtmiller Dependencies- => bugs #51684 is dependent
    2015-07-30 carandraug Dependencies- => bugs #45652 is dependent
    2015-02-22 mtmiller Dependencies- => bugs #40444 is dependent
    2013-10-22 mtmiller CategoryNone => Configuration and Build System
        Severity3 - Normal => 1 - Wish
        Item GroupNone => Feature Request
        StatusNone => Confirmed
    2012-05-16 mccann Carbon-Copy- => Added mccann

    Back to the top


    Powered by Savane 3.4