On Thu, 15 Jan 2009, Robin Rosenberg wrote:
> > Better yet, change the windows properties to enable quick edit. Then
> > you can paste with just right-click.
BTW this is something that bothered me forever with the stupid, stupid
Windows console.
However,
http://code.google.com/p/msysgit/issues/detail?id=29&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
(Issue 29: Change to another more user-friendly terminal) seems to be
dead in the water. I once had high hopes, but it seems that Windows
people are less enthusiastic than necessary to get stuff done.
Ciao,
Dscho
On Sun, 18 Jan 2009, namin wrote:
>
> Thanks, that's good to know. So, it's not an easy task to add copy-
> paste support in terms of Cltr-C/Cltr-V ?
Two things:
- please do not top-post,
- direct this issue to Microsoft Support, as it has nothing to do with Git
Bash, but all with cmd.exe.
Ciao,
Dscho
Actually, the Windows console window has nothing to do with cmd.exe
as well, it is managed by a core system service called csrss.exe:
http://blogs.msdn.com/oldnewthing/archive/2007/12/31/6909007.aspx
It also somewhat explains the difficulty of replacing the console
with a different application: unlike ptys in Linux there is no
generic interface for it, the console functionality is hardwired
into the system. Cygwin probably has some kind of pty emulation
in its runtime, but that won't work for native applications.
Alexander
On Mon, 19 Jan 2009, Alexander Gavrilov wrote:
> Actually, the Windows console window has nothing to do with cmd.exe
That must be the reason why we call "cmd.exe /c bash --login -i" to get
the console window.
Ciao,
Dscho
Johannes Schindelin schrieb:
Nope. A console application on Windows will create its own console
window, should it not inherit one from its parent.
You'll see that if you hit WindowsKey+R, and try to start bash from
there. The console window appears with no cmd.exe parent process.
I'm not sure why the "cmd.exe /c" was prepended, but it must be for
some other reason.
--
.marius
Did you try checking the properties for the relevant windows? On my
system the GIT Bash shortcut had Quick Edit disabled. After I enabled
it, it worked without any problems.
Alexander
The CreateProcess API call allows specifying flags to suppress the
console window of the child process. Using cmd as an intermediate step
allows overriding it in some cases.
For example, if you simply add {sh.exe --login -i} as a command to the
new Tools menu of git-gui, it won't work, because bash would try to
use its stdin/stdout for I/O, which are in this case connected to
git-gui via pipes. As a result, it would print the first prompt, and
immediately quit because of EOF on stdin.
On the other hand, {cmd //c "start sh.exe --login -i"} (note the //,
it is necessary) would create a new console window and run bash there.
However, the only role cmd plays here is passing appropriate flags to
the system when starting sh.exe.
Alexander
On Mon, 19 Jan 2009, Steve Wagner wrote:
> No i think this is not a bug of windows console. I can simply do a right
> click to paste my actually clipboard to a normal console window (with
> quick edit mode enabled). It only dose not works when using bash (cygwin
> and msys).
Steve, please do not top-post. It is outright annoying.
And further, the thing with the Windows console is that you _have_ to
enable the quick edit. It is not enabled by default.
Ciao,
Dscho