Run without cmd window? (hidden)

[DocMAX]

Is there a way to run a script via busybox64 but without cmd window?
I read about a noconsole option? How do i use it?
Also tried creating a .profile file with "export ENABLE_ASH_NOCONSOLE=1".

[garoto]

Very interesting, had no idea about ENABLE_ASH_NOCONSOLE, which seems to do what hideexec was designed to do and which is what I am/was using for this exact purpose. So thank you.

Try this:

C:\> busybox sh -c "ENABLE_ASH_NOCONSOLE=1 ~/sshtun.sh &"

[DocMAX]

No, i still get a black windows console.

Tried: busybox sh -c "ENABLE_ASH_NOCONSOLE=1; sleep 10"

[rmyorston]

ENABLE_ASH_NOCONSOLE is a build-time configuration setting, not a runtime variable. It's enabled by default and enables the noconsole option. Use it like so in whatever it is that runs the script:

C:/path/to/busybox sh -o noconsole C:/path/to/script

A console window still exists but it's hidden as soon as possible.

[DocMAX]

Ahhhh, so this is how it works. Thank you. Search for 1 hour now how to use that option.

[ale5000-git]

@rmyorston

Is there any way to have something like this?
busybox su -o noconsole -c "echo Example; sleep 20"

And also have it working dinamically with these?
set -o noconsole
set +o noconsole
busybox sh -c "set -o noconsole; echo Example; sleep 20; set +o noconsole"

There is an API: ShowWindow
with: SW_HIDE
Look here: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-showwindow

[rmyorston]

This works:

busybox su root -- -o noconsole -c "echo Example; sleep 20"

But set -o noconsole and set +o noconsole don't. I suppose they could be made to work but it wasn't a requirement when the feature was implemented.

[ale5000-git]

Also be able to hide an interactive shell with set -o noconsole would be nice but using set -o noconsole and set +o noconsole inside a shell script is the most useful thing.

[rmyorston]

The latest prerelease binaries allow thenoconsole option to be changed with set. Also, the console window is now minimised rather than hidden.

[skeeto]

I've been trying out FRP-5181 and noticed that I'm now seeing console windows that weren't there before, specifically when running programs from gvim :cexpr system("..."), due to a1ccb78. The semantics of this options have subtly changed, probably unintentionally:

• Old: When noconsole is unset (the default), do nothing.
• New: On start, force the window state to match noconsole.

IMHO, the original semantics are closer to the correct behavior. If I don't make a conscious decision about noconsole, ash should do nothing to the console window. (I hadn't appreciated the importance of this behavior until it was gone!) The most correct behavior should have three states: default, set, unset. The default (no decision) means don't call ShowWindow at all. The other two are implicit calls to ShowWindow to force it one way or another.

As a secondary observation: The change from SW_HIDE to SW_MINIMIZE means that even when I manually -o noconsole I get a distracting minimize animation, whereas before the window instantaneously minimized without showing for even a single frame. Despite SW_HIDE, the console was still visible and minimized, and I could interact with just as easily as the current SW_MINIMIZE, so I can't see any benefit.

[skeeto]

One more issue I forgot to mention that I noticed while investigating the new check: Despite the BOOL return, IsIconic doesn't return zero or one, but zero and non-zero. Though when I ran a few tests I only ever saw 0 or 1. One must be careful with Win32 BOOL about that! Some Win32 functions are even trinary in their BOOLs: -1 (error), 0 (false), 1 (true).

[rmyorston]

I've been trying out FRP-5181 and noticed that I'm now seeing console windows that weren't there before, specifically when running programs from gvim :cexpr system("...")

What sort of programs are you running in :cexpr system("...")?

New: On start, force the window state to match noconsole.

It should be the other way round: noconsole should be made to match the window state. In FRP-5181 these work differently:

~ $ sleep 3; set -o noconsole; sleep 3; set +o noconsole; sleep 3
~ $ sleep 3; set -o noconsole; sh -c "sleep 3"; set +o noconsole; sleep 3

The first keeps the console iconified for three seconds. In the second the console is restored immediately. There's a commit to fix that on the 'noconsole2' branch. (Requires a trinary console_state() function!)

Despite SW_HIDE, the console was still visible and minimized, and I could interact with just as easily as the current SW_MINIMIZE, so I can't see any benefit.

I don't agree. When the console is hidden with SW_HIDE is doesn't appear as an icon in the bottom panel.

[skeeto]

What sort of programs are you running in :cexpr system("...")?

I have busybox-w32 set as my shell so that commands such as ! have access to all its nice shell features. (Note: The configuration here is imperfect, but the best that can be achieved without modifying Vim itself.)

set sh=sh shcf=-c sxq=\"

So every external command involves ash even if the end program isn't a busybox-w32 app. I first noticed the change in behavior with goimports, which I run frequently while writing Go. Running it though cexpr populates the quickfix list, and Vim, knowing the output is for its own consumption, minimizes the console window automatically (i.e. Vim is solving the same problem as you). I expect the shell not to change the window state unless I explicitly say to do so. However, FRP-5181 normalizes that window because noconsole is unset.

It should be the other way round: noconsole should be made to match the window state.

That sounds reasonable, too. Simplifying your example further:

$ sleep 3; sh -c echo

If I start that command in FRP-5181 and then immediately minimize the console, after three seconds the console window will pop back up on its own. If my shell did this with the terminal on Linux I'd consider it broken.

a commit to fix that on the 'noconsole2' branch

Thank you! That looks a lot better. I tried it out, and it restores the original default (no decision) behavior in all the cases I tested.

When the console is hidden with SW_HIDE is doesn't appear as an icon in the bottom panel.

Hmm, I did another isolated test, and you're right. However, when I SW_HIDE through a Vim-launched shell, it behaves identically to SW_MINIMIZED. I don't know what's going on there. Perhaps the minimize animation I see in FRP-5181 is some kind of state whiplash? However, I don't see that in noconsole2, and in my own quick patch to only act on +o noconsole, SW_MINIMIZE works fine even when I use set -o noconsole in the command (i.e. it actually calls ShowWindow(SW_MINIMIZE)).

https://github.com/skeeto/w64devkit/blob/ce97a11/src/busybox-002-fix-noconsole.patch

(I'll drop this patch when noconsole2 makes it into a release.)

By the way, it's so nice and convenient that I can debug and hack on busybox-w32 natively on Windows! I could drop a breakpoint on ash_main, a watchpoint on noconsole (note: requires s/-g\>/-g3/ in Makefile.flags so that GDB can see through the macro), and just step though it. Even more, the improved CTRL-C in handling FRP-5007 is a boon for debugging interactive programs, which up until then, would confuse and crash GDB without set new-console as workaround.

[DocMAX]

The latest prerelease binaries allow thenoconsole option to be changed with set. Also, the console window is now minimised rather than hidden.

why is "hidden" removed? i prever hidden. can you add both options?

[rmyorston]

why is "hidden" removed?

The thinking was that iconification was better as it allowed the user to access the console window if required.

i prever hidden. can you add both options?

OK. There's a new noiconify option. If this is turned on with set -o noiconify the console window is hidden instead of iconified.

There are new prerelease binaries (PRE-5338 or above) which have this feature.

[ale5000-git]

@rmyorston
I appreciate your work on this issue but in my opinion names are very confusing.

My suggestion:

• set -o minimized
• set -o hidden or maybe set -o noconsole (to be coherent with the past versions where it wasn't minimizing)

Furthermore, in my opinion they should be independent from each other, not like now that noiconify does nothing without noconsole.

[ale5000-git]

Just to be clear, for those that are a bit old style and configure Windows like this, this is how it appears after set -o noconsole:

So it isn't "noconsole", but just minimized.

[rmyorston]

Sure, I know it isn't really no console, but it's too late to change the name now.

I'm also happy with the way noconsole and noiconify work together.

[ale5000-git]

First: I'm just write this to have an exchange of opinions, not for else.
So I'm just stating my opinion, no offense intended.

Sure, I know it isn't really no console, but it's too late to change the name now.

The noconsole was introduced in the rigth way (in my opinion) on 2013/05/24, here: 6392ae0
and it was changed in a confusing way (in my opinion) on 2023/06/01 here: a1ccb78

So it was actually actually "live" for 10 year in the previous way and only in the last year has taken this confusing form.
So I think it was already too late for the "2023/06/01" change.

In my opinion all of this is currently conceptually wrong.
The window in "Windows" have four status: normal, maximized, minimized, hidden.
All apps on Windows agree on this (in my opinion), see this for example: https://superuser.com/questions/925277/what-does-run-as-hidden-window-mean-and-how-can-i-show-the-hidden-windows

Quote:

What "Hidden" means is exactly what you observe, that you cannot see its GUI and it has no presence on the task-bar.

In my opinion the fact that currently in busybox the meaning of "hidden" is both really "hidden" or "minimized" doesn't make sense; if you follow this scheme ("hidden" as "not visible") then also when the windows is maximized but in background (behing other windows) is "hidden".

My suggestion was to restoring the previous behaviour of noconsole => really hidden; for the other things (iconified a.k.a. minimized) whatever name is wanted.

PS: Another source of confusion is this: on Windows the meaning of "iconified" is probably more likely => hidden but with an icon in the systray (the one near the clock, not task-bar); some GUI programs support this.

@rmyorston
@avih

[avih]

The noconsole was introduced in the rigth way (in my opinion) on 2013/05/24, here: 6392ae0
and it was changed in a confusing way (in my opinion) on 2023/06/01 here: a1ccb78

So what you call "confusing" is that -o noconsole now iconifies instead of hide, and if you want to hide then you need to add -o noiconify which is annoying/confusing, correct?

If yes, then I don't think it's confusing, because the behavior is well defined, and I do think it's technically better, because now by default with -o noconsole you can still access that window if you need, while previously you couldn't, but you can also hide if you really want to.

I.e. everything which was possible previously is still possible now, but with an additional feature.

Whether it's convenient or not is a matter of personal opinion and use cases, e.g. if you only care about hiding the window then it's probably less convenient, but I don't think there's any point in discussing it further, because it's subjective.

If by "confusing" you meant something else, then please be more specific.

[ale5000-git]

The fact that "iconify" depends on "noconsole" is confusing.
Also the fact that changing "noconsole" without changing "iconify", do minimize instead of no-consoling (hide the console) the window is confusing.

For me they are conceptually independent, they should be able to be in all these states:

• Not minimized and not hidden
• Minimized and not hidden
• Not minimized and hidden
• Minimized and hidden

Also as I already said "iconify" can't in any means mean minimized (in my opinion).

[rmyorston]

The terminology is confusing.

• The API to get the window state has IsWindowVisible() (i.e. not hidden) and IsIconic(),
• The API to set the window state uses SW_HIDE and SW_MINIMIZE.

Such is life.

[avih]

The terminology is confusing.
Such is life.

+1

There could be better names, and I don't think anyone is arguing otherwise. I also don't think many users would object to changing it to better names, which might be minor inconvenience in the short term, but not terrible.

Another option is to make -o noconsole hide again by default, and add -o iconify instead of noiconify (which still is only relevant when noconsole is set) which would decide on whether it's hidden-hidden, or hidden-iconified. But even if it stays as it, IMO it's not terrible.

The thing is that it's also subjective, so no real point in arguing over it beyone making one's opinion public.

The important thing is to ensure users can get the info, preferably easily, of what these options do.

[janko-jj]

Hi I've used the previous versions of busybox to start busybox's make from the .BAT file which after some conditions are checked comes to the

busybox make

line. The start of that BAT was initiated from my Windows GUI editor when pressed certain key.

Up to the most recent busybox version after pressing the key, busybox's make would run but there would be no console window appearing for a moment covering big part of the screen, and now I see exactly that happens (a non-minimized window appears for some moments) whenever that make has to do something (and, interestingly, not when everything is current!?).

I see here that there were indeed some changes in the related behavior and that there are new options now to configure the behavior of new console window appearing, but since I haven't had to configure anything up to now, I'm confused about what I should do and where actually. Can you suggest what I should actually change and where? Thanks.

Edit: Most importantly I don't call shell explicitly there, just busybox make. I also haven't had $HOME/.profile up to now and I also tried inserting in the newly created file there both set +o noconsole and set -o noconsole but nothing changes (I assumed one would at least minimize the window but I don't see any change). Makefile itself is simple, invokes compiler etc but doesn't have any commands calling busybox or make.

[rmyorston]

@janko-jj When you say 'the most recent busybox version' do you mean the latest release (FRP-5398) or prerelease (PRE-54xx)?

Which editor are you using? I'd like to be able to reproduce the problem you're seeing.

[rmyorston]

@janko-jj If you're currently using FRP-5398 it would be worth trying a prerelease binary, version PRE-5436 or greater.

[janko-jj]

Hi, thanks. With BusyBox v1.37.0-FRP-5301-gda71f7c57 I don't see that behavior, with BusyBox v1.37.0-FRP-5398-g89ae34445 I see it, both downloaded from https://frippery.org/files/busybox/

Now preparing repro files I see that except for calling gcc I do call another busybox command inside of Makefile, here rm and when I remove it the console window doesn't appear.

To reproduce the effect: you'd need SciTe https://www.scintilla.org/SciTEDownload.html (Sc1.exe as a single binary should be enough)

Then put these files a new directory, there open a.c file in SciTe and hit F5. It should run busybox make from mybuild.bat

mybuild.bat:

echo starting busybox make...
busybox make

SciTEDirectory.properties:
command.go.*.c=mybuild.bat $(FileName) $(1) $(2) $(3) $(4) $(5)
Makefile:

a.exe: a.c
	rm -f __tmp__
	gcc a.c

a.c:
void main( void ) { }

SciTEDirectory.properties has to be named so. Sorry for not attaching the archive instead with the files but it gets rejected by github because of "unknown extensions" inside.

With 5301 no console, with 5398 console appears. I haven't had $HOME/.profile as I've observed it, and I'm not aware I've done anything else than simply copying busybox to path (and doing so renaming busybox64.exe to busybox.exe, I'm using 64 bit no-unicode exe on Windows 8.1, sorry for "MS unsupported", but busybox works).

[avih]

With 5301 no console, with 5398 console appears.

Is one of "no console" and "console appears" desirable and/or expected, while the other is unexpected or undesirable?

If yes, which is which, and why is it expected or desirable to behave like so?

Also, you should try the latest pre-release as well. As noted earlier, at least 5436

[janko-jj]

I've just downloaded BusyBox v1.37.0-PRE-5438-gd18c624d9 and now it behaves like 5301 and older versions did, which is what I'd expect (that the console window doesn't appear when it definitely shouldn't). It seems you solved it and 5398 was an "unstable" release. Thanks!

Edit: if I understand correctly, the relevant commit could be
347c877

Edit2: Now seeing the commit, I can imagine that the reason why the window appeared is that I also have links like the following to busybox.exe from rm.exe and mkdir.exe reachable through the path, which I both created using "busybox ln", and now I think busybox's make executes these, and they launched that undesired new windows?

C:\my\utils>busybox ls -l rm.exe
lrwxrwxrwx    1 root     root            11 Jun 30 22:46 rm.exe -> busybox.exe

[rmyorston]

@janko-jj Thanks for the instructions for reproducing the problem. I was able to use them to confirm that the issue here is the same as in #430: the editor hides the console host associated with the cmd.exe which runs the batch file. This confused the shell which make uses to run the build commands. As you've demonstrated, the fix for #430 works here too.

Your rm.exe and mkdir.exe won't be run by make: it knows rm and mkdir are available as applets in BusyBox so it's able to run them even if they aren't reachable on PATH. Of course, you may have other reasons to have them on PATH.

[janko-jj]

Many thanks. Now I still don't understand why it appeared to me that the console host didn't show every time the busybox make was called, but only then when it had to execute the commands from some rules? (That's why I thought I should report about rm.exe link too).

[rmyorston]

The hidden console host is revealed the second time a shell runs. (It's changed from hidden to iconified the first time. That's less noticeable.) So if make only has one command to run the console host doesn't appear.

[TechnoSparks]

Hi i actually got information on how to run a hidden console through this github issue. I use it to run a script using windows' task scheduler.

One thing i noticed, running busybox sh -o noconsole -o noiconify script.sh does not work and i have to use set -o inside the script.sh. Which is fine I think since the script is meant to run in the background silently. However, I notice that when busybox is called, a fullscreen application (games, in my case) would lose focus and throw me to the desktop. I tried using nircmd exec hide busybox sh script.sh (this was my goto way to hide batch scripts window) but the forced unfocus still happens.

Does anyone have tips to mitigate this?

[ale5000-git]

@TechnoSparks
The issue is in the current latest release but it is already fixed in the latest pre-release here: https://frippery.org/files/busybox/prerelease/?C=M;O=D

Just update and the issue will disappear.

[ale5000-git]

@TechnoSparks
Also noiconify should be set before noconsole, otherwise it won't be used the first time, so try:
busybox sh -o noiconify -o noconsole script.sh

[TechnoSparks]

@ale5000-git hi much thank you for the reply. It seems like the behaviour have changed completely because I just updated to a newer version of Windows 11 (insider Beta). This time, neither the prerelease or current version launches the script hidden but using nircmd exec hide works, as opposed to my previous comment. Strange! I proceed to check with a clean Windows 11 Stable in a VM and no difference there either.

Video showcasing a new window is spawned when using sh -o noconsole -o noiconify: (please ignore the dirname in "PRE" tab, rest assured it is using the prerelease binary) busybox noconsole not working.webm

But nircmd exec hide works on both current and pre-release versions. Interestingly, for pre-release, using nircmd exec hide and omitting the -o noconsole -o noiconify options work. On current version, this will still spawn a cmd.exe window, but it is minimized and does not make focus lost. it does

With that being said, my issue within this issue have solved itself and the culprit was Windows. But the developer may be interested on the -o noconsole -o noiconify not working. I suspect it must be with Windows Terminal.

I noticed I didn't tell what nircmd is. It's this: https://www.nirsoft.net/utils/nircmd.html

[TechnoSparks]

🤦‍♂️ I totally forgot to test using tasksched specifically. Will update soon

Update: Task Scheduler aligns with my findings above

[TechnoSparks]

But the developer may be interested on the -o noconsole -o noiconify not working. I suspect it must be with Windows Terminal.

yes it seems with Windows Terminal a new window appears. Using "Windows Console Host" (conhost.exe) does not spawn a visible window, which is the correct behavior. Hopefully my comments here could be of use for any future readers.

[ale5000-git]

@TechnoSparks @rmyorston
I have made some tests on Windows 10 and noticed some discrepancies:

1. From cmd.exe => busybox.exe sh -o noiconify -o noconsole -c "sleep 5; set +o noconsole" => it hide correctly

2. From Terminal => busybox.exe sh -o noiconify -o noconsole -c "sleep 5; set +o noconsole" => it only minimize

3. From Start Menu => Run... => busybox.exe sh -o noiconify -o noconsole -c "sleep 5; set +o noconsole" => spawn a new window for an instant and then hide correctly

4. From cmd.exe => start "" busybox.exe sh -o noiconify -o noconsole -c "sleep 5; set +o noconsole" => spawn a new window for an instant and then hide correctly

5. From Terminal => start "" busybox.exe sh -o noiconify -o noconsole -c "sleep 5; set +o noconsole" => spawn a new window for an instant and then hide correctly

@rmyorston
Is there any way to avoid the issues?

[avih]

Is there any way to avoid the issues?

How many issues are there? As far as I can tell, according to you, all of them are correct except the 2nd one "it only minimize", no?

unless you consider this an issue "spawn a new window for an instant and then hide correctly", but this is not in busybox's control.

It's "start" which launches the window, and once busybox starts running, it does what it's supposed to do and hides it.

IIRC "start" does support non-default launch modes too, so that's probably what you should use when using "start".

[ale5000-git]

No, all are wrong except the first.
I think some apps are able to start already hidden without show a new window at least on the point 3.

Note: The point 3 doesn't use "start".

[avih]

Note: The point 3 doesn't use "start" application.

busybox.exe is a console application. like any console app, if you run it from GUI (like explorer, or start), it first creates the window, and then starts running.

If you want to launch it hidden from gui then you should check the gui docs how to do that. but busybox itself can't hide the window before it starts running, and it only starts running after the window is created.

[TechnoSparks]

TechnoSparks rmyorston I have made some tests on Windows 10 and noticed some discrepancies:

1. From cmd.exe => busybox.exe sh -o noiconify -o noconsole -c "sleep 5; set +o noconsole" => it hide correctly
2. From Terminal => busybox.exe sh -o noiconify -o noconsole -c "sleep 5; set +o noconsole" => it only minimize
3. From Start Menu => Run... => busybox.exe sh -o noiconify -o noconsole -c "sleep 5; set +o noconsole" => spawn a new window for an instant and then hide correctly
4. From cmd.exe => start "" busybox.exe sh -o noiconify -o noconsole -c "sleep 5; set +o noconsole" => spawn a new window for an instant and then hide correctly
5. From Terminal => start "" busybox.exe sh -o noiconify -o noconsole -c "sleep 5; set +o noconsole" => spawn a new window for an instant and then hide correctly

rmyorston Is there any way to avoid the issues?

I believe Avih is right, and what you are experiencing is the correct behaviour. Since you are using Windows 10, you aren't using Windows Terminal as the default "host" like my machine does, so your no. 2 is the only discrepancy here. But in my opinion, that's Windows Terminal's problem and not really busybox-w32's.

My personal summary, to launch busybox hidden:

• without any external tools on Windows 11 (because Windows Terminal is set as default console), use conhost directly: conhost.exe busybox.exe sh -o noiconify -o noconsole [...]
  • this will however cause any fullscreen window to minimize
• without causing focus loss, use nircmd external program: nircmd exec busybox.exe sh -o noiconify -o noconsole [...]
  • this works everywhere, in Windows Terminal, conhost, launching from File Explorer, Run, Task Scheduler

[ale5000-git]

If I use conhost.exe from cmd.ex / Terminal / run I get it to "spawn a new window for an instant and then hide correctly"; it never minimize.

[ale5000-git]

@TechnoSparks
Could you please upload a video of your use of conhost.exe that cause any fullscreen window to minimize?
Because I didn't understood what you mean.

[rmyorston]

Also noiconify should be set before noconsole, otherwise it won't be used the first time

Actually, the order doesn't matter. When multiple options are processed from the command line all the new values are set first and then any required actions happen.

I see the problem with Windows Terminal not respecting the -o noiconify option, but that does indeed look like an issue with the Terminal itself.

[ale5000-git]

@rmyorston
Here they seems to have fixed the issue with Terminal: microsoft/terminal#12570
I don't know this code too much so I'm not really sure but maybe you can find the solution.