\clink\clink.bat" inject " unexpected at this moment about clink HOT 16 CLOSED

There's a superfluous double quote in clink.bat line 34. I removed it and it works.

Before:

    start "Clink" cmd.exe /s /k ""%~dpnx0" inject %clink_profile_arg%%clink_quiet_arg%"

After:

    start "Clink" cmd.exe /s /k "%~dpnx0" inject %clink_profile_arg%%clink_quiet_arg%"

from clink.

Can you try the following clink.bat file instead?

EDIT: removed; use updated Clink instead.

from clink.

Well, I've done enough cmd to not dare to try doing what clink.bat does. If you run this .bat in a regular directory:

(
    echo Hello, %~p0!
)

it works as expected. But copy it to c:\Program Files (x86)\clink and the mysterious message appears. It's only the ~p part that does it, so it's probably the closing brace after x86 that gets misinterpreted.

PS Actually, you just need to rename your working directory to so that it contains a closing brace - there's no different interpreter for scripts under c:\Program Files. Well, at least this example doesn't demonstrate that.

from clink.

Happens to me as well on both W10/W11 x64 in cmd shell. PowerShell seems unaffected.

from clink.

Latest update clink.1.6.7.87398b breaks clink, had to rollback to clink.1.6.6.87eebc When running either via clink.bat or the injected cmd, it throws this error on title.

@alfablac Thanks for reporting this.

I am completely unable to reproduce the problem.
It seems there must be more to it than just running clink.bat -- maybe there is some Windows configuration that matters as well.

There's a superfluous double quote in clink.bat line 34.

@vii1 Count the quotes carefully. It's not superfluous, and it didn't change.

What changed is the line got moved inside a ( .. ) pair.
Apparently, that is changing how CMD parses the quotes, but only on some computers.

Strangely, I cannot reproduce the problem at all (which is how the problem got published).

Happens to me as well on both W10/W11 x64 in cmd shell. PowerShell seems unaffected.

@rybnicek Yes, it's expected that PowerShell would be unaffected by anything in Clink, because Clink has nothing to do with PowerShell.

from clink.

@vii1 Count the quotes carefully. It's not superfluous, and it didn't change.

You're right. In fact my attempt broke running from the start menu icon. I tried escaping the inner quotes with ^" and it fixes autoinject but running from icon shows "The system cannot find the specified path" (but runs Clink anyway)

from clink.

I can't reproduce the problem as described, but I think I see what's causing it.
It looks like the described repro steps are either ambiguous or not quite accurate.

from clink.

I can reproduce a little different error when running clink.bat startmenu or when double clicking on the Clink.lnk in the Start Menu after using the setup exe installer.

Those aren't the same as "running either via clink.bat or the injected cmd", so maybe the described repro steps were phrased ambiguously?

I have a fix, though.

from clink.

Can you try the following clink.bat file instead?

[ removed the quoted test bat file so no one tries to use it; use v1.6.8 instead ]

I just installed clink and encountered the same issue. I tried this clink.bat and it works fine now.

from clink.

@mkurup27 Don't use that clink.bat. It solves one problem but causes another under other circumstances. v1.6.8 is coming in a few minutes.

from clink.

I saw it too and 1.6.8 fixes it, so I'm good. But FYI: I never "run" clink, know about clink.bat or configured anything; I just run the installer and open up a console (or run cmd.exe). So I wonder what the circumstances are: is there something peculiar about my registry or settings:? I don't see anything extraordinary in %HOME%\AppData\Local\clink\clink_settings.

from clink.

@ssomers I don't know, and the mystery is annoying me. I was able to reproduce a different variation of the problem, and that enabled me to verify a fix. But I'm completely unable to reproduce the described problem on W10 or W11 (x64 on both). Even setting up AutoRun for Clink doesn't reproduce it.

But the underlying problem was I had broken subtle cooperation between shift and call in the script. If any of the if conditions in the clink.bat file end up running shift, then the later %~dp0 usages don't refer to the batch script name. The call :launch is important because a side effect of call is that %0 gets reset to be the batch script name again despite any preceding shift.

And in fact there is still a problem with that: running clink --profile c:\temp\test_profile inject fails (with a different error message). But that problem has existed since before I got involved with Clink at all -- it even exists in Clink v0.4.9.

The part I don't understand is how people were hitting this shift-related problem when using a syntax that doesn't run any of the shift commands? Maybe the executed command wasn't literally clink.bat or clink inject, or maybe there is some other system level configuration (not Clink configuration) that is somehow relevant, or maybe there were two separate problems (but then why couldn't I reproduce it?).

from clink.

Well, I've done enough cmd to not dare to try doing what clink.bat does. If you run this .bat in a regular directory:

(
    echo Hello, %~p0!
)

it works as expected. But copy it to c:\Program Files (x86)\clink and the mysterious message appears. It's only the ~p part that does it, so it's probably the closing brace after x86 that gets misinterpreted.

Ah! Mystery solved! Thanks for sharing the observation.

There were two problems.

1. The cooperation between shift and call.
2. The use of (..) combined with the Clink program directory being under Program Files (x86) AND the (correct and necessary) use of "" before the %~dp0, which has a side effect of preventing CMD from treating the embedded ) as being quoted in the first parsing pass.

Mine is under c:\wbin\clink, thus I could not reproduce the problem.

from clink.

The clink.bat implementation is juggling many syntax and chipset and performance (speed) details all at once. It's indeed challenging to keep all of them working in proper harmony.

from clink.

@chrisant996, thanks for the heads-up. It has been working fine for me but I've installed the latest version anyways. Thanks!

from clink.

I just noticed the update and I forgot I reported this. haha Thanks for fixing it @chrisant996 !!

from clink.