Duplicated installations of Clink causes profile overriding

[DRSDavidSoft]

Hey @DRSDavidSoft I've been testing the build and the error is not present anymore, but I would like to point out a few things I've noticed about the clink injection behaviour (also present in past builds, not only this new one):

1 - For people like my that already have clink injected on cmd, the history is not available if using cmder.
2 - If I comment line 207 of vendor\init.bat (or 41 of \config\user_init.cmd)
"%CMDER_ROOT%\vendor\clink\clink_%clink_architecture%.exe" inject --quiet --profile "%CMDER_CONFIG_DIR%" --scripts "%CMDER_ROOT%\vendor"
clink still works, since it is already in the system, and also the command history, but then I lose the lambda symbol in the prompt, and I think colors too.

If I change the --profile "%CMDER_CONFIG_DIR%" to --profile "MY_SYSTEM_CLINK_DIR" then I have the lambda, colors AND my command history.

Running clink autorun show gives me the system autorun config, and I can take from there the profile path so I can see my history on cmder.

Now, why is clink and the lambda/colors of the command window related? Aren't we injecting clink twice, one from the system and one from cmder?

Thanks!

Originally posted by @pmsobrado in #2800 (comment)

[DRSDavidSoft]

Hi @pmsobrado I believe @chrisant996 may be able to better answer these questions, but here's my take:

Firstly, as you have already seen, Cmder uses Clink and store its configuration profile in %CMDER_CONFIG_DIR%, which for example is [cmder]\config. Your history and settings are stored in clink_history and clink_settings respectively. Additionally, the lambada prompt is stored under [cmder]\vendor directory, in form of lua files, such as clink.lua.

If you already have Clink running from before, injecting it again while passing the paths of Cmder profile will override your running Clink with the profile that is in the Cmder directory.

In the other way around, if you completely remove the line that injects Clink, whatever you were running from before will be inherited, which as you said, contains both old history, and also doesn't include the lua script files in Cmder that sets the lambada prompt.

When you only set your --profile to the other place you had on your disk, the settings and history from there will be used -- but since you left the --scripts path to the lua directory inside Cmder (which translates to [cmder]\vendor), the scripts that set the prompt to green and load lambada are used (alongside other cool things, like clink completions) while still using your other profile (i.e. history & settings). I hope this much is clear.

I should point out that we need to implement a method to detect if Clink is already injected, and if the user wants, entirely bypass our own version of Clink -- although this has not implemented yet, so you can for now do this by commenting/uncommenting the line in init.bat where we inject Clink with our profile path and our scripts path.

Now, in my opinion, you have a dilemma on your hands. Do you actually want to have separate Clink profiles, or not? Personally, I'm against having installed multiple versions of the same thing on my machine, and tend to re-use components in other projects.

For example, do you really need to set vanilla Clink as startup so that it opens all the time, and only run Cmder from time to time you need? Or would you prefer to set the Clink inside Cmder as your startup, so you don't have duplicate settings & history files? Or maybe you'd prefer to set Cmder itself as AutoRun (I mean the init.bat component). Here's the wiki page that explains this:

https://github.com/cmderdev/cmder/wiki/Cmder's-shell-in-other-terminals

I can understand if you want or need separate profiles. You can have multiple Cmder installations or multiple Clink installations, or a combination of both, each with their separate profile directories. I know some colleagues of mine do this to separate their work environment from their hobby environment, but I personally prefer to have a unified profile and one installation of Clink, the one inside Cmder. I personally don't use ConEmu that much. So whenever I need a shell, the init.bat file injects Clink to the running Cmd.exe process, so I can use in ConHost.exe (i.e. the old Command Prompt) and Windows Terminal (wt.exe). You can have a look at the Wiki for a list of terminals and how you can use them with Cmder (in place of ConEmu).

So, you have two options.

1. Keep using separate, multiple, different directories of Clink, each with their own configuration
2. Remove all other Clink directories, and use a unified one, prefereably the latest version

In option 1, you need to either copy scripts & configurations between your profiles, or use the --scripts and --profile arguments to point to a single directory to achieve consistent results. I don't recommend this for your use case.

In option 2, you need to remove all but one Clink directory, and set that as your AutoRun. I suggest the one that resides in Cmder.

If you'd like to go with option 2, please first un-set the other Clink as your AutoRun, back its configuration up, and remove/uninstall it. Then open the configuration directory of your primary Clink installation and merge your settings with it. Now, set that as your startup, while also updating other references to Clink to use the new path. I also suggest adding the installation directory of Clink to your path.

For example, if you'd like to keep your existing installation of Clink, please edit init.bat to reference the old directory, and also modify your AutoRun settings to also use the scripts provided by Cmder. Or don't, if you don't want to have Cmder prompt in your AutoRun, and only want to have Cmder prompt when you launch Cmder, while still retaining your old history & settings.

I personally suggest the othe way around. Remove your existing Clink installation while moving your history to Cmder, and merging your old Clink settings file with the Cmder one found in the config directory. Then update your AutoRun settings to use either Cmder's init.bat as AutoRun, or Clink itself as AutoRun.

Personally, me and @chrisant996 are against using AutoRun, but this surely works.

I don't know your particular use case, but maybe instead of AutoRun, this alternative might satisfy you:

Wiki page: https://github.com/cmderdev/cmder/wiki/Seamless-Windows-Terminal-Integration
Section: Optional Steps, Default terminal application
(While settings Cmder as the default profile).

[DRSDavidSoft]

Cmder.demonstration.all.mp4

[daxgames]

We should be able to detect if clink is already injected and use its profile folder in place of %CMDER_CONFIG_FOLDER%

I am looking at that now in my more_speed_2 branch

[daxgames]

I take that back. Not sure how to detect if clink is already injected since clink info produces an error inside a batch file.

[pmsobrado]

@daxgames maybe looking at the registry key where clink writes the autorun injection?
Equipo\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Command Processor

@DRSDavidSoft Thanks for the explanations! It is much more clear to me now. But for now, I think I'm gonna go with the global clink and the modified profile path in Cmder. I have clink installed and injected on the system, and for me, right now it makes more sense for cmder to use that installation, that to uninstall clink from the system and inject (in the system) a clink that is not really installed and inside a folder inside another app/program that it's also not actually installed.

Probably it's a bad approach but for now, it works for me. I use both cmd and cmder depending on the task, and I don't know anything about the clink scripts functionality so for me, everything is in place now.

I actually only use cmder for the looks (it's cooler than cmd) and the multiple consoles feature, since I already have "Windows subsystem for Linux" and Cygwin 😅 sorry about that! Great app anyway xD

[DRSDavidSoft]

@pmsobrado That's great, it's recommended to use programs that are installed globally, rather than what's inside essentially portable ones, such is Cmder. Many people use Cmder because of its looks! 😄 Besides, you should use what works best for you, for your use case.

My only suggestion is to go with option 1, use your global Clink profile (that enables you to retain your global settings & history) and only use the scripts in Cmder for the added prompt when you launch it.

Essentially, what you described in your original comment, when you changed the clink profile path to your global one's.

Cheers!

[chrisant996]

There's a lot to unpack.

Re: lambda prompt

@pmsobrado, I'm pretty sure here is why you're experiencing the issue "no lambda prompt when I use cmder /c" -- it's the only way I'm able to reproduce the reported issue:

• You have your Clink scripts in the same directory as your non-Cmder copy of Clink executable files (which is where I put my own Clink scripts, as well).
• You have a prompt filter script among your Clink scripts that uses a smaller priority number than Cmder's prompt filter, and it explicitly halts further prompt filtering thus Cmder's prompt filter is never reached.
  • Are you using clink-flex-prompt?

So, using cmder /c causes the following to happen:

1. Starting cmd.exe automatically injects Clink.
2. Cmder injects Clink and points --scripts to Cmder's vendor\ directory to load Cmder's Clink scripts.
3. The Clink scripts in the non-Cmder copy get loaded.
4. The prompt filter script(s) from the non-Cmder copy of Clink run earlier than the Cmder prompt filter and block it from running.

That is not a bug -- that is exactly how the prompt filters are meant to work, so that e.g. you can supersede the lambda prompt with clink-flex-prompt if you choose to.

But, it doesn't take into account the case where someone wants Cmder's prompt filter to take precedence even though another prompt such as clink-flex-prompt is also installed (otherwise, Cmder's prompt filter would append to clink-flex-prompt, making a mess of things).

The simplest thing to do as a quick solution is for @pmsobrado to change the priority number of the Cmder prompt. @DRSDavidSoft please do not make that change in the main Cmder, as that would create other problems. I'll think about how to make everything coexist in a configurable manner, and reply here again later.

E.g. for now you could change the 1 to -9, the 50 to -8, and the 51 to -7. Again, that's not a long-term solution, it's just a temporary measure until Cmder and/or clink-flex-prompt have a way to configure whether to apply their prompts, separate from whether they're installed.

EDIT: Nope, just changing the priority numbers won't be enough. @pmsobrado, what other prompt are you using outside of Cmder?
If it's clink-flex-prompt, then I can make a change in clink-flex-prompt to make it conditional whether to supersede the Cmder prompt.

re: sharing Clink profile (history and settings) between Cmder and non-Cmder windows

@pmsobrado, I think in the current versions of Cmder the simplest way to get your normal profile to be used is set the CMDER_USER_CONFIG environment variable to your profile directory, instead of using cmder /c.

You could set it in the ConEmu environment variables section, or in the System control panel.

EDIT: That might work ... but it will still load scripts from Cmder's config directory, not from your Clink profile directory. See here for details. So, depending on exactly how you have your Clink profile(s) set up, it may or may not do quite you want expect.

re: clink not working in a batch script

clink info produces an error inside a batch file.

@daxgames The only reason clink info works at a prompt is because Clink creates a doskey macro to add a fully qualified path to itself. In the init.bat script you need to use the full path to Clink, just like when it runs clink inject.

re: detecting whether Clink is injected

clink info won't tell you that. In fact, Clink doesn't have a way to ask that at all, because Clink cannot reliably answer the question "is Clink injected successfully".

It can be approximated like this, but that will be a bit slow and I wouldn't recommend it for Cmder.

Instead, if Cmder wants to make it optional whether to use the Cmder Clink profile directory or a user's own Clink profile directory, then I would suggest having a flag such as /profile in CmderLauncher.cpp and update init.bat accordingly, etc. And/or a config setting to choose whether to use a custom Cmder profile, or the default Clink user profile, or a custom Clink user profile, etc.

I can help with those change in Cmder if needed; if that's desired then @daxgames @DRSDavidSoft please open a separate issue/discussion for that.

re: overriding --scripts

I recommend to not mess around with changing --scripts. The reasons why not are a bit complicated. I'm happy to discuss further, but if so then that should happen in a separate discussion topic.

[pmsobrado]

Hi @chrisant996. About the lambda prompt, what I did was to open a clean copy of cmder with no configs changed with the /c parameter, and the lambda wasn't there. I don't know what kind of fix @daxgames implemented but, in any case, I'm not launching cmder with /c anymore. Instead I'm running it directly from the exe.

About the profile sharing, if I remember correctly, setting the CMDER_USER_CONFIG variable had no effect. Or maybe it was another variable... CLINK_PROFILE?

I have left the --scripts options untouched.

[daxgames]

@chrisant996 I was going at it in a VERY rudimentary way I was just going to:

1. Run set "CLINK_PROFILE=%CMDER_CONFIG_DIR%"
2. Run clink info
3. Grab the state value it returns.
4. Override env var %CLINK_PROFILE% to the captured value.
5. Use %CLINK_PROFILE% in the Cmder clink injection instead of %CMDER_CONFIG_DIR%

But even that does not work because even if clink is notr injewcted it reports a value for state.

[chrisant996]

Also, step 1 would be problematic for two reasons:

• A user may have set CLINK_PROFILE to point at their profile directory, and then step 1 would stomp on their setting and end up returning an inaccurate profile directory.
• Setting CLINK_PROFILE supersedes all other mechanisms of specifying the profile directory. So step 1 would make it always report that %CMDER_CONFIG_DIR% is the profile directory, no matter what.

[chrisant996]

By the way, an important note: clink info does not attempt to inspect the actual runtime state of the actual injected Clink (that would be very complicated and unreliable). Instead it looks at the current environment variables and settings and figures out what the profile/etc would be. Except that if Clink is already injected, then it will have set a hidden environment variable =clink.profile (only accessible from high level languages like C/C++/Rust/Go/etc), and if that variable is present then that's what clink info reports.

But you'd have to be careful to not actually set CLINK_PROFILE, since that overrides even checking for =clink.profile.

[daxgames]

@chrisant996 Good to know. I didn't even know %CLINK_PROFILE% was a thing, so substitute %CMDER_CLINK_PROFILE% everywhere I said %CLINK_PROFILE%.

[chrisant996]

Oh, I see. As you noted, it wouldn't work anyway, because of what I mentioned here.

[chrisant996]

@pmsobrado just to be clear: there is currently no way to get Cmder to work entirely correctly with a non-Cmder profile for Clink.

But you can get close, in a number of different ways.

Here is the simplest way:

NOTE: This will only work as expected if you don't have any Lua scripts in your Clink profile directory.

Set CLINK_PROFILE={your preferred profile directory to use for all cmd windows}:

1. Run sysdm.cpl to open the System control panel applet.
2. Click on the "Advanced" tab.
3. Click on the "Environment Variables..." button near the bottom.
4. Click on the "New..." button.
5. Enter CLINK_PROFILE for the variable name.
6. Enter your preferred profile directory for the variable value.
7. Click on the "OK" button.

Then all cmd windows will use that profile directory.

Cmder should use history and settings from there.

But Cmder will still forcibly load Lua scripts from its own internal Clink profile directory at %CMDER_ROOT%\config. But it will not load any scripts from your own Clink profile directory (i.e. from step 6 above).

There is a bug in cmder /c:

@daxgames @DRSDavidSoft It lets the user specify a different Cmder config directory, but it loads scripts from the default Cmder config directory and does not load scripts from the specified config directory.

It's because right here Cmder looks for %CMDER_ROOT%\config instead of using %CMDER_USER_CONFIG%.

Two regressions were introduced in clink.lua in PR #1884 in Sep 2018 while fixing issue #1882.

1. When not using cmder /c, no scripts are loaded from %CMDER_ROOT%\config.
2. When using cmder /c, scripts are loaded from the normal %CMDER_ROOT%\config instead of the user config directory that was specified.

The intent of the change was to fix a bug that was accidentally loading from both %CMDER_ROOT%\config and %CMDER_USER_CONFIG%. A mistake in the change accidentally broke both cases.

The code should be something like this at the end of clink.lua:

local cmder_config_dir
if clink.get_env('CMDER_USER_CONFIG') then
    cmder_config_dir = clink.get_env('CMDER_USER_CONFIG')
else
    cmder_config_dir = clink.get_env('CMDER_ROOT')..'/config/'
end
for _,lua_module in ipairs(clink.find_files(cmder_config_dir..'*.lua')) do
    local filename = cmder_config_dir..lua_module
    -- use dofile instead of require because require caches loaded modules
    -- so config reloading using Alt-Q won't reload updated modules.
    dofile(filename)
end

In other words, here are the diffs to apply:

@@  -669,9  +669,12  @@
+local cmder_config_dir
 if clink.get_env('CMDER_USER_CONFIG') then
+    cmder_config_dir = clink.get_env('CMDER_USER_CONFIG')
+else
-    local cmder_config_dir = clink.get_env('CMDER_ROOT')..'/config/'
+    cmder_config_dir = clink.get_env('CMDER_ROOT')..'/config/'
+end
-    for _,lua_module in ipairs(clink.find_files(cmder_config_dir..'*.lua')) do
+for _,lua_module in ipairs(clink.find_files(cmder_config_dir..'*.lua')) do
-        local filename = cmder_config_dir..lua_module
+    local filename = cmder_config_dir..lua_module
-        -- use dofile instead of require because require caches loaded modules
+    -- use dofile instead of require because require caches loaded modules
-        -- so config reloading using Alt-Q won't reload updated modules.
+    -- so config reloading using Alt-Q won't reload updated modules.
-        dofile(filename)
+    dofile(filename)
-    end
+end
-end

[pmsobrado]

@chrisant996 Thanks, I'll do that!

[daxgames]

@chrisant996 Thank you for looking at this and I understand you have looked at this a lot today but take a look at the below and tell me if it makes sense.

I believe the code in %cmder_root%\vendor\clink.lua is NOT a bug and is working as designed and intended. I am reluctant to change it since I know there are users using it in the manner described below.

The Cmder.exe /c "[folderpath]" setting allows an Admininistrator to centrally install and configure Cmder in C:\Program Files\Cmder with global config, bin, and opt folder structures that will contain centrally maintained default applications and configuration in a multiuser system while allowing individual users the ability to have their own customizations in a user private location.

Users can then launch Cmder.exe /c "%userprofile%\.config\cmder" using a shortcut provided by the Administrator. This tells Cmder to create and use user specific config, bin, and opt folders under "%userprofile%\.config\cmder"

The "%cmder_root%\vendor\clink.lua" code that exists today in the repo checks to see if /c [folderpath] was used to launch Cmder and if it was it loads the centrally located and managed *.lua scripts that Clink would have no knowledge of BEFORE Clink itself loads the lua scripts from the profile folder specified on the Clink injection Command line.

To be clear there is no lua code in Cmder that loads the scripts from the profile folder it appears that Clink does this loading entirely by itself.

I have confirmed that lua code is indeed being loaded from both locations in the correct order by setting differing settings in the [cmder folder path]\config\cmder_prompt_config.lua in both locations as such code in the user private location wins if it exists.

If I comment ALL code in the user private %userprofile%\.config\cmder\config\cmder_prompt_config.lua the prompt is correctly configured using the centrally installed and managed C:\Program Files\Cmder\config\cmder_prompt_config.lua that clink.exe would be unaware of without the code in %cmder_root%\vendor\clink.lua.

Edit - The below prompt was acheived by setting some settings in both files:

• Central Config

  --- REQUIRED. config_prompt_useHomeSymbol is whether to show ~ instead of the full path to the user's home folder
   -- Use true or false
   -- default is false
  prompt_useHomeSymbol = true
  
  -- Symbols
  -- REQUIRED. Prompt displayed instead of user's home folder e.g. C:\Users\username
   -- default is '~'
  prompt_homeSymbol = "~"
  
  -- REQUIRED. Symbol displayed in the new line below the prompt.
   -- default is 'λ'
  -- prompt_lambSymbol = "λ"
  prompt_lambSymbol = "#"
  
  -- REQUIRED. Adds [user]@[host] to the beginning of the prompt like bash
   -- default is false
  prompt_useUserAtHost = true
  
  -- REQUIRED. If true prompt is a single line instead of default two line prompt.
   -- default is false
  prompt_singleLine = false
  
  

• User Private Config

  --- REQUIRED. config_prompt_useHomeSymbol is whether to show ~ instead of the full path to the user's home folder
   -- Use true or false
   -- default is false
  -- prompt_useHomeSymbol = false
  
  -- Symbols
  -- REQUIRED. Prompt displayed instead of user's home folder e.g. C:\Users\username
   -- default is '~'
  prompt_homeSymbol = "~"
  
  -- REQUIRED. Symbol displayed in the new line below the prompt.
   -- default is 'λ'
  -- prompt_lambSymbol = "$"
  
  -- REQUIRED. Adds [user]@[host] to the beginning of the prompt like bash
   -- default is false
  prompt_useUserAtHost = true
  
  -- REQUIRED. If true prompt is a single line instead of default two line prompt.
   -- default is false
  prompt_singleLine = true
  

If the above does not make sense please let me know.

[chrisant996]

I'll take a look later tonight. Some of the statements don't make sense to me, but maybe I overlooked something. I'll dig into it in more detail and respond with my findings.

[daxgames]

@chrisant996 No big hurry. I added more to the previous comment to show more of wat I was talking about.

[chrisant996]

I believe the code in %cmder_root%\vendor\clink.lua is NOT a bug and is working as designed and intended. I am reluctant to change it since I know there are users using it in the manner described below.

The Cmder.exe /c "[folderpath]" setting allows an Admininistrator to centrally install and configure Cmder in C:\Program Files\Cmder with global config, bin, and opt folder structures that will contain centrally maintained default applications and configuration in a multiuser system while allowing individual users the ability to have their own customizations in a user private location.

Users can then launch Cmder.exe /c "%userprofile%\.config\cmder" using a shortcut provided by the Administrator. This tells Cmder to create and use user specific config, bin, and opt folders under "%userprofile%\.config\cmder"

The "%cmder_root%\vendor\clink.lua" code that exists today in the repo checks to see if /c [folderpath] was used to launch Cmder and if it was it loads the centrally located and managed *.lua scripts that Clink would have no knowledge of BEFORE Clink itself loads the lua scripts from the profile folder specified on the Clink injection Command line.

@daxgames Ah, I see, thanks for investigating and explaining. I indeed inaccurately reverse-engineered the intent of the code.

I would recommend adding a comment in the vendor\clink.lua code:

@@  -669,3  +669,6  @@
+-- Clink loads scripts from the profile directory given to it.  If there's a
+-- user config dir then Clink won't know about the default config dir, so we
+-- need to load scripts from there manually.
 if clink.get_env('CMDER_USER_CONFIG') then
     local cmder_config_dir = clink.get_env('CMDER_ROOT')..'/config/'
     for _,lua_module in ipairs(clink.find_files(cmder_config_dir..'*.lua')) do

What was particularly misleading for me was the CMDER_CONFIG_DIR variable. It's used to mean "user config dir, or if no user config dir then the default config dir", and it's only used by a few places. And there is also CMDER_USER_CONFIG which means "user config dir", and it's only used in even fewer places. They led me to anticipate that the config dir would always be referred to by a variable, but that's not the case. On deeper examination, I see that there are many places that use %CMDER_ROOT%\config to explicitly refer to the default config dir without using either of the config dir variables.

(It would likely help readability, searchability, and maintainability if there were also a variable that meant "default config dir". If the three variables were initialized nearby each other then their purposes would be self-documenting, and then the places that repeatedly explicitly construct the default config dir could just refer to a variable. It would also help if there were a comment explaining that the intent is to use some things from the default config dir even if the user overrides it with a custom user config dir -- or if there is such a comment, then maybe I just wasn't able to find it.)

To be clear there is no lua code in Cmder that loads the scripts from the profile folder it appears that Clink does this loading entirely by itself.

I have confirmed that lua code is indeed being loaded from both locations in the correct order by setting differing settings in the [cmder folder path]\config\cmder_prompt_config.lua in both locations as such code in the user private location wins if it exists.

You're right, I was remembering the details incorrectly about that. What happens is Cmder uses --scripts, which originally caused Clink to load scripts only from there. To compensate for that, Cmder has these lines; that's what I was misremembering as "Cmder forcibly loads the scripts".

Also, with Clink v1.0.0 and higher those lines do nothing -- everything from the external clink.lua file has been moved to happen inside the clink_dll_*.dll files, and Clink loads from both the --scripts path and the user's normal script paths.

[daxgames]

Agree 100% and I will try and clarify the code as you suggested. I think the current state is just a result of the code growing organically through different authors.

[chrisant996]

Thanks for explaining how the config dirs are meant to work in Cmder.

That actually presents a further complication for trying to unify Clink profile usage inside/outside of Cmder:

• If the Cmder profile is used both inside/outside of Cmder, then Cmder-specific Lua code runs always, and that's likely a problem.
• If the non-Cmder profile is used both inside/outside of Cmder, then Cmder-specific Lua code does not run, and that's likely a problem.

To me, it looks like the way that Cmder has merged its own config dir with Clink's profile dir makes it difficult to separate them cleanly anymore, at least not without a breaking change that requires some users to rewrite how their configs work.

[daxgames]

@chrisant996 Couldn't @pmsobrado just add a load_my_clink_profile.lua to one of Cmder's config folders

If not using /c [folder] that would be %cmder_root%\config\load_my_clink_profile.lua. Clink would load this script which would load his profile scripts last.

[chrisant996]

No: that would load "non-Cmder" scripts inside Cmder, but that doesn't solve any of the issues.

The main request was to use the same history and settings both inside and outside Cmder. Those files are located in the Clink profile directory (clink_history and clink_settings). The only way to satisfy the main request is to literally use the same Clink profile directory both inside and outside Cmder.

More Info About Clink Profile Challenges in Cmder

It makes perfect sense to me that Cmder forced using using a Cmder-specific profile. It also makes sense to me if there's a desire to have a configuration option for Cmder to use a specific Clink profile. However, that raises the possibility for compatibility problems, so such an option mustn't be the default. If a user doesn't have any Lua scripts that make assumptions about whether they're running in Cmder, then that can work out ok. But if a user has any such scripts, then that will cause malfunctions (and possibly/likely Lua script errors).

And what if the user wants two different prompts -- one inside Cmder and another outside Cmder? That requires either controlling which scripts are loaded, or scripts having configuration options to control whether they register things when inside/outside Cmder. Either way, that's an invasive change to Cmder's vendor\clink.lua file and also to other non-Cmder scripts.

Here's a concrete example: prompts. Such as clink-flex-prompt or cmder-powerline-prompt or a user's own custom prompt.

1. Some users may want their own prompt to replace the Cmder prompt even inside Cmder.
2. Some users may want the Cmder prompt inside Cmder and their own prompt outside Cmder.
3. Some users may want the Cmder prompt both inside and outside Cmder.

So, when both scripts are loaded ... which prompt should be shown? There's no "right" answer.

Cmder assumes that if its vendor\clink.lua file is loaded, then the user wants to see the Cmder prompt.
Similarly, other prompts assume that if their script is loaded, then the users wants to see their prompt.
It would be nonsensical to try to show multiple different prompts at the same time.

Note that there are some scripts that don't create their own prompt and instead just augment another prompt, and it does make sense to load those along with the Cmder prompt. Such as the git_prompt.lua script in clink-completions, which is included under Cmder's vendor directory.
Sidebar: I just now realized that script isn't hooked up to use async prompts yet, and thus is still incurring the cost of git config in the foreground, so I'll update that in the clink-completions repo.

Here are samples of just a few of the ways that clink-flex-prompt can be configured.

[pmsobrado]

I tried setting CMDER_CONFIG_DIR in the settings like this:

but it had no effect, as you can see. Maybe is because of this line on init.bat?

For now, I can only make my clink history to work by manually changing the profile in the user_init.cmd, as I said before.

[daxgames]

@pmsobrado And that is my suggestion of how to fix this. That file is yours to edit after we create it. We would never touch it again unless you forced it to be recreated.

Does the Cmder prompt still work if you do that? If so, is there really an issue to solve?

If there is still something to solve please explain because at this point, I am wondering what we are trying to solve if you have:

• Your external Clink profile history and the Cmder prompt in Cmder
• Your external Clink profile history and prompt outside Cmder.

[pmsobrado]

Nothing to solve by now, at least if manually editing the file and the profile path is the "clean and official" way of doing it. I was just pointing out that setting the variable in the settings does not work :)

[chrisant996]

Nothing to solve by now, at least if manually editing the file and the profile path is the "clean and official" way of doing it. I was just pointing out that setting the variable in the settings does not work :)

@daxgames the way that pmsobrado is achieving the goal is to make a modification to Cmder itself. There is currently no other way to achieve it.

That's why I suggested adding a /profile switch to Cmder and also init.bat. I haven't had a chance yet to review the PR you shared -- maybe it will have a solution for that part.

And my other point is that merging the inside-Cmder and outside-Cmder profiles is possible in many cases, but runs into problems depending on the user's configuration. And therefore it is not reasonable to make a change that by default merges them. Or at least, it's important to call it out as a breaking change, and give guidance for how users can fix their configuration (and that would be a very complicated article to write, much less read...).

[daxgames]

@chrisant996 @pmsobrado is using an unreleased build of Cmder and is editing a file this build puts in the users config folder.

This file is generated by Cmder's init.bat on the FIRST run, but because of its location, it is NOT a part of Cmder and is the users to edit however necessary to achieve the desired configuration.

We could indeed add switch to cmder.exe that would cause this file to be generated with the correct path already in it but the user would need to know they had to do this the FIRST time they run Cmder because after we generate the file we do not touch it again because it now belongs to the users configuration. The user can force it to be regenerated by renaming/deleting it or by manually executing the powershell script that generates it.

[chrisant996]

daxgames wrote:
@chrisant996 @pmsobrado is using an unreleased build of Cmder and is editing a file this build puts in the users config folder.

@daxgames Ah, I see. I was using Cmder 1.3.20 and 1.3.21.

pmsobrado wrote:
I tried setting CMDER_CONFIG_DIR in the settings like this:

set CMDER_CONFIG_DIR=~\clink

@pmsobrado The ~ syntax is not understood by Windows. Clink is able to internally translate certain paths that contain ~, but the %CMDER_CONFIG_DIR% value is used by init.bat and cmd.exe outside of Clink. They do not understand ~, and they'll malfunction given that syntax. Either use environment variables instead, or a fully qualified path.

pmsobrado wrote:
For now, I can only make my clink history to work by manually changing the profile in the user_init.cmd, as I said before.

@pmsobrado Do you mean that your user_init.cmd runs set CLINK_PROFILE=~\clink? Setting CLINK_PROFILE is an extreme approach that overrules all other profile-related configuration. But it's simple to use, so if it's working how you want then it's probably reasonable.

(And it's safe to use ~ in CLINK_PROFILE because it's used only by Clink, and Clink translates the ~ in it -- unlike in CMDER_CONFIG_DIR which is used by things outside Clink and is passed to CMD commands that do not understand ~.)

[pmsobrado]

I just replaced the cmder line with the line clink uses to autorun system wide. I have no more technical knowledge about cmder or clink. I know ~ is not Windows syntax, but is what clink puts on the registry and on autorun, etc. If I change the ~ to %APPDATA% or to my local user folder, it does not work. If I replace it on the cmder settings, it does not work.

It's OK, I only say this because here (or in another issue/discussion) someone (can't remember who) told me to replace the variable instead of hardcoding the line in the settings file. Well, it seems that's not an option. Just letting people know here.

I appreciate all the support but for now, hardcoding the same line clink uses on cmder settings seems the only way to make it work. All other proposed options have failed.

If devs want to think of an option for future releases to support local clink, that's up to them, I'm not really asking for any feature. All this started because I was seeing some weird error messages on the console.

[chrisant996]

Sidebar: I just now realized that script isn't hooked up to use async prompts yet, and thus is still incurring the cost of git config in the foreground, so I'll update that in the clink-completions repo.

It wasn't as bad as it looked at first, since it loads the git config directly instead of invoking git config. But it was still worth making the performance optimization. clink-completions v0.4.9 has been published with the optimization (and a few other things).