| Summary: | --block doesn't work | ||
|---|---|---|---|
| Product: | [Applications] kate | Reporter: | Jesper Pedersen <blackie> |
| Component: | application | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | kare.sars |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Jesper Pedersen
2017-04-05 06:59:51 UTC
Hmm... is that a Windows "feature"... A bit of Googling found: "c:\Program Files\Kate\bin\kate.exe" | rem does this do the trick or have I missed something? I can start kate just fine. When I do so on windows, "kate --block" should prevent kate from going into the background, but it doesn't In linux terms. "kate --block" on windows would be equal to "kate", while it really behaves like "kate &" Cheers I think the problem is that having a GUI applicaton on Windows implicitly means a virtual & at the end. Adding "| rem" after the command works like removing the & on Linux (except you don't get stderr output). --block is for when you have an instance already running and don't want to exit the new instance until the old instance (that actually opens the provided file) exits. On Windows the new instance does not exit, but you don't notice it since the "wise" shell automatically adds a virtual '2> /dev/null &' to all GUI applications ;) Adding "| rem" is a workaround, but I think we would need a patch/volunteer to dig into the gory details of what special functions to call on windows to prevent the virtual "...&" but at the same time not always open a teminal-window. |