it-swarm-tr.com

Bir terminalde yanlışlıkla Ctrl-S'ye bastıktan sonra nasıl çözülür?

Bu benim için oldukça sık olan bir durum: düğmesine bastıktan sonra (farklı bir niyetle) Ctrl-S bir terminalde, onunla etkileşim (giriş veya çıkış) dondurulur. Muhtemelen bir çeşit "kaydırma kilidi" ya da her neyse.

Bundan sonra terminali nasıl çözerim?

(Bu sefer apt-Shell içinde bash içinde urxvt-- özel kullanımından hangisinin sorumlu olduğundan emin değilim Ctrl-S: Komutların geçmişini geriye doğru C-r, her zamanki gibi readline için, ama sonra her zamanki gibi - en azından Emacs'ta- tarih boyunca "geri" gitmek istedim.C-s ( 1 , 2 , ), ama bu terminalin donmasına neden oldu. Geçmiş şeyleri görüntülemek için kaydırma/sayfalama terminalde hala çalışıyor, ancak orada çalışan işlemlerle etkileşim yok.)

Ctrl-Q

Bunu tamamen devre dışı bırakmak için stty -ixon bir başlangıç ​​komut dosyasında. Herhangi bir anahtarın işlerin tekrar akmasını sağlamak için stty ixany.

ps: Bunu yapan terminal veya Shell değil, işletim sisteminin terminal sürücüsü.

924
ak2

Ctrl-Q gerçekten de cevap. ak2'nin doğru cevabı kenar boşluklarına sığmayacak kadar uzun bir tarih yazacağımı sanıyordum.

Karanlık çağlarda, bir terminal uzun bir kablo üzerinden veya modemli telefon hatları aracılığıyla uzak bir cihaza bağlanan büyük bir ekipmandı (başlangıçta başka bir terminal çünkü teletiplerin bir telgraf anahtarından daha kolay öğrenilmesi daha kolaydı). Unix geliştiğinde, ASCII kodu zaten iyi bir şekilde oluşturulmuştur (IBM'in rakip EBCDIC kodu hala dikkate alınması gereken bir güç olmasına rağmen).

İlk terminaller alınan her karakterin yazılı kaydını tuttu. Karakterler en azından yazdırma kafasının yazabileceğinden daha hızlı gelmedikçe. Ancak CRT tabanlı terminaller mümkün olur olmaz, sorun sadece yaklaşık 25 satırın CRT'ye sığması ve 80 karakterden oluşan 25 satırın yeterince temsil ettiği ortaya çıktı RAM kimsenin daha fazlasını sağlama konusunda ciddi düşünmediği = RAM.

Bu nedenle, gönderen ucun, okuyucunun yetişmesini sağlamak için duraklaması gerektiğini bildirmek için bazı kurallara ihtiyaç vardı.

7-bit ASCII kodunun kontrol karakterlerine ayrılmış 0 kod noktası vardır (0 ila 31 ve 127). Bunlardan bazıları NUL (boş) diş çekme, boşluklar ve ekler için kağıt şerit lideri), DEL (yedi deliğin tümünü delme ile gösterilen kağıt şerit üzerindeki "çarpı işareti" karakterler), BEL (Ding!), CR, LF ve TAB.Ancak dördü terminal aygıtının kendisini kontrol etmek için açıkça tanımlandı (DC1 ila DC4 aka Ctrl + Q, Ctrl + R, Ctrl + S ve Ctrl + T).

Benim en iyi tahminim, bazı mühendislerin (anımsatıcılar gittikçe), "Durdur" için "S" ve "Devam" için "Q" ifadelerinin çok kötü olmadığını ve DC3 "lütfen göndermeyi durdur" ve DC1 "Tamam, şimdi göndermeye devam et" anlamına gelir.

Bu kongre bile Unix'in dünyaya çıkmak için Bell Labs'ta yuvadan ayrılmasından çok önce kurulmuştu.

Kural, yazılım akış kontrolü olarak bilinir ve gerçek seri cihazlarda son derece yaygındır. İletişim kanalında başka herhangi bir amaç için bu karakterlerden herhangi birinin kullanılmasını önlediğinden ve alıcı uçtan daha fazlasını göndermekten kaçınmak için durma sinyalinin bekleyen herhangi bir karakterden önce ele alınması gerektiği için doğru bir şekilde uygulanması kolay değildir. üstesinden gelmek.

Pratik ise, akış kontrolü için seri veri akışından bant dışı ek sinyaller kullanılması büyük ölçüde tercih edilir. Ek sinyal kablolarını sağlayabilen doğrudan kablolu bağlantılarda, bu karakterleri diğer kullanımlar için serbest bırakan donanım el sıkışmasını bulacaksınız.

Tabii ki, bugünün terminal penceresi gerçek bir fiziksel seri port kullanmıyor, kaydırma çubuklarına sahip ve gerçekten yazılım el sıkışmalarına ihtiyaç duymuyor. Ancak sözleşme devam ediyor.

Richard Stallman'ın emacs'ın ilk sürümlerinde artımlı aramaya Ctrl + S eşlemesi hakkında şikayetler aldığını ve 7 bitlik, yazılım akışı kontrollü bir bağlantıya bağımlı olması gereken herhangi bir kullanıcıya oldukça duyarsız olduğunu iddia ediyorum.

412
RBerteig