Medio ambiente: Windows 11 pro.
Quiero llamar msys2a bash en vim de git-bash donde ambos comparten la misma versión de vimy bash(aunque este contexto parece extraño).
Yo preguntéuna pregunta de origenen Vi/Vim SE y el problema parece ser que no se tiene set -mla opción al llamar :call term_start("/d/msys64/usr/bin/bash -li -vx")( -les a la fuente .bash_profile, etc. -ies para garantizar que podamos usar bash en vim) en vim. Se nota hivxBHpara $-. Pero para un bash normal llamado por :call term_start("bash -li -vx"), $-es himvxBH.
Intenté usarlo -lim -vxpero no funciona.
Lo anterior -lfunciona y se verifica en shopt -p login_shellla parte superior de /etc/profilela muestra temporal shopt -s login_shell.
Cuando no tenemos -mopción, también tenemos el siguiente mensaje de error (seguíeste control de calidad. Pero ya he usado -ila opción y esta opción no agrega -mla opción de forma predeterminada) antes de realizar la compra./etc/profile
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
El término clave es "control de trabajo", que es importante para que vim ejecute la terminal interna ( :h terminal-usedice "Se puede iniciar un trabajoconectado al emulador de terminal')
Dado que mla opción corresponde a 'monitorear' donde 'El control de trabajo está habilitado' como dice el manual, esa es la fuente del problema.
Esta pregunta puede serresuelto indirectamenteusando msys2 vim para llamar a git-bash para poder usar una versión de vim para llamar a todos los shells en mi máquina, incluidos git-bash, pwsh y msys2 bash.
P:
En mi humilde opinión, parece que vim de git-bash no tiene permiso para llamar /d/msys64/usr/bin/bash(pero git-bash sí puede). ¿Hay alguna manera deresolver directamente con¿El error anterior 'Ioctl inapropiado para el dispositivo' que causa 'no hay control de trabajo en este shell'?
Editado:
Después de ser insinuado poreste blog, 'Ioctl inapropiado para el dispositivo' parece deberse a un uso pipemás stdinespecífico. Normalmente, ls -al /dev/fd/* -alen la parte superior ~/.bash_profileaparecerá algo como /dev/fd/0 -> /dev/pty3cuando
term_start. Pero al usar el parámetro /d/msys64/usr/bin/bashtendrá /dev/fd/0 -> pipe:[0].
Entonces al veresta publicación, parece deberse a no tener el privilegio. Sin embargo, msys2 puede llamar a git-bash con /dev/fd/0 -> /dev/cons3.
Resuelto ahora:
El problema se debe a que msys2 encapsula muchos detalles y no puede ser manipulado por vim pero sí por git-bash.
# git bash try to call msys2 bash
# here although the administrator has the rwx mode, using as one administrator can't solve the problem.
$ ls -al /d/msys64/dev/
total 4
drwxr-xr-x 1 foo 197609 0 Mar 28 16:59 ./
drwxr-xr-x 1 foo 197609 0 Apr 4 16:29 ../
drwxr-xr-x 1 foo 197609 0 Mar 28 16:59 mqueue/
drwxr-xr-x 1 foo 197609 0 Mar 28 16:59 shm/
# msys2 bash try to call git bash
$ ls -al /d/Git/dev/
total 8
drwxr-xr-x 1 foo foo 0 Apr 2 09:53 .
drwxr-xr-x 1 foo foo 0 Apr 2 09:53 ..
lrwxrwxrwx 1 foo foo 13 Apr 2 09:53 fd -> /proc/self/fd
drwxr-xr-x 1 foo foo 0 Apr 2 09:52 mqueue
drwxr-xr-x 1 foo foo 0 Apr 2 09:52 shm
lrwxrwxrwx 1 foo foo 15 Apr 2 09:53 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 foo foo 15 Apr 2 09:53 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 foo foo 15 Apr 2 09:53 stdout -> /proc/self/fd/1
Entonces, como solución alternativa, podemos usar msys2 como terminal principal porque git-bash no encapsula /dev.
El entorno de desarrollo desordenado anterior es solo un entorno temporal que utilicé en Windows (realmente no se recomienda usarlo). Normalmente, desarrollaba en Archlinux. Aquí se muestra dónde está el problema. Si tienes problemas similares, espero que esto pueda ayudarte.