Je suis en train d'utiliser l'invite de commande bash de Cygwin, et pour les commandes longues, le texte se placera sur la même ligne au lieu de passer à la ligne suivante malgré avoir configuré mon PS1 à simplement ' $'.
Voici une capture d'écran,
J'utilisais déjà MinTTY et enlever le saut de ligne dans PS1 n'a pas aidé non plus. Un conseil sur cette page m'a aidé. J'ai exécuté cette commande bash :
kill -WINCH $$Dans mon cas, exécuter cela une fois a résolu le problème, même après avoir déconnecté et reconnecté. Je ne suis pas sûr si c'est toujours le cas.
En juger par -WINCH, cela signale au processus bash que la fenêtre du terminal a été redimensionnée. Donc cela devrait être fait après chaque redimensionnement de la fenêtre du terminal, je suppose.
@ivan_pozdeev, Je viens de trouver que tu dois seulement faire cela si tu redimensionnes alors que vim est ouvert : vim reçoit le signal et se redessine à la nouvelle taille, mais cela n'est pas transmis à son processus parent et donc bash continue de penser que la taille de l'écran est celle qu'elle était lorsque vim a été ouvert.
Comme mentionné par @ak2 dans un commentaire sous la question originale, l'exportation de TERM=cygwin est suffisante pour résoudre le problème.
Ce n'était pas suffisant dans mon cas. Si PS1 contient des séquences d'échappement qui ne sont pas incluses dans \[...\], le problème d'enrobage persisterait. Définir la variable d'environnement TERM pourrait être suffisant dans votre cas, mais j'en doute.
Pour moi, cela corrige le problème selon lequel la deuxième ligne écrase la première ligne, cependant, sauf si j'utilise un terminal de largeur exactement 80, la position du curseur et le décalage du texte sont toujours désordonnés (en utilisant cygwin64, mintty 2.3.7)
J'ai eu le même problème avec MinTTY également. Le problème a probablement quelque chose à voir avec l'invite principale (PS1).
La solution pour moi était de supprimer le dernier caractère de 'nouvelle ligne' de PS1 (juste avant le signe '$') :
user@host ~
$ echo $PS1
\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$
user@host ~
$ export PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\$ '
user@host ~ $voir http://cygwin.com/ml/cygwin/2001-07/msg00140.html pour référence.
Pour rendre ce changement persistant, ajoutez export PS1='[\e]0;\w\a]\n[\e[32m]\u@\h [\e[33m]\w[\e[0m]\$ ' à votre fichier ~/.bashrc.
La réponse de @jtpereyda est certainement pertinente. Mais pour une raison quelconque, je ne pouvais pas laisser cela passer et j'ai creusé un peu plus profondément.
En développant sur ce commentaire, si vous redimensionnez le terminal pendant que vous êtes dans vim (ou toute autre application en plein écran prenant le contrôle du tty loin du shell), le SIGWINCH résultant n'est souvent pas envoyé au shell, donc il ne sait pas que le terminal a été redimensionné une fois qu'il retrouve le contrôle.
Lorsque vous redimensionnez votre terminal, il devrait appeler un ioctl(..., TIOCSWINSZ, ...) sur le pseudo-terminal maître dans lequel vim fonctionne. Cela entraîne ensuite un killpg(SIGWINCH) sur le groupe de processus de vim.
Le problème est que vim s'exécute dans son propre groupe de processus distinct du shell dont il a été lancé, donc le shell bash ne reçoit pas le SIGWINCH et n'ajuste pas ses lignes/colonnes correctement.
Si vous souhaitez une solution temporaire, ajoutez shopt -s checkwinsize à votre .bashrc. Cela permet à bash de vérifier la taille de la fenêtre (ioctl(..., TIOCGWINSZ, ..)) après chaque commande et d'actualiser ses lignes/colonnes.
Je voulais faire référence à une autre question qui, je pense, établissait un lien plus évident, mais en résumé, une cause possible du problème de l'auteur est l'ouverture d'une application de terminal complète comme vim, le redimensionnement du terminal, puis la sortie. Comme je l'ai expliqué, le SIGWINCH n'est pas vu par le shell, donc lorsque vous quittez vim, il pense toujours que le terminal est de la taille précédente, ce qui entraîne divers problèmes d'enroulement de lignes.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
13 votes
Quelle est la valeur de la variable d'environnement
TERMdéfinie ? Pour la console Cygwin, elle devrait êtrecygwin.1 votes
@ak2 cela a résolu le problème pour moi, merci. Cygwin sur Mintty.