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

Fix menu commands blocking the file manager process #14

Merged
merged 2 commits into from
Mar 14, 2014

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.

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 <blees@dcon.de>
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 <blees@dcon.de>
@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