Launching the BusyBox shell from Windows' CMD or PowerShell and pressing Ctrl+C will overlap both shells
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- bash, c, powershell
- Área
- cli, operating-systems
Línea de trabajo
Start by reproducing the issue with bash.exe or sh.exe launched from Windows CMD or PowerShell, including after Ctrl+C interrupts a command such as sleep 10. Trace the terminal and interrupt handling involved in those shell entry points; done means Ctrl+C no longer leaves both shells receiving input or printing prompts.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I noticed this when trying to setup for myself an easy-to-use shell environment.
If I open a CMD or PowerShell window, and then launch bash.exe from the command line, and then I press Ctrl+C, it will appear like both CMD/PowerShell and the BusyBox shell will fight for my terminal. Both will print their prefixes at the same time, and it seems that each of my keystrokes is sent in alternance to each shell, so if I were to type "exit" and enter, one shell would get "xt" and the other "ei" and enter. The terminal becomes essentially unusable.
The Ctrl+C bug passes through any running command, so if I'm within the BusyBox shell running another program like GCC or even sleep 10, just one Ctrl+C will both interrupt the running program as expected, and cause the bug I describe. Pressing Ctrl+C more times does not appear to change anything, the only way that I'm aware of to work around the problem is to close and reopen the terminal.
Straightforward reproduction steps:
- Launch CMD or Powershell
- From the shell, execute BusyBox's
bash.exeorsh.exe - Optionally, launch a program that takes time, like
sleep 10 - Press Ctrl+C once
The effects should be immediately visible; pressing return a few times shows the clash between the shells.
I'm not entirely sure where is the most relevant place to report this issue since I'm not sure what's in cause here; I can bump the bug report to BusyBox or elsewhere if needed.
- Lenguaje dominante
- C
- Estrellas
- 5k
- Forks
- 408
- Merge medio
- 4 h 40 min
- PR fusionados (30 d)
- 2
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de skeeto/w64devkit
-
New busybox-w32 versionAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 46/100
-
Bring UTF-8 back to x86 kitAbierto
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
-
Support for mcfgthreads?Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Todos los issues de skeeto/w64devkit
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
sk3llo/ffmpeg_kit_flutter#176 ·
-
Synth suite fails unless run from the repo root: signal_flow's default machine path is cwd-relativeAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
Nimblesite/osprey#370 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100