Clink doesn't launch clink_start.cmd from custom profile folder

[Rygor83]

Good morning,

I am trying to configure clink to launch clink_start.cmd file from custom profile folder. It doesn't work. clink_start.cmd contains chcp 65001 command.

Here is clink info

clink.autostart value

clink custom profile folder

clink_start.cmd in different folders.
If clink_start.cmd is in binaries folder - everything is ok. but if it's in profile folder - nothing happens

[chrisant996]

@Rygor83 I don't think it's a Clink issue:

I've confirmed that it works as described, and as you expected.

But there's another aspect in your specific case:

Your profile is in OneDrive. Which means the clink_start.cmd file is downloaded from the Internet. So I would expect it should be getting marked as being Blocked from executing, until the Unblock button is clicked in the File Properties dialog in File Explorer.

When a file is blocked, CMD won't execute it.

I haven't set up OneDrive to test that theory, but I suspect that's what's going on here. Because certainly for other profile directories (custom or default), the script gets executed as expected.

Can you check whether the script is marked as Blocked?

[Rygor83]

Dear Chris,

No, clink_start.cmd file is not blocked. It was not downloaded, I've created the file on my PC in onedrive folder.

[chrisant996]

Interesting. I've tried to reproduce the problem, but I can't -- when I try, clink_start.cmd files are run as expected from all of the possible locations (binaries dir, default profile dir, custom profile dir, or both binaries dir and profile dir).

Does it make a difference if there's a clink_start.cmd file in the binaries directory as well?

What are the contents of each of the clink_start.cmd files?

What happens if the script includes echo reached here as the first line? Or includes notepad as the first line?

(E.g. to help troubleshoot whether the script might be getting executed but output might be getting redirected somehow)

[chrisant996]

@Rygor83 I see that the profile (state) directory is a custom location, which gave me some further ideas:

• How is the profile directory pointed at the d:\OneDrive\command_line directory?
• What is the output from clink autorun show?

What if the reason d:\onedrive\command_line\clink_start.cmd isn't run is because the profile isn't being pointed to d:\onedrive\command_line until after Clink has already loaded and been initialized?

[Rygor83]

@chrisant996 , sorry for the silence.

• How is the profile directory pointed at the d:\OneDrive\command_line directory?

• What is the output from clink autorun show?

[Rygor83]

Does it make a difference if there's a clink_start.cmd file in the binaries directory as well?

If clink_start.cmd is only in profile directory - nothing happens,
if clink_start.cmd is both in profile and binaries directories - then it is executed.

What are the contents of each of the clink_start.cmd files?

chcp 65001

What happens if the script includes echo reached here as the first line? Or includes notepad as the first line?

If clink_start.cmd is only in profile directory - nothing happens,
if clink_start.cmd is both in profile and binaries directories - then every command is executed: echo reached here / notepad

[chrisant996]

I found a way to reproduce the issue, and tracked down the problems (there's more than one, which is why it was hard to figure out what was happening).

Analysis

If you press Ctrl-X,Ctrl-Z then Clink will report its internal info directly (versus launching a separate clink_x64.exe which has to backtrack to find the Clink session it's associated with and then extract info from it).

Doing that reports that the profile (state) directory is "c:\users{current_user}\appdata\local\clink". Which comes from the Autorun command having explicitly set it to that.

It turns out that CLINK_PROFILE is only used if the profile directory has not been set at all by any other mechanism yet. It was documented as "takes precedence over any other mechanism", but a change in 2016 accidentally broke that.

And that's also why clink info reports a different profile directory than is actually being used:

• When Clink was injected, the autorun command specified a profile directory explicitly.
• When clink info is used, it does not specify a profile directory explicitly. And then the bug in the precedence logic for CLINK_PROFILE isn't hit, and so it comes up with the expected profile directory ... although that isn't the actual profile directory being used by the associated Clink session. (Sheesh.)

The change that broke it

On 2016/09/15 Martin made the following change:

app_context.cpp

@@  -32,8  +32,11  @@
     // The environment variable 'clink_profile' overrides all other state
     // path mechanisms.
-    if (!os::get_env("clink_profile", state_dir))
-        if (state_dir.empty())
+    if (state_dir.empty())
+        os::get_env("clink_profile", state_dir);
+
+    // Look for a state directory that's been inherited in out environment.
+    if (state_dir.empty())
-            load_from_env();
+        load_from_env();
 
     // Still no state directory set? Derive one.
     if (state_dir.empty())

Notice the comment didn't change and still says "clink_profile overrides all other state path mechanisms".

But the functionality changed: it made clink_profile be used only when a profile directory hasn't been specified by any other mechanisms.

The description of the commit is "State dir that's set externally should trump all.", but that's not how it actually behaves.

(The original logic wasn't correct either; it had a different flaw. The good news is I see how to solve both flaws.)

Conclusions

1. I'll fix the precedence of CLINK_PROFILE.
2. I'll confirm that fixing it solves both problems.
   • Uses the CLINK_PROFILE directory as the profile directory in the Clink session.
   • Enables the clink info to accurately report the profile directory.

[chrisant996]

The fix is available in v1.4.6.