Vraag Hoe krijg ik lange opdrachtregels om naar de volgende regel te gaan?


Iets wat ik al heel lang in Ubuntu gemerkt heb, is frustrerend voor me. Als ik een opdracht aan het typen ben die langer (breder) is dan de terminalbreedte, in plaats van naar een nieuwe regel te wikkelen, gaat het terug naar kolom 1 op dezelfde regel en begin met het overschrijven van het begin van mijn opdrachtregel. (Het feitelijke commando wordt niet daadwerkelijk overschreven, maar visueel overschrijft het de tekst die werd weergegeven).

Het is moeilijk uit te leggen zonder het te zien, maar laten we zeggen dat mijn terminal 20 tekens breed was (de mijne is meer als 120 tekens - maar ter wille van een voorbeeld), en ik wil het Engelse alfabet herhalen. Wat ik typ is dit:

echo abcdefghijklmnopqrstuvwxyz

Maar hoe mijn terminal er uit ziet voordat ik de sleutel heb geraakt is:

pqrstuvwxyzghijklmno

Als ik op enter raak, echoot het

abcdefghijklmnopqrstuvwxyz

dus ik weet dat de opdracht goed is ontvangen. Het verpakte gewoon mijn typen na de "o" en begon opnieuw op dezelfde regel.

Wat ik zou verwachten te gebeuren, als ik dit commando zou invoeren op een terminal die slechts 20 tekens breed zou zijn, zou dit zijn:

echo abcdefghijklmno
pqrstuvwxyz

Achtergrond: ik gebruik bash als mijn shell en ik heb deze regel in mijn ~ / .bashrc:

set -o vi

om te kunnen navigeren op de opdrachtregel met VI-opdrachten. Ik gebruik momenteel de Ubuntu 10.10-server en maak verbinding met de server met Putty.

In elke andere omgeving waarin ik heb gewerkt, zal ik, als ik een lange opdrachtregel typ, een nieuwe regel toevoegen onder de regel waaraan ik werk wanneer mijn opdracht langer wordt dan de terminalbreedte en als ik blijf typen, zie ik mijn opdracht aan 2 verschillende lijnen. Maar zo lang als ik me kan herinneren met behulp van Ubuntu, bezetten mijn lange opdrachten maar 1 regel.

Dit gebeurt ook als ik terugga naar eerdere opdrachten in de geschiedenis (ik druk op Esc en vervolgens op 'K' om terug te gaan naar eerdere opdrachten) - als ik bij een vorig commando kom dat langer is dan de terminalbreedte, krijgt de opdrachtregel verminkte en ik kan niet zeggen waar ik ben in het bevel.

De enige oplossing die ik heb gevonden om de hele lange opdracht te zien, is door op "Esc-V" te drukken, waardoor de huidige opdracht in een VI-editor wordt geopend.

Ik denk niet dat ik iets vreemds heb in mijn .bashrc-bestand. Ik becommentarieerde de "set -o vi" regel, en ik had nog steeds het probleem.

Ik heb een nieuw exemplaar van Putty gedownload en heb geen wijzigingen in de configuratie aangebracht - ik typte zojuist mijn hostnaam om verbinding te maken en ik heb nog steeds het probleem, dus ik denk niet dat het iets met Putty is (tenzij ik het nodig heb een paar configuratiewijzigingen aanbrengen)

Heeft iemand anders dit probleem gehad en kan iemand erover nadenken hoe het te repareren?

Bewerk

Het was mijn .bashrc-bestand. Ik heb hetzelfde profiel van machine naar machine gekopieerd en ik heb speciale tekens in mijn $ PS1 gebruikt die het op de een of andere manier weggooien. Ik blijf nu bij de standaard bash-variabelen voor mijn $ PS1.

Bedankt aan @ ændrük voor de tip over de .bashrc!

... Einde bewerken ...


93
2018-02-01 20:17


oorsprong


Om er zeker van te zijn dat het probleem niet wordt veroorzaakt door uw .bashrc-bestand, raad ik aan het tijdelijk te vervangen door een kopie van /etc/skel/.bashrc. Houd er rekening mee dat u opnieuw verbinding moet maken om de wijzigingen door te voeren en zorg ervoor dat u een back-up van uw eigen .bashrc-bestand bijhoudt. - ændrük
Welke terminalapplicatie gebruikt u? Het gedrag dat u beschrijft is niet gebruikelijk, zeker geen standaard. - João Pinto
In shells waarin ik heb gewerkt (en in Cisco CLI), kunt u ook Ctrl-L typen om de regel weer te geven die u typt, zelfs als deze buiten beeld is. In jouw situatie kan dat misschien nog steeds de gebroken uitvoer opleveren waar je het over hebt, maar ik zou nieuwsgierig zijn. - belacqua
Voel je vrij om een ​​"antwoord" te maken waarin de oplossing wordt uitgelegd en gemarkeerd als geaccepteerd. Het lijkt misschien een beetje raar, maar als je een goed antwoord hebt, houd je de site geordend en kun je anderen die soortgelijke problemen hebben in de toekomst effectiever begeleiden. - ændrük
Vanaf dit antwoord op serverfault, gebruik tput smam - Samveen


antwoorden:


Zorg ervoor dat alle niet-afdrukbare bytes in je PS1 eronder vallen \[ \]. Anders telt bash ze in de lengte van de prompt. Het gebruikt de lengte van de prompt om te bepalen wanneer de regel moet worden ingepakt.

Bash telt hier bijvoorbeeld de prompt als 19 kolommen breed, terwijl de prompt die wordt weergegeven door de terminal slechts 10 kolommen breed is (My prompt geschreven in cyaan, en > geschreven in standaardkleur):

PS1='\e[36mMy prompt\e[0m>'         # bash count: 19, actual: 10

terwijl hier alleen de prompt telt als 10 kolommen breed omdat het de bytes negeert tussen de special \[ en \] ontsnapt:

PS1='\[\e[36m\]My prompt\[\e[0m\]>' # bash count: 10, actual: 10

Gebruik echter voor goede praktijken tput om de terminal-escapes te genereren in plaats van ze hard te coderen:

cyan=$(tput setaf 6) # \e[36m
reset=$(tput sgr0)   # \e[0m
PS1='\[$cyan\]My prompt\[$reset\]>'

Zien http://mywiki.wooledge.org/BashFAQ/053, en ook http://wiki.bash-hackers.org/scripting/terminalcodes voor meer informatie tput.


119
2018-02-02 08:00



Dat is een geweldige verklaring voor het probleem dat het geaccepteerde antwoord niet biedt - Jamie Cook
In de laatste regel code PS1='...' : waarom voorkomen geen enkele aanhalingstekens $cyan en $reset van vervanging? - andrybak
@andrybak, ze voorkomen het wel $cyan en $resetvan vervangen, maar PS1 wordt geëvalueerd telkens wanneer de prompt wordt afgedrukt. Je kunt dit zien door het te proberen PS1='$var> ' en geef dan var verschillende waarden en zie hoe de prompt verandert. Probeer het dan PS1="$var> "  en merk op dat de prompt statisch blijft; $var werd uitgebreid tijdens de opdracht, niet elke keer PS1 wordt geëvalueerd. - geirha
Dit is geweldig. Heel erg bedankt voor het plaatsen van dit! Het maakt het ontsnappen van de vierkante haken veel gemakkelijker en leesbaarder. - phyatt
Hoe ik dit werk maak PS1=${PS1}"\e]2;$@\a" . Ik heb geprobeerd PS1=${PS1}"\[\e]2;\]$@\[\a\]" - Ramana Reddy


Ik denk dat je je hebt geconfigureerd PS1 met kleuren, toch?

Zorg ervoor dat je dat hebt gedaan \[ in je PS1 citaat voorafgaand aan uw kleurenset

Bijvoorbeeld:

PS1='\[\e[0;32m\u@\w/:\[\e[m '

56
2018-02-02 07:06



Mijn PS1 was export PS1='^[[96m'$(hostname)'<^[[92m${PWD}^[[96m>^[[97m ' - Ik gebruik die al heel lang - het is compatibel met KSH ... - BrianH
Wauw. Ik gebruik al sinds eeuwig terminalaanwijzingen en heb dit probleem nooit eerder gehad. Ik had dat nooit uitgevonden. Bedankt. - bchurchill
het gebruik van \ [tijdens het gebruik van eenvoudige aanhalingstekens levert een onbedoelde slash op. er moet ook] aan het einde van de magische tekens worden gebruikt, zoals opgemerkt in het best gestemde antwoord - igorsantos07
-1 Werkt niet. Je moet inpakken het niet-afdrukken gedeelte met \[ aan het begin en \] aan het einde. - wjandrea
@ igorsantos07 De dubbele backslash in \\[ was een typfout veroorzaakt door een bewerking. Ik heb het gerepareerd. - wjandrea


Ik had een soortgelijk probleem en vond uiteindelijk een eenvoudige oplossing.

Voeg de volgende regel toe in uw .bashrc het dossier:

COLUMNS=250

Typ dan source ~/.bashrc om het gewenste effect te krijgen.


10
2018-04-17 10:58



In sommige gevallen, zoals smalle terminatoronderverdelingen, is het probleem niet in de promt-kleurtekens, maar alleen in een verkeerde COLUMNS-waarde. Dit antwoord heeft me uit een heel lastig gat gehaald! - Carles Sala
Afmelden is niet nodig. Do source .bashrc. Uw prompt wordt onmiddellijk bijgewerkt - Sergiy Kolodyazhnyy
Ik vond dat omdat ik geen shopt had setwinsize ingesteld voor mijn bash, dus het was niet COLOMMEN bij te werken, zie unix.stackexchange.com/a/167911/8337 - rogerdpack
ik deed export COLUMNS=250 gevolgd door export TERM=xterm en het was gelukkig. - Philip Kearns


Ik had hetzelfde probleem met een aangepaste gekleurde prompt, hoewel ik daarin kleurcodes had \[ en \] scheidingstekens. Het blijkt dat bash heeft problemen die kleuren echoën van binnen een functie. Ik heb uiteindelijk alleen variabelen gebruikt voor mijn prompt, en hoewel mijn .bashrc iets minder elegant is, werkt alles nu goed.


5
2018-05-06 04:20



Als iemand dit nog steeds leest, is het eigenlijk mogelijk om in een functie aan kleuren te ontsnappen. Zien dit antwoord op de gekoppelde vraag. - wjandrea


Een eenvoudige handeling is om de volgende regel toe te voegen voordat je de PS1 instelt:

stty columns 1000

Bijvoorbeeld,

stty columns 1000
PS1='\[\e[0;32m\u@\w/:[\e[m '

dit is echter van invloed op andere unix-commando's zoals ls en man.


2
2018-02-12 15:27



Dat werkt in OSX. - raskhadafi
Dit beïnvloedt ook vim slecht. Gebruik dit alstublieft niet. - justhalf


Ik had dit probleem wanneer verbonden in tmux. Het probleem was dat ik een ipython sessie op de achtergrond (ctrl + z) en op de een of andere manier brak de lijnverpakking. Zodra ik het beëindigde (fg, ctrl+d+d) mijn terminal ging naar behoren werken

Controleer dus of er interactieve aanwijzingen zijn gestopt.


0
2018-04-07 20:39