Skip to content
This repository was archived by the owner on Nov 9, 2017. It is now read-only.

Conversation

@kblees
Copy link
Contributor

@kblees kblees commented Mar 5, 2014

As of PR #11, Git-Cheetah menu commands that were supposed to launch a separate process (such as "Git Bash", "Git GUI") would block the file manager process until the child process exits.

This PR reverts PR #11 and adds an alternate solution to the "Git-Cheetah prints to the console" problem.

kblees added 2 commits March 5, 2014 22:51
This reverts commit f743394.

Most Git-Cheetah commands are expected to launch an independent process,
without blocking the calling file manager application.

Signed-off-by: Karsten Blees <[email protected]>
Git-Cheetah redirects and reads stdout / stderr of forked commands only if
it needs to. Otherwise this output simply goes to stdout / stderr of the
calling file manager process. This is OK for GUI-based file managers (e.g.
Windows Explorer), as there is no console.

For text-based file managers (e.g. Far Manager) this is a problem, as such
unwanted console output messes up the UI.

Redirect stdout / stderr of forked commands to /dev/null if Git-Cheetah
doesn't need it.

Signed-off-by: Karsten Blees <[email protected]>
@dscho
Copy link
Member

dscho commented Mar 5, 2014

@hvoigt you seemed to be able to reproduce the problem fixed in #11... could you try this patch, please?

@dscho
Copy link
Member

dscho commented Mar 14, 2014

Okay, since nobody chimed in who has a chance to test FarManager I am willing to force them to test by merging this.

@dscho
Copy link
Member

dscho commented Mar 23, 2014

Unfortunately, the FarManager users were not bitten, but the Windows Explorer crowd. Hopefully #15 addresses this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants