Separate path for settings and history?

[mdnava]

Hi... is there a way to have a separate path for the settings file and the history file?..

I tried using the %CLINK_INPUTRC% environment var but it seems to take only a folder path.

I ask for this because I'd like to have a single settings file in the Cloud for different computers, but different history files locally for each computer.. This would also prevent locked files in the Cloud, which is cause for syncing issues.

[chrisant996]

The settings and history files are stored in the profile directory. There isn't currently a way to separate them.

Have you explored if there's a way for your cloud syncing software to exclude the history files?

I'm reluctant to add settings that selectively override the profile directory for only certain things from the profile. It gets complicated and error-prone pretty quickly. Also, Clink isn't designed to support syncing settings or history or logs or etc. I'm reluctant to make it appear as though it's supported, when it's not.

I added the default_settings file recently, which you could potentially use as an alternative to syncing. It can override the default values for settings, so you could package up your favorite settings into a default_settings that you copy onto each computer, and then you can even use clink set to set some settings locally. You can end up with the best of both worlds (syncing and non-syncing), at the cost of needing to manually deploy the default_settings file -- or you could write a script to handle that automatically. Presumably there is already some set of scripts and other configuration files that you're already manually deploying.

[mdnava]

Hi, thank you for your quick response.

I'm aware of the profile directory. It was like that in 0.4.9. I've just recently found this updated version by chance and now I try to update frequently. I did notice the added default_settings and it could indeed be a solution. It is in fact the reason why I was motivated to asked this question here. I've noticed there has been a lot of improvements and feature "elasticity".

As I mentioned, using default_settings can be a solution, but I've already made a workaround long time ago, since the previous (0.4.9) version, and it could be overwritten by mistake after an update. I don't actually need a solution to this; you can mark this issue as solved after this message, but I'd still like to make a case for this feature. First, consider that almost every shell I use runs from a OneDrive directory and they share the same system PATH, system aliases, environment vars, and a similar prompt; all through the use of autoruns and a global script. The case for CMD is special because Clink gave it new life.

My cloud software (OneDrive) throws syncing errors whenever any locked file is encountered, and if enough syncing errors occur the process may halt altogether. The software doesn't really have any useful options, but does the job. Because of this, history files for Clink must be located outside cloud directories. Also, ideally, each computer should have its own separate command history (I don't think this applies only in my case), because some programs or commands that are available in one computer might not be available in another.

Now, my current solution (what I've done since 0.4.x versions); is to inject Clink within the CMD autorun file, and also execute Clink commands with my customized settings (only during the first CMD run on any computer, or if the settings file is not found).

%Utilities%\Clink\Clink\clink_x64.exe inject --quiet --nolog

Rem There's some more validation (excluded from this example)

If "%$IsFirstRun%"=="YES" (
    %Utilities%\Clink\Clink\clink_x64.exe set cmd.auto_answer answer_yes >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set clink.path %Utilities%\Clink\Lua;%Utilities%\Clink\Lua\modules >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set history.shared true >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set history.max_lines 1000 >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set match.expand_envvars true >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set color.input  "white" >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set color.unrecognized "white" >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set color.argmatcher "bright yellow" >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set color.cmd "bright yellow" >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set color.executable "bright yellow" >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set color.doskey "bright green" >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set color.arg "white" >NUL 2>&1
    %Utilities%\Clink\Clink\clink_x64.exe set color.flag "white" >NUL 2>&1
)
:CLINK_OUT

This has worked fine for few years now, and allows to just drop Clink files whenever there's a new update, without the risk of overwriting customized settings. But still, please consider a way to separate settings from history in the future. Environment vars? Clink arguments?. I think it would simplify things.

Anyway!.. Have a great Sunday!.

[chrisant996]

How do the other shells accommodate this?

• Do they not use locking on the history files? (I hope they use locking, otherwise they'll be susceptible to race conditions that corrupt the history or lose history.)
• Maybe they have a default location for things, and separate configuration for each thing that can have a location, and you've overridden some of them? Probably via environment variables, I would imagine?

I'm potentially willing to add an environment variable to override the history path.

However, I do not want to add one for the settings path -- that leads to a bunch of side effect problems. Nor for the logs path.

Something to consider: the more location override options exist, the more complicated it becomes for me to help with support requests (and more time-consuming for me, and more frustrating for users requesting help). And so I don't really want to add one for the logs path, either, but I expect the logs are giving you trouble as well (lots of conflicts, I expect). Also, adding overrides creates a ripple effect through the documentation and the in-app help text, increasing verbosity and complexity for both. I have to weigh the benefits vs drawbacks. Some people give me feedback that stuff is too complicated already.

[mdnava]

How do the other shells accommodate this?

• Do they not use locking on the history files? (I hope they use locking, otherwise they'll be susceptible to race conditions that corrupt the history or lose history.)
• Maybe they have a default location for things, and separate configuration for each thing that can have a location, and you've overridden some of them? Probably via environment variables, I would imagine?

Well, for Bash,Fish,Zsh,Csh I use MSYS2 which is somewhat self contained, and I haven't had any issues with file locking at all. Configuration rc files are located inside a /home folder within the MSYS2 directory. I can update/replace all other directories and configuration files are kept intact. Some of the history files are also located within the /home folder (.bash_history, .histfile, fish_history). I have not had sync issues with Msys2 and OneDrive, but I did move the cache directory out because it gets incrementally big after each update. I can also add that the default command history for Msys2 shells is ok, but not very reliable.

The case of GIT BASH: it uses the $HOME environment variable to determine where to save the .bash_history file (which I've set within the cloud), or (I believe) fallbacks to $USERPROFILE. There isn't any file locking but the Git Bash history is the least reliable. This history file is updated only after a clean Bash exit. If I open another Git Bash terminal the history is not shared (possible there's an option to fix this) and if I close the terminal without a clean exit, the command history is not saved.

Powershell 7 loads its autorun settings from %Documents%\PowerShell\Microsoft.PowerShell_profile.ps1 and saves the command history in the %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt file. This is perfect out-of-the-box, because the Documents folder is already within the cloud, and the history file is outside. I tested the history file and it seems there's no file locking involved (unless it's locked & released), but I do feel that the Pwsh history is consistent and reliable.

I'm potentially willing to add an environment variable to override the history path.

However, I do not want to add one for the settings path -- that leads to a bunch of side effect problems. Nor for the logs path.

It could work (for me at least). I could move the %LOCALAPPDATA%\clink folder within the cloud directory and make a junction back. I use a lot of those, I have an script that makes them for me after a new Windows install, but is not for everyone. However, if log files are also locked the issue will persist. If both logs and history are file locked, I think it would be best to give a option to move instead the settings file location (which if I'm not mistaken is a non-locked simple text file). But I understand if you have reservations. You know better the inner workings of Clink.

Another thing to possibly consider in the future (in contrast with environment vars) could be the Pwsh standard and/or the standard for Windows programs. Pwsh saves settings in Documents and caching/history in %APPDATA%, while Windows programs usually save settings within %APPDATA% and caching/history within %LOCALAPPDATA%. I do believe personally that the Clink settings file falls into the ROAMING category (this file should be synced), but the history and logs are LOCAL.

Something to consider: the more location override options exist, the more complicated it becomes for me to help with support requests (and more time-consuming for me, and more frustrating for users requesting help). And so I don't really want to add one for the logs path, either, but I expect the logs are giving you trouble as well (lots of conflicts, I expect). Also, adding overrides creates a ripple effect through the documentation and the in-app help text, increasing verbosity and complexity for both. I have to weigh the benefits vs drawbacks. Some people give me feedback that stuff is too complicated already.

I understand. However, as I understand it, I don't think there's an actual option to override config locations, besides the recently added default settings files within the program's folder. I think it's good feature to have default settings available. But I don't think it would be a good idea to modify/customize those files, because changes can get lost after an update if someone forgets to keep them, and forgets to manually make a backup of them.

Please don't feel like I'm trying to impose something. Just trying to share ideas to possibly improve Clink. As I mentioned, I've already come up with a solution in my particular case.

Have a nice day.

[chrisant996]

I'm not happy with the Clink profile directory system.

However, it has been around for many years, and many people have installations that are dependant on it. And, for example, the Cmder package is heavily reliant on it.

Also, several of the Clink settings can be machine-specific local paths. And many other Clink settings can be desirable to be machine-specific.

It'd be easy to completely rewrite how and where config stuff is stored. But that would completely break upgrading in existing installations.

Anyway, I'll ponder this more. I would ideally like some settings to roam. Other settings are, for me, important to NOT roam. Splitting up the settings file into multiple files is, I believe, just about the worst option available (and won't happen).

In my opinion, the best solution currently is to write a script that handles the issue.

If one doesn't care about locking/reliability, then it's easy to use a Lua script to copy settings to/from a roaming file, without having the profile directory itself roam.

[mdnava]

I'm not happy with the Clink profile directory system.

However, it has been around for many years, and many people have installations that are dependant on it. And, for example, the Cmder package is heavily reliant on it.

I hear you!.. I actually used Clink v0.4.x integrated with ConEmu for a few years, but now I use v1.x independent from it, so it works with any terminal. I'm not sure how different is Cmder, but I don't think it would break in ConEmu. I mean, yes, older settings would have to be copied or optionally migrated somehow, but if I remember correctly ConEmu works with Clink by just copying files to a subfolder and activating a checkbox, and there are clear instructions for this (I might be wrong, it was long ago since I've used it that way). Consider the new setting files; last week when I updated to v1.3.5 I had to redo my Clink configuration because things were different for settings I had not set, and some things broke (particularly console colors) . But it was ok. I thought of it as progress. I'd bet I wasn't alone in this. But again, it made me notice this software is actually alive and on going. And forced me to familiarize myself with the newer settings. No complain here.

Also, several of the Clink settings can be machine-specific local paths. And many other Clink settings can be desirable to be machine-specific.

Yeah! I can see how that could be a problem.

It'd be easy to completely rewrite how and where config stuff is stored. But that would completely break upgrading in existing installations.

If you were to decide that's the way to go, you could consider it for a v2.0a branch.. and possibly keep both branches until enough people have upgraded. Many cool software opts to take up this road when making important changes... breaking changes... AutoHotkey 2, PHP 7, Java 8, Python 3, PlayStation 2 😁, etc..

Anyway, I'll ponder this more. I would ideally like some settings to roam. Other settings are, for me, important to NOT roam. Splitting up the settings file into multiple files is, I believe, just about the worst option available (and won't happen).

Yep. Splitting the settings file would most certainly be a bad idea. I can imagine several ways how that would make things harder for the user, but particularly how that would make your life much more difficult, taking into account what you mentioned before about user feedback.. Still, if an option to change the settings file location were to be available, it would be up to the user to decide if those paths were available for roaming/syncing or not. For me at least, it would just work.

In my opinion, the best solution currently is to write a script that handles the issue.

If one doesn't care about locking/reliability, then it's easy to use a Lua script to copy settings to/from a roaming file, without having the profile directory itself roam.

I suppose that'd be possible. My introduction to Lua was actually with this iteration of Clink. It does have potential for many uses, I just wouldn't want to overkill the prompt start process. In my case, I just execute the desired command settings once, and if a console runs for the first time (like in another computer) those commands are executed again.

I do appreciate the command history reliability in Clink. The change has been noticeable.

[chrisant996]

Consider the new setting files; last week when I updated to v1.3.5 I had to redo my Clink configuration because things were different for settings I had not set, and some things broke (particularly console colors) . But it was ok. I thought of it as progress. I'd bet I wasn't alone in this. But again, it made me notice this software is actually alive and on going. And forced me to familiarize myself with the newer settings. No complain here.

I considered omitting the default_settings and default_inputrc files from the .zip file, and having them only be in the setup .exe file. Maybe I should rename them in the .zip file, as another user gave feedback that they don't like for CMD+Clink to have input keys compatible with normal CMD, they prefer bash. Simply renaming or deleting the default_settings and default_inputrc files would revert to the old defaults.

Probably I should include them in the .zip file, but rename them so that they don't cause unexpected problems for people who either dislike change, or -- more importantly -- for people who do not have the luxury of reacting immediately to sudden and unexpected change. I take backward compatibility seriously. Fiddling with colors or a couple key bindings isn't necessarily a big deal, but the new suggestions feature can potentially be incompatible with some match generator Lua scripts, depending on how they have been written, and that could be more problematic.

I appreciate your response to the situation, and that you see it as progress. I can also understand viewpoints that change is unwelcome. I'm trying to find a path forward that allows growth and innovation, with as little disruption as possible. The path seems narrow and elusive... 🙂

It'd be easy to completely rewrite how and where config stuff is stored. But that would completely break upgrading in existing installations.

If you were to decide that's the way to go, you could consider it for a v2.0a branch.. and possibly keep both branches until enough people have upgraded. Many cool software opts to take up this road when making important changes... breaking changes... AutoHotkey 2, PHP 7, Java 8, Python 3, PlayStation 2 😁, etc..

It would double the support work for me. 🙃 And also be complicated for users. And for example, Cmder and its users would likely stay on v1.x forever. Forking the product avoids one problem, but creates other problems.

Still, if an option to change the settings file location were to be available, it would be up to the user to decide if those paths were available for roaming/syncing or not. For me at least, it would just work.

I will explore the possibility of an environment variable to specify the location (and possibly also the filename) of the settings file.

In my opinion, the best solution currently is to write a script that handles the issue. If one doesn't care about locking/reliability, then it's easy to use a Lua script to copy settings to/from a roaming file, without having the profile directory itself roam.

I suppose that'd be possible. My introduction to Lua was actually with this iteration of Clink. It does have potential for many uses, I just wouldn't want to overkill the prompt start process. In my case, I just execute the desired command settings once, and if a console runs for the first time (like in another computer) those commands are executed again.

Copying the clink_settings file from a OneDrive folder to the Clink profile directory, and vice versa, will be a lightweight operation. Every new input line completely reads the entire history file. The settings file is orders of magnitude smaller.

I do appreciate the command history reliability in Clink. The change has been noticeable.

Glad to hear it!

[chrisant996]

Notes to self:

• Consider envvar for settings folder, or folder+filename.
• Consider renaming default_settings and default_inputrc in the .zip file.

[mdnava]

Probably I should include them in the .zip file, but rename them so that they don't cause unexpected problems for people who either dislike change, or -- more importantly -- for people who do not have the luxury of reacting immediately to sudden and unexpected change. I take backward compatibility seriously.

If you decide to act on this, you could rename the files as you're considering, or comment out (and explain) lines that could potentially cause issues or activate new features (like Apache or PHP config files). Renaming would force the user to activate the file (which is a good thing). Commenting out lines would still allow you to set some defaults.

It would double the support work for me. 🙃 And also be complicated for users. And for example, Cmder and its users would likely stay on v1.x forever. Forking the product avoids one problem, but creates other problems.

I understand. Just brainstorming.

I will explore the possibility of an environment variable to specify the location (and possibly also the filename) of the settings file.

Cool! 👍

Copying the clink_settings file from a OneDrive folder to the Clink profile directory, and vice versa, will be a lightweight operation. Every new input line completely reads the entire history file. The settings file is orders of magnitude smaller.

Yes. But it can add up. Particularly writing operations. I can think of an scenario when the drive is already in the midst of heavy operations that even small new tasks can hinder system performance (that includes pressing the arrow keys to loop thru the command history). It is a very extreme example, and it would be trivial for a SSD, but in my case I'd prefer to minimize disk operations when starting a shell or prompt, specially if they were to happen on every prompt.

[chrisant996]

Yes. But it can add up. Particularly writing operations.

Yes. Copying would only need to happen if the file has actually changed. For me, at least, the settings file hardly ever changes.

os.globfiles() with the extrainfo arg true will include the file timestamps. A script could compare whether the timestamp changed and only copy if so. However, you'd want to also write the timestamp into e.g. the same file that stores the "already initialized" flag, so that on startup the script can detect whether the setting file changed since last time.

I can think of an scenario when the drive is already in the midst of heavy operations that even small new tasks can hinder system performance (that includes pressing the arrow keys to loop thru the command history).

Sidebar: Are you saying pressing the arrow keys is slow? There is no disk access there. Only searching in memory, and updating the terminal display.

It is a very extreme example, and it would be trivial for a SSD, but in my case I'd prefer to minimize disk operations when starting a shell or prompt, specially if they were to happen on every prompt.

Point taken. All of my machines (except one old file server) have high end SSD drives.

[bw1faeh0]

@mdnava Have you tried using symlinks to clink_settings file?

My solution is to put the clink_settings file to my syncing dir (in my case a git repo) and creating a symlink to %USERPROFILE%\AppData\Local\clink\clink_settings:

mklink %USERPROFILE%\AppData\Local\clink\clink_settings %USERPROFILE%\configFiles\clink_settings

(by using symlinks like this I sync a lot of tools settings across my machines)

[chrisant996]

@bw1faeh0 that's slick. I will play with that a bit and probably add a note in the Clink docs.

Because no matter what, there's not a way to make the settings file "sync by default" without breaking existing installs. Since some kind of manual config is needed no matter what, then a symlink seems even better than an envvar or regkey or whatnot.

[mdnava]

Yes. Copying would only need to happen if the file has actually changed. For me, at least, the settings file hardly ever changes. os.globfiles() with the extrainfo arg true will include the file timestamps. A script could compare whether the timestamp changed and only copy if so. However, you'd want to also write the timestamp into e.g. the same file that stores the "already initialized" flag, so that on startup the script can detect whether the setting file changed since last time.

Noted.

Sidebar: Are you saying pressing the arrow keys is slow? There is no disk access there. Only searching in memory, and updating the terminal display.

No at all. The command history is generally very responsive. But I've experienced the scenario I described (the system being real busy with intensive I/O). That's why I though there was drive access when invoking the command history. Probably that intensive work also affected other kinds of operations.

However, at random times it does take a little more time than usual for the history to show up without the system being that busy (like when a program access drive data). I don't think is an issue, but it happens every now and then. In those sporadic cases there could be a factor other than Clink, like ConEmu itself, or Windows. I actually tried to replicate this several times (in ConEmu and WinTerminal) for the purpose of this conversation but I could not make it happen. So, it's only an anecdote at this time.

@mdnava Have you tried using symlinks to clink_settings file?

My solution is to put the clink_settings file to my syncing dir (in my case a git repo) and creating a symlink to %USERPROFILE%\AppData\Local\clink\clink_settings:

@bw1faeh0 @chrisant996 Yes I have tried. You can freely use junctions and symlinks from OneDrive directories to locations outside but not the other way around. If you make a junction or a symlink from the outside into OneDrive, this will work in the local machine, but any content within those folders/files will not get uploaded or synced at all.

[bw1faeh0]

You have to copy clink_settings to your OneDrive first, then delete %USERPROFILE%\AppData\Local\clink\clink_settings and as last step create the symlink. The symlink has to point into OneDrive.

[mdnava]

You have to copy clink_settings to your OneDrive first, then delete %USERPROFILE%\AppData\Local\clink\clink_settings and as last step create the symlink. The symlink has to point into OneDrive.

Mmm.. I had it backwards.. your example could work. I think I'll give it a try. I didn't try it before because I've had issues with symlinks in the past. Some programs replace the target symlink with the actual file they're attempting to write. But I use the same principle with folder junctions to sync to the cloud, which never fails.

Thanks!

[chrisant996]

Added %CLINK_SETTINGS% which overrides the directory where the clink_settings file is located. Commit 5b8d1f82401257121a9d637df9b94fafc002ef39.

[mdnava]

Tested in v1.3.8!. Works great, thank you very much.. I've removed my previous workarounds. To be clear, it sets the directory where the "clink_settings" file is located..

I read the documentation. Just wanted to mention that OneDrive automatically sets the %ONEDRIVE% environment var where the cloud folder is located locally. This is much more reliable than using the %USERPROFILE% var.

In my case: CLINK_SETTINGS=%ONEDRIVE%\Command\Utilities\Clink\Config

I do think you could mention in the documentation that the %CLINK_SETTINGS% location excludes the history files, which are created on their default %LOCALAPPDATA%\clink location (or where it's set by the --profile option). It's obvious for me. But makes it clear it now allows for synced settings and a local history. It also helps to avoid sync issues with locked files (history files).

Note1: I don't use , nor do I need it in any way, but perhaps you could consider this file to be also loaded from the config folder, so it persists between manual updates, and also syncs. Just an idea.

Note2: In the documentation, it seems the "Clink Settings" table is broken at "terminal.mouse_modifier".

Have a great week!

[chrisant996]

Tested in v1.3.8!. Works great, thank you very much.. I've removed my previous workarounds. To be clear, it sets the directory where the "clink_settings" file is located..

Yes, that's what the documentation says it does.

I do think you could mention in the documentation that the %CLINK_SETTINGS% location excludes the history files, which are created on their default %LOCALAPPDATA%\clink location (or where it's set by the --profile option). It's obvious for me. But makes it clear it now allows for synced settings and a local history. It also helps to avoid sync issues with locked files (history files).

I'm puzzled. The docs state "it does X". Why do I need to change the docs to "it does X, and it does not do Y or Z, and it is not affected by A or B, and it does not affect A or B"?

Note1: I don't use , nor do I need it in any way, but perhaps you could consider this file to be also loaded from the config folder, so it persists between manual updates, and also syncs. Just an idea.

That is a puzzling statement. Maybe you have not read Startup Cmd Script? It sounds like you are asking for it to work the way it works...?

Note2: In the documentation, it seems the "Clink Settings" table is broken at "terminal.mouse_modifier".

Thanks; fixed!

[mdnava]

I'm puzzled. The docs state "it does X". Why do I need to change the docs to "it does X, and it does not do Y or Z, and it is not affected by A or B, and it does not affect A or B"? exhaustivo

It's not really necessary to explain that it does not do Y or Z. Please ignore my comment if it serves no purpose. Clink's documentation is very helpful, and somewhat thorough. I just put myself for a moment into a place where I'm reading the documentation for the first time and the first place I go is to "Files » clink_settings". The program uses the profile dir for the config file and the history file. I just thought it was worth mentioning again the history file is not included when setting up the EnvVar. As you've already mentioned in the documentation, it could get confusing for some; even more, I think some new users may confuse both the --profile option and the %CLINK_SETTINGS% var as the same feature in a different boxing.

I just thought it was worth mentioning. But there's no actual need.

That is a puzzling statement. Maybe you have not read Startup Cmd Script? It sounds like you are asking for it to work the way it works...?

Now I'm a bit puzzled myself.. Does Clink reads the "Startup Cmd Script" from then config directory set up by the %CLINK_SETTINGS% EnvVar?.. Again, I don't use this script, nor I'm interested in using it because I already implement a batch autorun (from where I inject Clink). The logic for my comment was that (I believe), any customizable configuration file should be kept in a place available for syncing, where its content is not lost after each manual update. Replace/update the program folder, keep all customizations. But perhaps I'm not clear about what the "Startup Cmd Script" does.

Have a great week!

[chrisant996]

Now I'm a bit puzzled myself.. Does Clink reads the "Startup Cmd Script" from then config directory set up by the %CLINK_SETTINGS% EnvVar?

You have misunderstood one or more things, I think.

Clink has a profile directory. If anything is a "config" directory for Clink, it is the profile directory.

The env var does not set a config directory. Not at all.

It sets a location for only the clink_settings file. That is a unique new ability, to move the clink_settings file somewhere other than the profile directory. But there are at least 4 other ways already to set the profile directory.

So, no, the new env var should not set the profile directory. That would defeat its reason to exist.

.. Again, I don't use this script, nor I'm interested in using it because I already implement a batch autorun (from where I inject Clink). The logic for my comment was that (I believe), any customizable configuration file should be kept in a place available for syncing, where its content is not lost after each manual update. Replace/update the program folder, keep all customizations. But perhaps I'm not clear about what the "Startup Cmd Script" does.

If you want to use OneDrive as your mechanism to sync programs, scripts, and configuration between computers, then by all means do so. I do not find it sufficient or safe enough for my purposes -- notably it lacks version control or history.

The doc link I shared says the setting that controls the location and name of the Clink startup script. Set the existing one, rather than making this new env var serve multiple roles. 🙃

I am not going to try to make Clink natively support syncing, for the reasons I described earlier. Dealing with conflicts and locks and corruption and data loss and specifying which settings to roam and which not to roam... That is far too complicated and unreliable. And without that level of support, it would be useless/harmful for me to use, myself.

It may require some reading, but I believe all the needed configuration mechanisms exist to separate things the way you want.

Have a great week!

Thank you, and thank you for the useful discussion to clarify things!

[mdnava]

Yes, I am pretty much covered. Thank you!. And I think other people will also find the new EnvVar useful.

BTW.. In case it's of any use, OneDrive for Business does have versioning and file history. It can also easily coexist with Git and other solutions.

[chrisant996]

BTW.. In case it's of any use, OneDrive for Business does have versioning and file history. It can also easily coexist with Git and other solutions.

It is not my intention to debate here the features in OneDrive, nor to explain at length my needs. It would have been better for me to simply say "it does not meet my needs".