Another thing I've just noticed is that when setting the path to a non-existent folder the custom error I've created doesn't cause startup to fail. Maybe it's just a logged error?

As a user, I'm more in support of #10100. I feel that config and data files should be at fixed locations, not customized. Otherwise the data directory becomes too non-standard and a bit of a mess.

If the user really wants to customize the path, they can create some symlink. I have done so myself for e.g. the Nushell config dir for version control.

One of the reasons that I felt this was a reasonable idea is that it doesn't conflict with the defaults. The path config line can just not exist and users can rely on ENV and defaults to handle the path.

I can give an example of why a symlink isn't ideal in my case. I keep all my system config in a single directory and all my data for backup in another directory. Whilst symlinking certainly isn't a deal breaker for me, using real files does just make it easier and more obvious what my config is doing when I can put things exactly where I want them without any indirection.

(Copy pasting from #10110)

@tombh I like your idea of having a way to set an alternative history path.

My motivation for this feature is that within a particular dev project, you typically need to run a fixed set of commands frequently, and often times those commands are similar to those you run in normal shell session, so that when you reverse search in the history, those similar commands from your normal session just clutter the history list, making the ones you really want harder to locate.

The history.isolation setting doesn't really solve this use case because you want those histories to persist after restart, but then it would become a different shell session and all is lost. Being able to set an alternative history path seems to be the natural approach for this scenario.

For me, Since I use direnv to spawn a development shell (with custom config & env file checked into git repo) when I enter the directory of a particular project, I can cope with any way of making such customization (env var, CLI flag or config entry ). Though from the POV of being in line with nushell's current way of doing things, I feel like a --history-file CLI flag is more consistent (analogous to the current --env-config, --config and --plugin-config) and less intrusive (does not require updating config schema).

That's also a good use case, I hadn't thought of that. I'd be happy to add it.

I'm not quite clear on the downsides of adding it to the config. Does it affect backward compatibility?

My only comment is that I think it would make it a bit harder to set the default shell in Linux with chsh, I believe that only accepts an absolute path without arguments. So I would have to create a wrapper script that actually called nu --history-file /important/path.text.

That's also a good use case, I hadn't thought of that. I'd be happy to add it.

I'm not quite clear on the downsides of adding it to the config. Does it affect backward compatibility?

My only comment is that I think it would make it a bit harder to set the default shell in Linux with chsh, I believe that only accepts an absolute path without arguments. So I would have to create a wrapper script that actually called nu --history-file /important/path.text.

Sorry for the confusion, I don't object adding to config in any way.

My comment is based on how nushell currently specifies the three files it depends on: config.nu, env.nu and plugin.msgpackz. For obvious reasons, it does not make sense to specify the path of env.nu and config.nu inside config.nu. But for plugin.msgpackz, i think it makes sense to be specified in all three of the typical approaches, namely CLI flag, environment variable and within config file. A custom history file is similar to a custom plugin file: it can be reasonably specified via all three approaches.

On the other hand, nushell currently only supports the CLI flag approach for specifying plugin file. And if you are in need of a custom plugin file in conjunction with chsh, you face the same issue.

But that's just how nushell is today, and it certainly can/should be improved. Though the core devs might have other concerns that are beyond my sight.

A custom history file is similar to a custom plugin file: it can be reasonably specified via all three approaches.

Ohh yes, that makes sense. And I agree. And I'd be happy to add a CLI flag in this PR. I'll just wait for some feedback from the core team before I make any more changes.

nushell currently only supports the CLI flag approach for specifying plugin file

That's a shame. I guess that should be addressed in another issue and PR.

BTW I read your comment in the other thread:

I fear that modifying XDG_DATA_HOME would make other programs that depend on XDG_DATA_HOME, when run in this nushell session, behave incorrectly.

That's a really good point. I think that's the best example of why being able to explicitly set the history path is important. Nushell launches other programs, and so passes on its XDG settings. I guess a user could pass one XDG_DATA_HOME value to Nushell and then set a different XDG_DATA_HOME in env.nu for launched applications to inherit, but that's starting to get quite unintuitive and convoluted.

@tombh Looking forward to see this PR landed! Thank you in advance!

Testing this now (apologies for the delay). Some thoughts as I'm going through it:

1. My first natural attempt (even though I knew this wasn't right), was to set the path to a directory - ~/.local/share/nushell. This, of course, didn't work, but I would have expected a warning at startup. As it is, I only get an error when calling the history command itself. From the looks of it, history import would also error.

   But I'd expect a warning at startup if the history path isn't valid. Related - Item 4 below.

   I get why the full filename must be specified, though - If the user wants it in their home directory, then they probably want to name it something like .nushell-history.txt.

   Perhaps the warning could even catch the fact that a (valid) directory was specified instead of a file.

2. My second attempt was a more sensible try at setting it to:

   $env.config.history.path = '~/.local/share/nushell/history.txt'

   This also failed since ~ isn't expanded in a quoted string.

   To use a tilde as the home directory, you have to path expand it:

   $env.config.history.path = ('~/.local/share/nushell/history.txt' | path expand)

   This might be okay as long as we document it, but is it possible to expand this string on the Rust side?

3. The $nu.history-path isn't getting set properly. It always points to the config directory, even when using a different file.

4. Tested setting it to an int, and it failed, which is ... good? The problem here is that errors in the config cause any subsequent config to not load (see Startup/config files should continue-on-error by default #13210).

   Should this be a warning instead? I believe the code will continue after a warning is triggered.

5. Tests - Let's nail down the behavior first, but yes, we'll need some.

Thanks for the feedback. I'm still interested in working on this. I'll update soon.