git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Git Bash Bug
@ 2017-07-14 13:43 Kavita Desai
  2017-07-14 14:28 ` Johannes Schindelin
  0 siblings, 1 reply; 12+ messages in thread
From: Kavita Desai @ 2017-07-14 13:43 UTC (permalink / raw)
  To: git

Hello,

Originally, when I first had Git Bash everything was working
perfectly. Randomly one day, my bash commands were not working. I
uninstalled Git Bash an reinstalled it. I have been trying for 3 weeks
to get it to work again. I am working on Windows 10.  I have tried
editing the PATH variables and the PATH environment variables and
nothing seems to be working. Do you have any other suggestions?



Thank you,

Kavita

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Git Bash Bug
  2017-07-14 13:43 Git Bash Bug Kavita Desai
@ 2017-07-14 14:28 ` Johannes Schindelin
  2017-07-14 14:34   ` Kavita Desai
  0 siblings, 1 reply; 12+ messages in thread
From: Johannes Schindelin @ 2017-07-14 14:28 UTC (permalink / raw)
  To: Kavita Desai; +Cc: git

Hi Kavita,

On Fri, 14 Jul 2017, Kavita Desai wrote:

> Originally, when I first had Git Bash everything was working
> perfectly. Randomly one day, my bash commands were not working.

There are a gazillion ways how commands can "not work". You *need* to be
more specific here. In the least, a precise pasted output of a failed
command is necessary.

In addition, a couple of other points of interest would be good to know,
the issue reporting template at
https://github.com/git-for-windows/git/issues/new tries to help you
provide as much important information as you can. Maybe give it a try?

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Git Bash Bug
  2017-07-14 14:28 ` Johannes Schindelin
@ 2017-07-14 14:34   ` Kavita Desai
  2017-07-14 14:37     ` Paul Smith
  0 siblings, 1 reply; 12+ messages in thread
From: Kavita Desai @ 2017-07-14 14:34 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

Sorry for not being specific. What I meant by not working was that the
bash commands are not found.
Here is an example

$ ls
bash: ls: command not found

Kavita

On Fri, Jul 14, 2017 at 9:28 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Kavita,
>
> On Fri, 14 Jul 2017, Kavita Desai wrote:
>
>> Originally, when I first had Git Bash everything was working
>> perfectly. Randomly one day, my bash commands were not working.
>
> There are a gazillion ways how commands can "not work". You *need* to be
> more specific here. In the least, a precise pasted output of a failed
> command is necessary.
>
> In addition, a couple of other points of interest would be good to know,
> the issue reporting template at
> https://github.com/git-for-windows/git/issues/new tries to help you
> provide as much important information as you can. Maybe give it a try?
>
> Ciao,
> Johannes



-- 
Kavita Desai
UIUC Engineering Physics 2018
Engineering Outreach Society Engineering Open House Chair
UIUC Housing Ike. South Front Desk Clerk

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Git Bash Bug
  2017-07-14 14:34   ` Kavita Desai
@ 2017-07-14 14:37     ` Paul Smith
  2017-07-14 14:59       ` Kavita Desai
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Smith @ 2017-07-14 14:37 UTC (permalink / raw)
  To: Kavita Desai, Johannes Schindelin; +Cc: git

On Fri, 2017-07-14 at 09:34 -0500, Kavita Desai wrote:
> Sorry for not being specific. What I meant by not working was that the
> bash commands are not found.
> Here is an example
> 
> $ ls
> bash: ls: command not found

The most obvious issue is your PATH is wrong.

What does "echo $PATH" show?

What does "type -a ls" show?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Git Bash Bug
  2017-07-14 14:37     ` Paul Smith
@ 2017-07-14 14:59       ` Kavita Desai
  2017-07-14 15:03         ` Paul Smith
  0 siblings, 1 reply; 12+ messages in thread
From: Kavita Desai @ 2017-07-14 14:59 UTC (permalink / raw)
  To: paul; +Cc: Johannes Schindelin, git

Here are the results.

What does "echo $PATH" show?
/c/Users/Kavita/

What does "type -a ls" show?
ls is aliased to `ls -F --color=auto --show-control-chars'



On Fri, Jul 14, 2017 at 9:37 AM, Paul Smith <paul@mad-scientist.net> wrote:
> On Fri, 2017-07-14 at 09:34 -0500, Kavita Desai wrote:
>> Sorry for not being specific. What I meant by not working was that the
>> bash commands are not found.
>> Here is an example
>>
>> $ ls
>> bash: ls: command not found
>
> The most obvious issue is your PATH is wrong.
>
> What does "echo $PATH" show?
>
> What does "type -a ls" show?



-- 
Kavita Desai
UIUC Engineering Physics 2018
Engineering Outreach Society Engineering Open House Chair
UIUC Housing Ike. South Front Desk Clerk

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Git Bash Bug
  2017-07-14 14:59       ` Kavita Desai
@ 2017-07-14 15:03         ` Paul Smith
  2017-07-14 20:33           ` Johannes Schindelin
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Smith @ 2017-07-14 15:03 UTC (permalink / raw)
  To: Kavita Desai; +Cc: Johannes Schindelin, git

On Fri, 2017-07-14 at 09:59 -0500, Kavita Desai wrote:
> What does "echo $PATH" show?
> /c/Users/Kavita/

Well, there you go.  That's clearly wrong.

You absolutely have to have /bin and /usr/bin on your PATH, _at least_
if you want to be able to run standard UNIX tools.  And most likely
you'll have a ton of other directories on your PATH as well.

I would investigate the shell configuration files etc. and see where
you've messed up resetting your PATH variable.

> What does "type -a ls" show?
> ls is aliased to `ls -F --color=auto --show-control-chars'

Yep.  There is no ls binary found.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Git Bash Bug
  2017-07-14 15:03         ` Paul Smith
@ 2017-07-14 20:33           ` Johannes Schindelin
  2017-07-14 21:12             ` Paul Smith
  0 siblings, 1 reply; 12+ messages in thread
From: Johannes Schindelin @ 2017-07-14 20:33 UTC (permalink / raw)
  To: Paul Smith; +Cc: Kavita Desai, git

Hi,

On Fri, 14 Jul 2017, Paul Smith wrote:

> On Fri, 2017-07-14 at 09:59 -0500, Kavita Desai wrote:
> > What does "echo $PATH" show?
> > /c/Users/Kavita/
> 
> Well, there you go.  That's clearly wrong.
> 
> You absolutely have to have /bin and /usr/bin on your PATH,

As Kavita talks about Git Bash, it is probably Git for Windows, for which
/bin should not be in the PATH but /mingw64/bin or /mingw32/bin (depending
on the architecture).

It may be messed up by some strange setting in the User Environment. Go to
the Windows Explorer, right-click on "This PC", select "Properties", in
the newly-opened window ("Control Panel>All Control Panel Items>System"),
next to the "Computer name, domain, and workgroup settings" select "Change
settings" which brings up the "System Properties" window, in whose
"Advanced" tab is an "Environment Variables" button.

(Or hit the Windows key, type "Edit the system environment variables")

You should find the "Path" variable at least in the System variables. It
is case-insensitive, so if your User variables contain, say, an empty
value for a key "paTH", then the riddle is solved.

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Git Bash Bug
  2017-07-14 20:33           ` Johannes Schindelin
@ 2017-07-14 21:12             ` Paul Smith
  2017-07-14 21:52               ` Johannes Schindelin
  0 siblings, 1 reply; 12+ messages in thread
From: Paul Smith @ 2017-07-14 21:12 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Kavita Desai, git

On Fri, 2017-07-14 at 22:33 +0200, Johannes Schindelin wrote:
> > You absolutely have to have /bin and /usr/bin on your PATH,
> 
> As Kavita talks about Git Bash, it is probably Git for Windows, for
> which /bin should not be in the PATH but /mingw64/bin or /mingw32/bin
> (depending on the architecture).

I did check this with my Git for Windows installation before posting. 
Mine is older (2.7.0) though so maybe things have changed:

  pds@build-win MINGW64 ~
  $ type -a ls
  ls is aliased to `ls -F --color=auto --show-control-chars'
  ls is /usr/bin/ls
  ls is /bin/ls
  ls is /usr/bin/ls
  ls is /usr/bin/ls

Clearly I have a lot of duplicates on my PATH now that I notice :)

I have /mingw64/bin on my PATH as well but looking there it has git,
gettext, edit, a bunch of DLL's, etc. but it doesn't contain ls or
other coreutils programs.

Cheers!

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Git Bash Bug
  2017-07-14 21:12             ` Paul Smith
@ 2017-07-14 21:52               ` Johannes Schindelin
  0 siblings, 0 replies; 12+ messages in thread
From: Johannes Schindelin @ 2017-07-14 21:52 UTC (permalink / raw)
  To: Paul Smith; +Cc: Kavita Desai, git

Hi Paul,

On Fri, 14 Jul 2017, Paul Smith wrote:

> On Fri, 2017-07-14 at 22:33 +0200, Johannes Schindelin wrote:
> > > You absolutely have to have /bin and /usr/bin on your PATH,
> > 
> > As Kavita talks about Git Bash, it is probably Git for Windows, for
> > which /bin should not be in the PATH but /mingw64/bin or /mingw32/bin
> > (depending on the architecture).
> 
> I did check this with my Git for Windows installation before posting. 
> Mine is older (2.7.0) though so maybe things have changed:
> 
>   pds@build-win MINGW64 ~
>   $ type -a ls
>   ls is aliased to `ls -F --color=auto --show-control-chars'
>   ls is /usr/bin/ls
>   ls is /bin/ls
>   ls is /usr/bin/ls
>   ls is /usr/bin/ls

Oh wow ;-)

For the record, /bin/ is simply mapped to /usr/bin/. They are not
different directories, really.

> Clearly I have a lot of duplicates on my PATH now that I notice :)

;-)

> I have /mingw64/bin on my PATH as well but looking there it has git,
> gettext, edit, a bunch of DLL's, etc. but it doesn't contain ls or
> other coreutils programs.

Right. The difference between executables in /mingw64/bin/ and in
/usr/bin/ is that the latter executables all implicitly link to
msys-2.0.dll, i.e. the POSIX emulation layer based on Cygwin. As you
probably guessed: the coreutils are all compiled using that POSIX
emulation layer.

Ciao,
Johannes

^ permalink raw reply	[flat|nested] 12+ messages in thread

* git bash bug
@ 2025-07-09 17:20 Preston, David J.
  2025-07-09 22:47 ` brian m. carlson
  2025-07-11 14:40 ` Johannes Schindelin
  0 siblings, 2 replies; 12+ messages in thread
From: Preston, David J. @ 2025-07-09 17:20 UTC (permalink / raw)
  To: git@vger.kernel.org


[-- Attachment #1.1: Type: text/plain, Size: 22 bytes --]

Bug report attached.

[-- Attachment #1.2: Type: text/html, Size: 1464 bytes --]

[-- Attachment #2: git-bugreport-2025-07-09-1206.txt --]
[-- Type: text/plain, Size: 1723 bytes --]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
started happening after an update to a newer version of git... has been happening for a while, so i am not sure what version it started with

What did you expect to happen? (Expected behavior)
when using git bash in windows environment, when a previously typed command is executing and i start typing, i expect that what i type will eventually show up on the command line, in the order i typed it, once the executing command completes.

What happened instead? (Actual behavior)
letters that i have typed show up in a different order than i typed them.  basically, i think there is some async processing going on, and keyboard input is being handled in such a way that the keystrokes are output to the console in an order that is random based on race conditions in the async code.

What's different between what you expected and what actually happened?
keys output in a different order than i typed them in.

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.49.0.windows.1
cpu: x86_64
built from commit: cca1f38702730b35f52c29efd62864b85e85ddcc
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.12.1
OpenSSL: OpenSSL 3.2.4 11 Feb 2025
zlib: 1.3.1
uname: Windows 10.0 22631 
compiler info: gnuc: 14.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe


[Enabled Hooks]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: git bash bug
  2025-07-09 17:20 git bash bug Preston, David J.
@ 2025-07-09 22:47 ` brian m. carlson
  2025-07-11 14:40 ` Johannes Schindelin
  1 sibling, 0 replies; 12+ messages in thread
From: brian m. carlson @ 2025-07-09 22:47 UTC (permalink / raw)
  To: Preston, David J.; +Cc: git@vger.kernel.org

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

On 2025-07-09 at 17:20:22, Preston, David J. wrote:

Hi,

> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
> 
> What did you do before the bug happened? (Steps to reproduce your issue)
> started happening after an update to a newer version of git... has been happening for a while, so i am not sure what version it started with
> 
> What did you expect to happen? (Expected behavior)
> when using git bash in windows environment, when a previously typed command is executing and i start typing, i expect that what i type will eventually show up on the command line, in the order i typed it, once the executing command completes.

The Git project doesn't ship bash, a terminal, or any software other
than the source code to Git.  Git Bash is part of Git for Windows, which
is a separate project.  You may want to report this https://github.com/git-for-windows/git/issues.

I would recommend searching for any relevant issues, open or closed,
first and providing any information that might be relevant.  For
instance, does this problem only occur when the system is loaded or does
it happen all the time, even with little load?  Is there anything else
going on that is correlated with the problem (e.g., a virus scan)?  Does
the same thing happen when running Git for Windows's bash through
Windows Terminal, or is it only the built-in MinTTY?  Those kinds of
things might help the maintainer solve the problem more quickly.

Best of luck on this.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: git bash bug
  2025-07-09 17:20 git bash bug Preston, David J.
  2025-07-09 22:47 ` brian m. carlson
@ 2025-07-11 14:40 ` Johannes Schindelin
  1 sibling, 0 replies; 12+ messages in thread
From: Johannes Schindelin @ 2025-07-11 14:40 UTC (permalink / raw)
  To: Preston, David J.; +Cc: git@vger.kernel.org

Hi David,

On Wed, 9 Jul 2025, Preston, David J. wrote:

> What did you do before the bug happened? (Steps to reproduce your issue)
> started happening after an update to a newer version of git... has been
> happening for a while, so i am not sure what version it started with
>
> What did you expect to happen? (Expected behavior)
> when using git bash in windows environment, when a previously typed
> command is executing and i start typing, i expect that what i type will
> eventually show up on the command line, in the order i typed it, once
> the executing command completes.
>
> What happened instead? (Actual behavior)
> letters that i have typed show up in a different order than i typed
> them.  basically, i think there is some async processing going on, and
> keyboard input is being handled in such a way that the keystrokes are
> output to the console in an order that is random based on race
> conditions in the async code.
>
> What's different between what you expected and what actually happened?
> keys output in a different order than i typed them in.

This is essentially the same issue that has been reported at
https://github.com/git-for-windows/git/issues/5632.

The problem is in the MSYS2 runtime, which is the POSIX emulation layer
required to run Bash that Git for Windows employed, which in turn is a
friendly fork of the Cygwin runtime.

I haven't had time to report this bug over in Cygwin yet (for which I
would have to verify that this bug reproduces with their own Bash running
in their own MinTTY). Maybe you can help out and install Cygwin
(https://cygwin.com) and perform that test?

Thanks,
Johannes

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2025-07-11 14:40 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-14 13:43 Git Bash Bug Kavita Desai
2017-07-14 14:28 ` Johannes Schindelin
2017-07-14 14:34   ` Kavita Desai
2017-07-14 14:37     ` Paul Smith
2017-07-14 14:59       ` Kavita Desai
2017-07-14 15:03         ` Paul Smith
2017-07-14 20:33           ` Johannes Schindelin
2017-07-14 21:12             ` Paul Smith
2017-07-14 21:52               ` Johannes Schindelin
  -- strict thread matches above, loose matches on Subject: below --
2025-07-09 17:20 git bash bug Preston, David J.
2025-07-09 22:47 ` brian m. carlson
2025-07-11 14:40 ` Johannes Schindelin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).