79e467c32a
All checks were successful
PR Check / check (pull_request) Successful in 58s
Three Windows install/launch issues reported by the user:
1. Double-click on Desktop shortcut → dialog "This is a command line
tool. You need to open cmd.exe and run it from there."
Cause: charmbracelet/huh detects no TTY when launched via Explorer
and aborts. Fix:
- cmd/muyue/commands/root.go: skip RunFirstTimeSetup when
os.Stdin is not a character device; persist config.Default()
and let the React onboarding wizard handle first-run UX.
- ci-{main,develop}.yml: build Windows binaries with
-ldflags="-H=windowsgui" so the .exe is a GUI subsystem app —
no console window flashes on double-click.
2. CLI sub-commands (`muyue scan`, `muyue install-shortcuts`, etc.)
would lose all output under -H=windowsgui when launched from
cmd.exe / PowerShell. Mitigation:
- cmd/muyue/console_windows.go (new, build-tagged): on init(),
call kernel32!AttachConsole(ATTACH_PARENT_PROCESS). If the
parent has a console, rebind os.Stdout/os.Stderr/os.Stdin to
it and call log.SetOutput(os.Stderr) so existing log.Printf
calls surface. If no parent console (Explorer), exit silently.
3. After install, `muyue` not recognized in PowerShell.
Causes: (a) the extracted binary is muyue-windows-amd64.exe, not
muyue.exe; (b) the user PATH update by install-shortcuts doesn't
propagate to the existing PowerShell session.
Fix in install-shortcuts:
- Copy self to <installDir>/muyue.exe (rename impossible — the
running .exe is locked on Windows) so `muyue` resolves once
PATH is set.
- Update Desktop + Start Menu .lnk to target the canonical
muyue.exe rather than the platform-suffixed binary.
- Print the line `$env:Path += ';<installDir>'` for the user to
paste, refreshing the current session immediately.
- ci-main.yml install snippet bumps to 5 lines, last being
`$env:Path += ";$dest"`.
- internal/version/version.go: 0.7.4 → 0.7.5
- CHANGELOG.md: v0.7.5 entry covers all three fixes
11 KiB
11 KiB