bugGNU Octave - Bugs: bug #57463, History should be stored at...

 
 

bug #57463: History should be stored at platform specific location

Submitter:  Markus Mützel <mmuetzel>
Submitted:  Sun 22 Dec 2019 04:20:04 PM UTC
   
 
Category:  Interpreter Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  In Progress Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 06 Nov 2020 04:54:17 PM UTC, comment #14: 

I generally agree with the idea that implementation and maintenance effort should be a consideration, it seems simple enough to add something like


if (isempty (history ()))
  warning ("attempting to recover history from ~/.octave_hist file used by previous versions of Octave");
  history ("-r", "~/.octave_hist");
endif


to the version-specific startup file.

John W. Eaton <jwe>
Group administrator
Fri 06 Nov 2020 09:38:40 AM UTC, comment #13: 

@ratijas
Think of maintainability and priorities?
In principle / theory I agree with you; of course. I'm also not opposed to a solution. But from a practical POV: Octave doesn't have as many developers as --say-- Firefox; plus, this is a volunteer project.

The change is clearly described in the NEWS. The required actions require mere basic computer proficiency - one lousy move or copy command, or see [*]. Seems out of proportion to me to create code to do that for users; the more since such code may turn out to be fragile on some platforms and/or some environments - that's the complexity I had in mind.

[*] Please read up on the 'history_file' command.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 05 Nov 2020 06:59:32 PM UTC, comment #12: 


> Octave's source code is complicated enough as it stands.


I wonder, how that is even an argument? And even if so, why it should affect end users?

Imagine web browser, say Firefox, lose your history someday. You know, browsers are fairly complex piece of software, millions lines of code, larger than Linux kernel -- so why bother with your profile?

What I mean to say is, such argument is below [my personal] level of acceptance. There might be better arguments, like "octave users on average don't rely on history snippets", but not this one.

ivan tkachenko <ratijas>
Thu 05 Nov 2020 06:35:51 PM UTC, comment #11: 

I agree with Kai's POV; Octave's source code is complicated enough as it stands.

In the NEWS we might add a little stanza about how to move (or copy, or symlink) the history file to the new location.
For Windows builds maybe something can be done in the NSIS installer along the lines of "Copy history and/or settings from previous Octave installation?" OTOH mxe-octave and the installer part is also already very complicated.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 05 Nov 2020 02:43:49 PM UTC, comment #10: 

+1 for this patch. As someone who likes to keep home directory clean, I am not happy with all those .*rc and .*hist trash cluttering it up.

I am excited to see changes are coming live soon!

Although, I don't agree on a migration strategy.  Seamless integration with previous versions is equally important. I personally don't use octave much lately, but my zsh history is bounded to 10'000 entries for a reason -- and if someone suddenly would decide to change the path without moving it, because he/she though it won't affect my UX -- let's just say, I won't be too happy about that either.

ivan tkachenko <ratijas>
Thu 08 Oct 2020 02:13:47 AM UTC, comment #9: 

@Rik comment #8: I think Markus' entry in the NEWS file is sufficient.  Adding more code looking for legacy location just complicates things and the user experience is not that much affected.

In your case it came as a surprise, as you might do not read the NEWS file after every pulled change on a development branch.  But this change comes with a major software upgrade and then it should be studied carefully 😇  And as you said nothing is deleted.

Kai Torben Ohlhus <siko1056>
Group Member
Sat 03 Oct 2020 02:19:37 PM UTC, comment #8: 

Shouldn't there be logic to migrate a user's existing history file?  I just updated to cset 28854 and my previous Octave sessions are not available.  On the good side, they haven't been removed, they are just at the old location of ~/.octave_hist.

Rik <rik5>
Group administrator
Sat 03 Oct 2020 11:05:01 AM UTC, comment #7: 

I pushed the patch here:
https://hg.savannah.gnu.org/hgweb/octave/rev/491433ba8612

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Fri 15 May 2020 07:09:37 PM UTC, comment #6: 

@Mike: Thanks for the review and feedback.
I hope to have addressed the issues you mentioned in the attached patch.

(file #49079)

Markus Mützel <mmuetzel>
Group administrator
Thu 14 May 2020 09:21:24 PM UTC, comment #5: 

Note to self, or Markus or others testing this, it's very important to make sure that 'octave --no-history' does not try to create the ~/.local/share/octave (or %APPDATA%/octave) directory when it doesn't exist. The most ideal behavior may be to create the directory only when the history file needs to be written.

Notes to Markus: please fix the references in the commit message to refer to 'get_user_data_directory' instead of 'config'. It would also be better to name the local variable 'data_dir' instead of 'hist_dir' in oct-env, since it isn't about history at this layer.

Mike Miller <mtmiller>
Group Member
Thu 14 May 2020 09:02:44 PM UTC, comment #4: 

Looks good on reading, not yet tested.

Please take note that we try to avoid using shortcuts or globs for file names in commit messages, so use "oct-env.cc, oct-env.h (env::get_user_data_directory) ..." instead of "oct-env.[cc,h]" or "oct-env.{cc,h}". I'll add that to the wiki if it's not already mentioned.

Mike Miller <mtmiller>
Group Member
Thu 14 May 2020 08:00:15 PM UTC, comment #3: 

The attached changeset moves the default location of the history to %APPDATA%/octave/history on Windows or ${XDG_DATA_HOME}/octave/history on Unix-like OSs. If XDG_DATA_HOME is not set, it uses ~/.local/share as a fallback. I hope I got this right.

This seems to work for me on Ubuntu 20.04 and Windows 10 1909.

(file #49067)

Markus Mützel <mmuetzel>
Group administrator
Mon 23 Dec 2019 06:45:00 PM UTC, comment #2: 

I'd opt for interpreting history as "data", too. Motive: there can be days or sometimes even weeks in between Octave sessions and I don't script all my activities not do I keep diaries of everything.

As many Windows users work on school or company networks with persistent roaming profiles I think something like %APPDATA%/Roaming/octave/ would be the best location.
Usually with such roaming profiles the local temp dirs are wiped after logout so there's little use in keeping history files there.

BTW I'd figure that roaming profiles should be possible on *nix as well. As on Windows it's just a question of linking to some persistent network location where /home lives at login time.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 23 Dec 2019 06:20:59 PM UTC, comment #1: 

Fortunately, this can already be configured by the user, see `help history_file`.

If we want to change the defaults to conform with OS expectations, a couple of questions for consideration.

  • Would the history file be considered more like a "cache" file, or more like a "data" file?


  • Would Windows users want to have Octave history saved in the per-machine profile directory or in the roaming profile directory? Would it be more useful to have a shared history between multiple machines by default or to have a unique history per machine?


My preference would be for "data", and I think shared history in the roaming profile probably makes sense. So on GNU, macOS, and other Unix-likes, the history file would be something like ${XDG_DATA_HOME}/octave/history, or ~/.local/share/octave/history if XDG_DATA_HOME is not defined. On Windows, the history file would be something like %APPDATA%\octave\history.

My ~/.octaverc already redefines the history_file to be ~/.local/share/octave/history, I've been using that for a while.

Mike Miller <mtmiller>
Group Member
Sun 22 Dec 2019 04:20:04 PM UTC, original submission:  

The .octave_hist file is currently stored in the home directory.
It would be nice if a location preferred by the OS would be used. This could be the XDG directories on POSIX systems or LOCALAPPDATA/APPDATA on Windows.

See also bug #36477 for the configuration files and bug #40444.

Markus Mützel <mmuetzel>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49079:  bug57463_xdg_history_v2.patch added by mmuetzel (6KiB - application/octet-stream)
file #49067:  bug57463_xdg_history.patch added by mmuetzel (6KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ratijas (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-06 jwe StatusFixed In Progress
        Open/ClosedClosed Open
    2020-10-08 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-10-03 mmuetzel StatusPatch Submitted Ready For Test
    2020-05-15 mmuetzel Attached File- Added bug57463_xdg_history_v2.patch, #49079
    2020-05-14 mmuetzel Attached File- Added bug57463_xdg_history.patch, #49067
        StatusConfirmed Patch Submitted
    2019-12-23 mtmiller Severity2 - Minor 1 - Wish
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code