Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.6 KiB
name, kind, lang, domain, version, purity, signature, description, tags, uses_functions, uses_types, returns, returns_optional, error_type, imports, tested, tests, test_file_path, file_path, params, output
| name | kind | lang | domain | version | purity | signature | description | tags | uses_functions | uses_types | returns | returns_optional | error_type | imports | tested | tests | test_file_path | file_path | params | output | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| launch_cpp_app_windows | function | bash | infra | 1.1.0 | impure | launch_cpp_app_windows(app_name: string, [desktop_dir: string]) -> void | Lanza un binario .exe en Windows desde WSL2. Asume que deploy_cpp_exe_to_windows ya copió el exe a Desktop/apps/<app_name>/. Usa cmd.exe /c start para desacoplar el proceso y retornar inmediatamente. |
|
false | error_go_core | false | bash/functions/infra/launch_cpp_app_windows.sh |
|
Imprime 'OK: <app_name> launched at <ts>' en stdout si el exe existe y el comando se lanza. Errores fatales a stderr con exit 1. |
Ejemplo
source bash/functions/infra/launch_cpp_app_windows.sh
# Lanzar con default desktop dir
launch_cpp_app_windows "registry_dashboard"
# OK: registry_dashboard launched at 2026-05-14T10:32:01
# Override de desktop_dir (ej. otro usuario)
launch_cpp_app_windows "chart_demo" "/mnt/c/Users/otrouser/Desktop"
# OK: chart_demo launched at 2026-05-14T10:32:05
Comportamiento
cmd.exe /c start es la clave: lanza el proceso en Windows y retorna inmediatamente sin esperar a que el exe termine. El proceso queda desacoplado del shell WSL2. Esta funcion no verifica que el exe arranco correctamente ni que sigue corriendo — esa responsabilidad recae en is_cpp_app_running_windows (funcion complementaria).
El cd /d previo al start es esencial: los apps C++ del registry buscan sus assets, local_files/ y DLLs relativos al directorio de trabajo. Sin el cd, Windows buscaria desde C:\Windows\System32 y el exe no encontraria nada.
Prerequisitos
- WSL2: la funcion usa
wslpath -wycmd.exe, ambos solo disponibles en WSL2. /mnt/c/montado: el exe debe ser accesible via la ruta/mnt/c/....- Exe ya copiado:
deploy_cpp_exe_to_windowsdebe haberse ejecutado antes. Esta funcion no compila ni copia nada.
Notes
Mitad complementaria de deploy_cpp_exe_to_windows_bash_infra. El flujo completo para actualizar y relanzar una app es:
# 1. Compilar para Windows
build_cpp_windows "registry_dashboard"
# 2. Copiar al escritorio (mata proceso si corre, copia DLLs+assets)
deploy_cpp_exe_to_windows "registry_dashboard" "/home/lucas/fn_registry/apps/registry_dashboard"
# 3. Lanzar
launch_cpp_app_windows "registry_dashboard"
No se incluyen tests automatizados porque requieren entorno WSL2 con Windows activo y no son automatizables en CI.
Gotchas
- Si
FN_REGISTRY_ROOT_WSLno es tu ruta default de fn_registry (/home/<user>/fn_registry), setea la variable antes de invocar esta función:FN_REGISTRY_ROOT_WSL=/ruta/custom launch_cpp_app_windows <app>. - El proceso hijo hereda
FN_REGISTRY_ROOTcomo path Windows (backslashes) yFN_REGISTRY_ROOT_WSLcomo path Linux. En el exe C++,py_resolve_interpreter()usaFN_REGISTRY_ROOT_WSLpara construir el invocationwsl.exe -- /path/python3. - PowerShell escapa
$con\$para evitar expansión de variables en el string del comando.
Capability growth log
- v1.1.0 (2026-05-16) — auto-propaga
FN_REGISTRY_ROOT(Windows path) +FN_REGISTRY_ROOT_WSL(Linux path) al proceso hijo para que pueda invocar WSL python viawsl.exe.