cmderdev/cmder

[Bug] 'git --version' returned an improper version string

petercao opened this issue · 19 comments

Version Information

Cmder version: newest
Operating system: win10

Cmder Edition

Cmder Full (with Git)

Description of the issue

Every launch of my cmder, it always print below msg:

Active code page: 65001
"'git --version' returned an improper version string"
Press any key to continue . . .

And I want to know if there some kind of terminal available on ArchLinux?
I just want to copy, paste using left/right click of my mouse?
or some shortkey, like ctrl +c / ctrl +v ?

Checklist

  • I have read the documentation.
  • I have searched for similar issues and found none that describe my issue.
  • I have reproduced the issue on the latest version of Cmder.
  • I am certain my issues are not related to ConEmu, Clink, or other third-party tools that Cmder uses.

@petercao Please type this in your Cmder terminal and then send us an screenshot:
git --version

Please, type cmd then type:
where git

You will see a list of git.exe files, then for each of them, run it with the --version switch.

Please attach a screenshot of all of them, thank you.

According to a GitHub search, neither Cmder nor ConEmu contain the word "improper".

Maybe this is completely unrelated to Cmder.

Look for other scripts that are being run.

@chrisant996

echo "'git --version' returned an improper version string!"

I wrote the script back in 2018, don't know why the search is not returning it

@petercao Firstly I apologize for this issue, I wonder exactly what is causing this.

Please follow these steps to update the affected component of Cmder and help us solve the issue:

  1. Open the following link and copy the entire file:
    https://raw.githubusercontent.com/cmderdev/cmder/master/vendor/lib/lib_git.cmd
  2. Open the following file in your Cmder folder: vendor\lib\lib_git.cmd, delete all lines, then paste the content from the first link
  3. Now, close all Cmder windows
  4. Open conhost.exe
  5. Type the following command, change the %CMDER_ROOT% to your actual folder
    "%cmder_root%\vendor\bin\cmder_shell.cmd" /d
  6. You shall see something like the image below, copy everything and paste it as .txt file, send us the file on GitHub
    image

Again I am sorry for this problem, but these steps will help us understand and solve this issue.

Please type this and post a screenshot:
set cmder_root

And please edit the cmder_shell.cmd using notepad, change echo off to echo on, then run again and send a screenshot

Thank you

always print as follow:
image

Please apply step 1 and step 4 from the link here:
https://github.com/cmderdev/cmder/wiki/Setting-up-Environment-Variables

Make sure to keep @echo on in the batch file as before.

Then, open conhost.exe and run this again:

"%cmder_root%\vendor\bin\cmder_shell.cmd" /d

Then, please send a screenshot again. Thank you.

@DRSDavidSoft Just curious but why are we instructing users to set cmder_root outside cmder?

This is not required for normal function.

Every script we provide to initialize cmder does this automatically for the running session.

@daxgames That's just for the debugging purposes according to what I see on the screenshots;

I'm not sure why the cmder_shell.cmd is apparently not setting the %cmder_root% variable on his machine (according to the screenshots) and/or returning such an error, what I'm trying to do is to make sure this variable is pre-set before the script is run, and also to make sure the echo is on so there is some useful debugging output on the terminal that I can use to better understand the problem.

Since each reply takes a couple of hours to troubleshoot the issue, I'm trying to reduce any un-important problem factors to debug the actual issue quicker.

@daxgames Sidenote, what is the preferred way to launch Cmder in debugging mode, I think it's best to add an entry for that to the wiki. It should also be terminal-agnostic.

@daxgames That's just for the debugging purposes according to what I see on the screenshots;

OK

I'm not sure why the cmder_shell.cmd is apparently not setting the %cmder_root% variable on his machine (according to the screenshots) and/or returning such an error,

Dunno works on my system:

image

@daxgames Sidenote, what is the preferred way to launch Cmder in debugging mode, I think it's best to add an entry for that to the wiki. It should also be terminal-agnostic.

The only shell that really has any debugging support is cmd.exe initialized by init.bat /d so editing a Conemu task as follows:

image

But that debug is severely limited if the speed optimized %cmder_root%\config\user_init.cmd exists so deleting this file will increase debug output for a single run.

There are various debug scripts that provide info about the users env and are cmder shell specific:

~\cmderdev (development-dax -> origin) λ dir vendor\bin\*_diag.*
 Volume in drive D is UserProfile
 Volume Serial Number is AAE8-A44A

 Directory of D:\Users\296951\cmderdev\vendor\bin

01/19/2024  02:18 PM             1,735 cmder_diag.cmd
05/30/2023  11:26 AM             1,981 cmder_diag.ps1
05/30/2023  11:26 AM             1,534 cmder_diag.sh

Maybe a user script is resetting some environment variables.

Especially if a user script contains setlocal.

Hello guys, I just downloaded the archive and launched it on my system for the first time and I got the same error and some more.
I am happy to invite you to a remote session.

Windows 10 Pro, 10.0.19045 Build 19045

"'git --version' returned an improper version string"
Press any key to continue . . .
"'git --version' returned an improper version string"
Press any key to continue . . .
'"C:\Users\Qwerty\cmd\cmder\config\profile.d\Invalid"' is not recognized as an internal or external command,
operable program or batch file.
The filename, directory name, or volume label syntax is incorrect.
λ where git
C:\Program Files\Git\cmd\git.exe
C:\Program Files\Git\mingw64\bin\git.exe

λ "C:\Program Files\Git\cmd\git.exe" --version
git version 2.37.3.windows.1

λ "C:\Program Files\Git\mingw64\bin\git.exe" --version
git version 2.37.3.windows.1

@ackvf Thanks for the information you provided, firstly I will check the values with our codebase.

If that doesn't work, I'm sure a remote session would be super useful, so thank you for reporting the returned values and the help with fixing this bug 😄