Anyone use ConEmu?

[Duthomhas]

I'm usually pretty comfortable at my default Windows Console (gasp! -- yes, I've got it pretty pimped out), but I recently decided to play with ConEmu.

It's nice.

Except for one thing I can't figure out. I've got a ~\bin directory with useful little batch files to do things (instead of filling my %PATH% with loads of directories), like this one:

~\bin\npp.bat

@"C:\Program Files (x86)\Notepad++\Notepad++" %*

Conveniently, at the command prompt I can type things like

    npp foo.cpp

And I get a copy of Notepad++ running and (this is the important point) I can still use my console.

I can't figure out why ConEmu locks (as if it were Unix locked onto a GUI application's standard I/O streams). I've tried all kinds of variations to starting my process with no results other than outright failure to start the process.

Does anyone know how I can make ConEmu just start the GUI program as a detached task? (The default behavior in Windows.)

[coder777]

Did you try the redirection >? I'd guess that ConEmu knows them too?

See:
http://commandwindows.com/command1.htm

[Maximus5]

I can still use my console.

False, of course.

ConEmu is a terminal. What you have "locked" is a shell (supposing it's a cmd.exe).
So you would get absolutely the same behavior in ConEmu and in the standard Windows console.

Thought, you've started notepad++ before trying that from std.con.

Also, use "start", it is more correct.

[Duthomhas]

Maximus5 wrote:

False, of course.

Boy how I love it when smart people come to explain to me that things I've been doing for thirty years are impossible.

You might consider that I understand more about how the Windows Console window works than you do.

And that the thesis of my post is that I cannot get the same behavior from ConEmu as I do the standard Windows console.

And "start" is not more correct. It is a different way of doing things. Which, by the way, I've tried variations of as well. The "start" command isn't the problem. ConEmu is.

If you want to help, please don't belittle me or explain what I've said is happening cannot.

coder777 wrote:

Did you try the redirection?

I have now, but I didn't expect it to work (which is why I didn't try it before).

The reason a terminal "locks" when you run a process in *nix has less to do with the standard I/O than the fact that the parent process is waiting on the child to terminate. This relationship of child to parent is what you typically call a "foreground" process. A "background" process (started with a trailing ampersand &) causes the parent (shell) to launch the child asynchronously -- meaning it isn't simply waiting for the child to terminate.

In Windows, processes don't actually have parent-child relationships, though the "parent" can still behave in much the same way with respect to "children" it starts.

It seems ConEmu tries to inject every process it runs and parent it in a tab. You can specify "special" command-line arguments to make it (not) do stuff like that, but even in *nix I don't have to type so much junk just to launch a separate process.

And it still doesn't quite behave correctly.

No one has experience with this?

[Maximus5]

Boy, You might consider that ConEmu's author understand more about how the Windows Console window and ConEmu works.

And of course I've checked your cmd file.

What can you do - run ProcessMonitor and ProcessExplorer and check the difference in the created process tree and executed commands.
Well, you haven't said what Windows version you are using, there is a small chance it does matter.
And you haven't told what shell you are using. Cmd.exe is my supposition.

Also, "start" may be synchronous and asynchronous, your cmd-file (at least on my PC) is always synchronous. With only exception if notepad++ is already running (obvious reason).

Here is my screenshot: http://i.imgur.com/2DrjqyY.png
Show yours...

[Duthomhas]

Alright, since you're the author of ConEmu then I concede that you likely have a pretty good idea better how the Windows Console works than I. It doesn't help when you start out by telling me that I can't do something that works (and always has) on the standard console.

(I've spent a lot of time hacking the Windows Console and also maintaining a utility that injects processes to modify environment variables. So I have a pretty good idea how these things work.)

The cmd.exe shell knows to start GUI applications asynchronously. (This is standard behavior! And, frankly, I've never heard of it doing otherwise. That's what the 'subsystem' flag in the PE header is for.)


I'm on Windows 7 Professional, SP1 (Version 6.1.7601)

(This is not my normal computer -- I'm setting it up this way to avoid messing with the owner's preferences and still have a small and useful environment I can use while here.)

I've a shortcut that starts ConEmu:

C:\Users\Public\Documents\Michael\bin\ConEmu\ConEmu.exe /dir C:\Users\Public\Documents\Michael /cmd cmd /k C:\Users\Public\Documents\Michael\bin\prompt.bat

(I've tried starting ConEmu from the Start Menu as well, plus all combinations of below, with no change in behavior.)

The prompt.bat file is:

@echo off
set PATH=C:\Users\Public\Documents\Michael\bin;%PATH%

(I've tried without the prompt.bat and without modifying the %PATH% as well.)

My npp.bat batch file is exactly as given (and as you have it), in a %PATH% directory.

Screenshot:
http://home.comcast.net/~michaelthomasgreer/temp/ConEmu-screenshot.png

Is there a configuration file or anything you'd like to look at?

[Maximus5]

Well, seems like cmd.exe totally ignores PE header while you are starting GUI application from cmd or bat file. And of course the behavior is the same from ConEmu or standard console (Checked on Win 8.1 x64).

You see, standard cmd.exe without ConEmu or any other emulators. Even notepad.exe is started synchronously, regardless of full path or "@" prefix.
http://i.imgur.com/jfxQ43v.png

But with "start" you can force cmd to do right things:
@start "" "C:\Windows\system32\notepad.exe" %*

The other way - aliases. You may add to the your prompt.bat file (example for notepad.exe):
doskey n="C:\Windows\system32\notepad.exe" $*
No bat - no lock:
http://i.imgur.com/SAhuhzS.png

One more way - just start notepad++ before running batches.

[LB]

Maximus5 wrote:

You see, standard cmd.exe without ConEmu or any other emulators. Even notepad.exe is started synchronously, regardless of full path or "@" prefix.
http://i.imgur.com/jfxQ43v.png

https://i.imgur.com/ljS9FH2.png

[Maximus5]

cmd.exe totally ignores PE header while you are starting GUI application from cmd or bat file.

You haven't read full message.

[Duthomhas]

Forgive me, but you seem to be overly occupied in attempting to show our counter-examples nonsense by recurring to the way your system works.

All you've succeeded in doing is convincing me that there is a difference in the way things work on Windows 8 vs every other version of Windows.

I think I'll ask on the Windows forums about it to see if it has anything to the observed disparate behaviors.

[Maximus5]

OK, I've specially checked:
Windows 2000
Windows XP SP3 x86
Windows 7 x64

Created np.bat with only line:
@"C:\windows\system32\notepad.exe" %*

Ran "np np.bat" from simple/naked/standard cmd.exe prompt

All these systems wait for notepad.exe termination before np.bat can be finished and prompt appears again.

Have you tried batch with simple notepad.exe instead of notepad++?

[LB]

That's the difference - when the command is in a batch file, it waits, but if you run it directly from the console, it doesn't wait. I didn't realize that was so significant.

[Maximus5]

I think there is a logic with that cmd.exe behavior. Batch is executed line-by-line. Following lines or even parent batches may depends of that GUI application execution results. So cmd.exe waits while created process is terminated.
And as I said that behavior was not changed since (at least) Windows 2000.

[Lachlan Easton]

Boy, You might consider that ConEmu's author understand more about how the Windows Console window and ConEmu works.

http://makeagif.com/pNIXHV

[Duthomhas]

Ah, that makes sense.

I'm at my home system now and I see that my npp.bat file reads:

@start C:\PROGRA~2\NOTEPA~1\NOTEPA~1.EXE %*

There also appears to be an issue with start if you include spaces in the filename... Go figure. I'll have to fix the start command issue with my Mother's PC.

Yay! Thanks! Now everything seems to be working properly.

[Maximus5]

@start "" "C:\Program Files\notepad++\notepad++.exe" %*

[S G H]

As Maximus notes, with multiple parameters, the first may be interpreted as the console's title, so there needs to be an empty string.

[Duthomhas]

I did not know that about start.
Where is the documentation on that?

[Maximus5]

start /?

[Duthomhas]

LOL, do you know how many times I've read that? (Or mis-read that?)