Terminal istemi doğru sarılmıyor


171

Bash'da çok uzun komutlar yazarsam terminalin doğru yazdığımı yapmamasına neden olur. Aşağıdaki gibi bir komut olsaydı, beklerdim:

username@someserver ~/somepath $ ssh -i /path/to/private/key
myusername@something.someserver.com

Komut iki satırda verilmelidir. Bunun yerine, sık sık etrafımda dolanacak ve istemimin üzerine yazmaya başlayacak, biraz şöyle:

myreallylongusername@something.somelongserver.comh -i /path/to/private/key

Geri dönüp bazı argümanları değiştirmeye karar verirsem, imlecin nerede gösterileceğini söylemediğimde, bazen istemin ortasında, ancak genellikle yazdığım yerin üstünde .

UpÖnceki bir komuta geldiğimde ek eğlence oluyor . Bunu hem gnome terminalinde hem de sonlandırıcıda, i3 ve Tarçın'da denedim. Birisi benim istemi olduğunu önerdi, işte burada:

\[\033[01;32m\]\u:\[\033[01;34m\] \W\033[01;34m \$\[\033[00m\]

Ctrll, resetve clearhepsi ne diyorlarsa onu yapın, ancak komutu geri yazdığımda veya Upaynı şeyler oluyor.

Kontrol ettim ve checkwinsizebash olarak etkinleştirildi. Bu 80x24 ve diğer pencere boyutlarında olur.

Bu sadece yaşamayı öğrendiğim bir şey mi? Bilmem gereken bir sihir var mı? Sadece kısa bir bilgi istemi kullanmaya karar verdim, ancak bu sorunu çözmedi.


1
Yani komutu kullanarak env -i bash --norconu düzeltir. $ COLUMNS ve $ LINES eşleşiyor. Bu benim .bashrc ile komik bir şey olduğu anlamına mı geliyor?
Muricula

Bu yüzden .bashrc'imi yorumladım ve sorunumu, özellikle de söz konusu renklendirme sözdizimini sorunlu kısım olarak sorardım. Yukarıdaki PS1'in nesi var?
Muricula

1
\[\033[01;32m\]\u: \[\033[01;34m\]\W \[\033[01;34m\] \$ \[\033[0m\]o ... tamamen orijinal istemini saygı ama eğer bilmiyorsanız - davranışlarında tuhaflık önlemek gibi görünüyor

1
Gereğince ServerFault bu cevap , kullanmaktput smam
Samveen

Yanıtlar:


189

Yazdırılamayan dizilerin içinde \[ve içine\] alınması gerekir . PS1'inize baktığınızda, açıklanamayan bir diziye sahiptir \W. Ancak, ikinci giriş önceki "1; 34" ifadesini tekrarladığı kadar gereksizdir .

\[\033[01;32m\]\u:\[\033[01;34m\] \W\033[01;34m \$\[\033[00m\]
                  |_____________|               |_|
                         |                       |
                         +--- Let this apply to this as well.

Gibi bu amaçlanan renklendirme olmalı:

\[\033[1;32m\]\u:\[\033[1;34m\] \W \$\[\033[0m\]
                               |_____|
                                  |
                                  +---- Bold blue.

"Orijinal" i saklamak da işe yaramalı:

\[\033[1;32m\]\u:\[\033[1;34m\] \W\[\033[1;34m\] \$\[\033[0m\]
                                  |_|         |_|
                                   |           |
                                   +-----------+-- Enclose in \[ \]

Düzenle:

Davranışın nedeni bash, istemin gerçekte olduğundan daha uzun olduğuna inanmasıdır. Basit bir örnek olarak, eğer kullanıyorsanız:

PS1="\033[0;34m$"
       1 2345678

İstemin 8 karakter olduğuna ve 1 değil olduğuna inanılır. Terminal penceresi 20 sütunsa, 12 karakter yazdıktan sonra 20 olduğuna inanılır ve etrafına sarılır. Bu da, eğer biri geri adım atmaya çalışırsa, ya da açıktır Ctrl+u. Sütun 9'da durur.

Bununla birlikte, son sütunda olmadıkça yeni satır başlatılmaz, sonuç olarak ilk satırın üzerine yazılır.

Biri yazmaya devam ederse satır 32 karakterden sonra bir sonraki satıra sarılmalıdır.


Eğer orjinal sekansta tam olarak neyin tekrarlanmasına neyin sebep olduğu konusunda bir açıklamanız varsa, bunu bilmek isterim. Ayrıca bunu görsel olarak nasıl gösterdiğiniz için +1.

1
@ illuminÉ: Kaynağa bakmadım, ancak gözlemdeki davranışları not alan bir güncelleme eklendi.
Runium

Herhangi bir sorunla karşı karşıya kalmanız durumunda, bu web sitesini yeni bir tane oluşturmak için kullanabilirsiniz - bashrcgenerator.com
divinedragon 11:15

Bu şaşırtıcı, teşekkür ederim @Runium - bunu nasıl bildiğini paylaşır mısın? Bununla ilgili bazı belgeler bulmayı çok isterim.
nycynik

2
@ nycynik: Gözlem. Sanırım bu belgelere en yakın olan kaynak kodudur ...
Runium

83

Çoğunlukla terminal tarafından kabul edilen pencerenin boyutuyla ilgisi gerçek pencere boyutunuzla aynı değildir. Bash kullanıyorsanız, bunu deneyebilirsiniz.

$ shopt checkwinsize

Eğer alamazsan

checkwinsize    on

Ardından ile etkinleştir

$ shopt -s checkwinsize

Sonra başka bir komutu çalıştırmayı (gibi ls) veya pencereyi bir kez yeniden boyutlandırmayı deneyin, yukarıdaki her zaman benim için çalışır.

Özellikle Redhat sistemleri için, sorun genellikle misconfiguring kaynaklanır ~/.bashrcaramamamı /etc/bashrc. Normalde, varsayılan olarak içerdiği, ~/.bashrcçağrılması beklenen bash yükleri ./etc/bashrcshopt -s checkwinsize


OS X ile aynı problemi yaşadınız, görünüşe göre terminalinizi başlatmak için "login" ı çağırırsanız, / etc / bashrc okuyan bir şekilde bash başlar, ancak doğrudan bash çağırırsanız, ~ / .bashrc yazmaz. kaynakların varsayılan olarak kaynaklanmasını sağlar, böylece tuhaf sarma efekti elde edersiniz. Teşekkürler!
rogerdpack 11:15

Bu benim için de işe yaradı. Bu sunucuda renkler açık değildi, doğru diyorlardı /etc/bashrc, her şey yolunda gidiyordu ... ortaya çıktı, bu sargılama sorunlarının nedeni.
dhaupin


İyi bir çözüme benziyor. Fakat bu benim ssh oturumumda çalışmıyor. Emin değilim neden. Komutu shopt -s checkwinsizessh oturumunda çalıştırdım . Ancak sarma devam ediyor.
Qiang Xu,

Bu kesinlikle benim sorunumdu - bir kullanıcı .bashrc / etc / bashrc'yi çağırmıyordu ve bu yüzden karışıklık yaratıyordu.
Sobrique

9

Diğer cevaplarda belirtildiği gibi, yazdırılamaz dizilerin \e[0;30msarılması gerekir \[...\].

Ayrıca (ve ne henüz söz görmüyorum) öyle görünüyor olduğunu \r\nolmalı dışında bir \[...\]bir çok satırlı istemini varsa. Sonunda bunu anlamak bana biraz deneme yanılma aldı.


8

Bir keresinde okumuştum (burada artık bilmiyorum) kullanarak o \001ve \002yerine \[ve \]bu sorunu çözebilir. Benim için yaptı.

Bu arada, PS1'i tanımlamanın çirkin görünmesi gerekmez.

green="\001$(tput setaf 2)\002"
blue="\001$(tput setaf 4)\002"
dim="\001$(tput dim)\002"
reset="\001$(tput sgr0)\002"

PS1="$dim[\t] " # [hh:mm:ss]
PS1+="$green\u@\h" # user@host
PS1+="$blue\w\$$reset " # workingdir$

export PS1
unset green blue dim reset

2
PS1'im, OP'nin sorununa neden olan printf escape dizilerinin çalıştırıldığı bir komutu çağırıyor. Sadece bu çözüm benim için sorunu çözdü.
RickMeasham

6

Bu, COLUMNS& LINESortam değişkeni ayarlarınızla ilgili bir sorun gibi görünüyor . Pencereyi yeniden boyutlandırdığınızda, genellikle gnome-terminali tarafından otomatik olarak ayarlanırlar (inanıyorum), komutu vererek onları manuel olarak ayarlamaya zorlayabilirsiniz resize.

Örnek

GNOME terminalimi 79x17 olarak yeniden boyutlandırırsam değişkenlerim şöyle görünür:

$ echo $COLUMNS; echo $LINES
79
17

Öyle zorlayabilirim:

$ resize
COLUMNS=79;
LINES=17;
export COLUMNS LINES;

1
İlginç, ama yardımcı olmuyor.
Muricula

1
Bu benim sorunumu düzelttikten sonra "ekran" komutunu çalıştırdıktan sonra satırların doğru şekilde sarılmaması sorunu giderildi. Teşekkürler!!
nukeguy


3

Ayrıca aynı sorun, geniş unicode sembolleri kullanılarak da meydana gelebilir ( https://stackoverflow.com/a/34812608/1657819 adresindeki gibi ). Soruna neden olan pasajı burada (dikkat edin $Greenve $Reddoğru şekilde renk dizgileriyle silinir):

FancyX='\342\234\227'
Checkmark='\342\234\223'


# Add a bright white exit status for the last command
PS1="$White\$? "
# If it was successful, print a green check mark. Otherwise, print
# a red X.
if [[ $Last_Command == 0 ]]; then
    PS1+="$Green$Checkmark "
else
    PS1+="$Red$FancyX "
fi

Bash uzunluğu doğru hesaplayamaz, bu yüzden en kolay yol bu geniş sembollerin üç bölümünden 2'sinden kaçmak olabilir.

FancyX='\[\342\234\]\227'
Checkmark='\[\342\234\]\223'

Mantıklı. Sanırım bash karakterleri sayar. X bir karakter alır ancak 3 olarak yazılırsa, saymayı düzeltmek için birinin 2 tanesini içine alması gerekir. @blauhirn cevabı ayrıca \001ve ile bir fonksiyonda nasıl yapılacağını açıklar \002.
akostadinov

Bilginize, bu şekilde çok baytlı unicode karakterlerin nasıl çıktılanacağını bu şekilde
çözersiniz
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.