Wezterm-gui.exe still spawn a cmd on windows

[melMass]

What Operating System(s) are you seeing this problem on?

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

-

WezTerm version

wezterm 20240607-175437-eb26a5da

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

btw wezterm -v doesn't work anymore

I tried both the nightly and stable scoop recipes of wezterm and they both spawn 2 cmd before running wezterm (that immediatly exits after spawning wezterm). I thought the issue was about how the recipes were packaged but after digging a bit more, and making my own recipe targeting wezterm.exe instead of wezterm-gui.exe I understood the initial goal of this separate binary yet it still spawns cmd.

When using wezterm.exe the spawning terminal is "owning" wezterm at least that's not the case with wezterm-gui.exe but I would still like to avoid having to close 2 cmd each time I open wezterm

To Reproduce

1. Install recipe

   scoop install wezterm

2. Run from Start

3. See

Configuration

no config

Expected Behavior

Running wezterm-gui.exe shouldn't spawn cmd on windows. After posting this issue I'm going to try and wrap wezterm.exe into a vbs script, that's what I'm using to run komorebi already that had the same issue.

Logs

No response

Anything else?

No response

[akthe-at]

Windows 10 user here, have both stable and nightly installed from scoop. No cmd prompt issue like mentioned above and no issues with wezterm -v either. The only time I can think of getting something like this is when I didn't know what a terminal emulator was and I was trying to launch Wezterm from Windows Terminal like it was a shell ? I'm sorry I can't reproduce with you and be more helpful.

[melMass]

Thanks, this can probably be closed then, not sure what could be causing this, I will comment if I find out but I'm using my solutin fine in the meantime, for -v this is what I get:

And this --version

Ignore the spellcheck I'm editing md files and it was on when I ran those commands

[melMass]

oh it's uppercase -V my bad, but anyway not the main issue

[akthe-at]

Can you make a screen cast of the double cmd happening?

[melMass]

wezterm-nightly (from scoop) using the shortcut - the same happens from the start menu and the shortcut file directly so it's not related to my launcher, and I also tried stable

https://github.com/wez/wezterm/assets/7041726/f5be4c8b-ebbb-4659-b453-25cdf60b8741

wezterm-nightly-mtb - see mentioned commit up here for more details but TLDR it's wrapped in a vbs

https://github.com/wez/wezterm/assets/7041726/3cc9a8b0-a390-423e-a93b-8996e82c6bc1

[akthe-at]

Shouldn't this bin command here be pointing at wezterm-gui.exe?

"bin": "wezterm.exe",
    "shortcuts": [["wezterm.vbs", "WezTerm", "", "wezterm-gui.exe"]]
}

[melMass]

I didn't try but I'm guessing wezterm-gui has the same purpose as wrapping it using vbs: not spawning an owning terminal on launch. It partially works for me as the terminal doesn't "own" when using the gui variant but it's still spawned.

I don't know windows enough to understand what could be causing it honestly and it's not the first time I had to "VBS wrap" a program

[akthe-at]

Also, can you show us your wezterm config and how you have your default domains setup?

[melMass]

Oh ok I misunderstood your message. No the binaries that are used in shortcuts shouldn't be specified in "bin". "bin" are for cli binaries usually. And in shortcuts, each item in the list is ["target_binary", "Name of Shortcut", "PWD for the program launch", "An icon"] I just use the wezterm-gui.exe to extract its icon for the shortcut.

wezterm config

For sure it's really short:

local wezterm = require("wezterm")

local config = wezterm.config_builder()

local function getOS()
    -- ask LuaJIT first
    if jit then
        return jit.os
    end

    -- Unix, Linux variants
    local fh, err = assert(io.popen("uname -o 2>/dev/null", "r"))
    if fh then
        Osname = fh:read()
    end

    return Osname or "Windows"
end
config.color_scheme = "rose-pine"
config.adjust_window_size_when_changing_font_size = false
config.automatically_reload_config = true
config.color_scheme = "AdventureTime"
config.enable_kitty_keyboard = false
config.window_background_opacity = 1.0
config.hide_tab_bar_if_only_one_tab = true
config.window_decorations = "RESIZE"

if getOS() == "Windows" then
    config.font = wezterm.font("FiraCode Nerd Font")
end

config.default_prog = {
    "nu",
}

wezterm.log_info("Loaded config")
return config

default domains setup

Kore wa nan desu ka? Sorry not super familiar with windows,

[akthe-at]

Ah so the .vbs is a virtualized container then right? This looks like you are trying to use the multiplexing features and need to setup either a unix or ssh domain to this to work correctly I think? Have you read through this stuff? I don't use wezterm this way with my PC so I can't help much beyond knowing that this is where the docs are. I am sorry! @wez am I wrong in thinking that they need to ssh (and setup an ssh domain in their config?) into the localhost server that appears to be launching?

[melMass]

Interesting, I did not, I will read it, I was wondering what this local server was about!

[akthe-at]

One last question...Is the goal to have wezterm launch on startup? Do you want wezterm to be vbs wrapped or is that a solution you were trying to create? If you are just trying to get a terminal launched on startup on windows you can type shell:startup into the Run prompt.

and in the explorer window that pops up after you hit enter, you can add programs that launch on startup. This is where I put a copy of the wezterm-gui.exe shortcut.

[melMass]

Not really, I'm just trying to open wezterm "manually" as seen in my "working" screencast. After reading the multiplex doc, I'm unsure if it's opt-in. The fact that the window lays out is just because of my Window manager (komorebi) but that shouldn't be related

[akthe-at]

I launch wezterm from komorebi with this keybind. I am sorry for misunderstanding the ultimate goal. Now...this is pwsh doing it in the background, but it launches it regardless if im using a bash shell, pwsh, etc inside of wezterm.

alt + return            : if ($wshell.AppActivate('Wezterm') -eq $False) {  Start-Process "C:\Users\ARK010\scoop\apps\wezterm-nightly\current\wezterm-gui.exe" }

[wez]

Regarding flashing open a terminal window on startup, it's possible that your io.popen call is responsible for that.

FWIW, you can replace your getOS function with something that looks at https://wezfurlong.org/wezterm/config/lua/wezterm/target_triple.html

If you did still want to run uname then I would suggest using https://wezfurlong.org/wezterm/config/lua/wezterm/run_child_process.html instead of io.popen so that you don't block the GUI thread.

[wez]

If you still see weird and extraneous terminal windows, I would suggest uninstalling it via scoop and instead installing via the official installer at https://wezfurlong.org/wezterm/install/windows.html

[melMass]

Thanks @akthe-at for proposing suggestions! And @wez for the tips.

I will close this issue as I feel it's user error and I just had it happen with a GUI app not installed through scoop so I'm guessing something is fishy in my OS/settings...

If I ever find a solution I'll comment here for googlers!

Thanks again

PS: I really enjoy Wezterm, somehow I overlooked it more than once :)

[melMass]

For anyone coming here from google, I found why I had this and it's probably the same for you: You use Windows Terminal as the default terminal but set it up to not close on exit... whereas cmd.exe does by default.

I was using never, I recommend graceful that will only close if there are no errors

source

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.