[Feature Request] Separate Environment Variable for History File Location

[ss005]

First of all, thank you for creating such an awesome project!
I've been using clink, flex-prompt, and clink-completions, they are really great, save lot of time and make terminal so much enjoyable.

Coming to this feature request:
I am aware that this feature has been requested before, and CLINK_PROFILE environment variable is already there to configure location for all clink profile related files.
However, I mainly want to synchronize the history file across multiple computers so I can easily access previously used commands from any machine.

Currently, I achieve this by setting the CLINK_PROFILE location to a folder in OneDrive.
This works but with some issues:

• All profile-related files, including temporary files e.g. clink_history_12345, clink_history_12345.removal etc, are synced to OneDrive which I don't need.
• Sync conflicts and errors: OneDrive tries to sync all the files including temporary files that are in use, leading to sync errors
• Recycle bin clutter: these temporary/.removals files occasionally end up in the recycle bin due to the sync process I believe

To address these issues, I propose for a separate environment variable (probably CLINK_HISTORY_FILE) for synchronizing history.

Thank you! Let me know if there is any way to achieve this or any additional details are needed.

[chrisant996]

Related: #233, #310, #385, #669

[chrisant996]

However, I mainly want to synchronize the history file across multiple computers so I can easily access previously used commands from any machine.

I can understand the hope. Some observations:

1. It would have reliability problems. File sync software can attempt to both read and write the history files while they're in use.
   • It leads to corrupted history files.
   • It leads to recent commands getting lost when the file sync software picks a "winner" when there are sync conflicts.
   • It leads to access violations where either Clink cannot access the history files, or the file sync software cannot access the history files.
2. Commands from one computer aren't necessary relevant or usable on another computer.

Sync conflicts and errors
Recycle bin clutter

Sync conflicts and errors will be a problem no matter what.
The Recycle Bin clutter is the result of the file sync software picking a "winner" when there are sync conflicts, and it sends the "loser" to the Recycle Bin in case you need to recover lost data from it.

I don't recommend trying to use file sync software on the settings file or history files. It's not going to work out how you hope.

To address these issues, I propose for a separate environment variable (probably CLINK_HISTORY_FILE) for synchronizing history.

But it wouldn't make syncing work. It won't address the sync conflicts and errors.

Also, the CLINK_HISTORY_LABEL env var makes any suggestion about moving history files more complicated. You want to move only one file, but it would also need to move sibling files constructed via all values of CLINK_HISTORY_LABEL that have ever been used. And separating the temporary files from the "real" files is highly problematic because it would break the access synchronization mechanism and would make Clink corrupt its own history files (the access synchronization is how Clink's history is more reliable than other shell history mechanisms, such as bash).

I'm open to considering changes to how history is stored. But the file sync issues can't be addressed by the proposal here, so this isn't a viable option.

[ss005]

Thank you for your detailed explanation, it helped me realize this is more complex than I assumed initially, specially while multiple computers are used at the same time.

Commands from one computer aren't necessary relevant or usable on another computer.

Maybe this is my specific use case, but I often find myself repeatedly using the many long commands across multiple computers and history/auto-completion helps a lot in this case when I switch PC (I don't have to save those command somewhere or find again on internet and everything is backed up, so convenient).

I think I should investigate more about this before making further suggestion, meanwhile I'll explore to create some custom script for my specific use case. This feature request can be closed for now.

Thank you once again!