Wait for a process to complete in Cmder \ ConEmu

Question

Executive Summary:

For software development debugging purposes, I’m using Cmder 1.3.12 for Windows 10 x64.

If, say, I run in a cmd window java –jar app2.jar, I get output logs (inside cmd) and, as expected, the cmd prompt will only become available when my java process terminates. This is working fine, not only from the command-line but also from inside my calling app (also a java app, let us call it “app1”).

But what I really want is to have a console emulator (I’m using Cmder) where I run my script/app in. This way, I get features cmd cannot give me, such as larger lines buffer, colored logs (ANSI red colors to clearly show eventual exceptions), multiple tabs and even support for my bash scripts (besides showing my (colored) app logs, it also redirect stdout and stderr to a single log file - for later usage).

However, if I run cmder /TASK mytask (which, basically, runs java –jar app2.jar) in a cmd window, though it runs smoothly namely by showing my logs inside the featured console, the cmd prompt will immediately become available. Even before the app2 process terminates. A similar behavior is found if I run cmder /TASK mytask from inside my app1.

And this is the problem: I need app2 process to complete before control is returned to app1. Never before!

Seems to me that, somewhere along the Cmder bundle, there’s some kind of stub which launches an application and then immediately exits… Any ideas how to solve this? Thanks!

>

Details:

I’ve done some digging… mytask is a ConEmu bash task: {bash::mytask} (same as default {bash::bash}, using customized %cmder_home%\config\user_profile.sh) which - basically - runs app2 inside Cmder.

For testing purposes, instead of directly calling Cmder, I tried some windows shell instructions which I believe to wait for its command argument to complete before the control returns back to the calling app (besides running them from my “app1”, I also tried running them in a cmd window):

start /w Cmder /TASK mytask

call "Cmder" /TASK mytask

cmd /c Cmder /TASK mytask

The same (undesirable) results.

Knowing that Cmder is, basically, a bundle of software packages, I continued my investigation:

ConEmu -run {mytask}

ConEmu -run "java -jar HelloWorld.jar"

I even tried, like before, calling ConEmu with some shell waiting instructions, such as “start /w”. Still same (undesirable) results!

Finally, I looked over ConEmu Settings for task specific (default) command:

cmd /c ""%ConEmuDir%..\git-for-windows\bin\bash" --login -i"

Well, bash interactive shells (-i) is not exactly my expertise, so I didn’t try to mess around with additional bash commands\arguments. Instead, I tried something else (by replacing the entire default command):

start /w "" "%ConEmuDir%..\git-for-windows\bin\bash" --login –i

call "%ConEmuDir%..\git-for-windows\bin\bash" --login –i

START /w "mytitle" cmd /c java -jar HelloWorld.jar

java -jar ./HelloWorld.jar

Also tried unchecking Process ‘start’ from ConEmu Settings Features page (default is checked).

Nothing really worked... Seems to me that, somewhere along the Cmder bundle, there’s some kind of stub which launches an application and then immediately exits… Any ideas how to solve this? Thanks!

EDIT:

%cmder_home%\config\user_profile.sh:

debug_red()(set -o pipefail;"$@" 2>&1>&3|sed $'s,.*,\e[31m&\e[m,'>&2)3>&1

debug_red "./$CTRL_App_loader_script_name.sh" 2>&1| tee $LOGNAME

These, basically, adds ansi red codes if output comes from stderr and then redirects both stdout and stderr to same $LOGNAME logfile.

$CTRL_App_loader_script_name.sh

EXEC_COMMAND="java -Djava.library.path="libs/" -jar CTRL_SENSOR22.jar"

$EXEC_COMMAND

Fixed name and location script. This is created on-the-fly by app1 and just runs my app2.

Answer 1

Oddly enough, in order to keep blocked my calling app1 while called app2 is still running "inside" Cmder\ConEmu, Single instance mode ConEmu setting has to be unset.

Single instance mode setting can be found in the Appearance group window of ConEmu settings (Cmder version 1.3.12.915, Windows 10 x64) and is described there as "use existing window instead of running new instance".

The fact was that, in order to limit the number of log windows showed in my Windows task bar, I had changed the default (which is unset ;-)). I'm sure you all agree that this setting could hardly be considered a suspect for this case...

Moreover, one should also take notice if Close ConEmu with last tab is set (Task bar group window of ConEmu settings). If it isn't, when app2 eventually stops running, app1 will still be kept blocked and the only way to unblock app1 is to manually close that ConEmu window.

Anyway, I would like to thank everyone who took their time reading this question in the hope of being able to help me!

Hope these finds may help someone in the future.