Tamamlanmış bir terminal komutundan önceki tüm çıktıları nasıl görebilirim?


0

Gnome terminalinde terminale beklediğimden daha fazla çıktı alan bir komut çalıştırdım. Çıktının tamamını okumak istiyorum, ancak terminal kaydırma başlangıcına gelmeden önce duruyor.

Sınırsız kaydırmayı etkinleştirmek veya çıktıyı bir dosyaya aktarmak, vb. İçin terminal profili ayarlarını değiştirebileceğimi anlıyorum. gelecek Bununla birlikte, çıktı.

Daha önce yürütülen bir komutun tam terminal çıktısını nasıl görebilirim?

Düzenleme: Tamam, yapılamaz. Herkese teşekkürler!


1
Almak mümkün olduğunu sanmıyorum.
Matei David

1
@MateiDavid haklı, dosya sisteminde STDOUT geçmişi yok. Terminaliniz için günlüğe kaydetme etkin değilse, o zaman şansınız kalmaz.
sebastienvg

Bu doğru, kurtarılamaz. (Yapılandırılmış daha küçük bir değere sahip olsa bile iyileşmek mümkün olsaydı, böyle bir ayar olmazdı ve gnome-terminali her zaman çıktının tamamını hatırlardı.)
egmont

1
Kesinlikle doğru olmak için: Silinen bir dosyanın içeriğini almak bazen mümkün olabilir. belki Bu g-t'yi kullanmayı bıraktıysanız (ancak açık tutun) ve dosyalarını incelemeniz durumunda bu içeriklerden biraz daha fazlasını elde etmek mümkün olabilir. Scrollback şifrelemeli vte-0.40'ta bu daha da zorlaştı ama bazı durumlarda hala belki mümkün olsa da, buna değmeyeceğine eminim. (Önce banka hesabıma makul bir miktar aktarıp ardından bilgisayarınıza erişim izni verirseniz bakabilirim - sadece şaka: D)
egmont

(Scrollback şifrelemesi hakkında bir not: Şifresini çözmek için, anahtarın gnome-terminal sunucusu işlem hafızasına yerleştirilmesi gerekir. Gnome-terminalinden çıktıktan veya söz konusu sekmeyi kapattıktan sonra, anahtar iyi bir şekilde kaybolur.)
egmont

Yanıtlar:


1

Deneyimlerim, yorumlardaki fikir birliğinin doğru olduğu - terminalin arabelleği aşıldıktan sonra, verilerin kaybolduğu (ya da - o kadar iyi - muhtemelen henüz üzerine yazılmamış bellekte olabilir) - ve bu nedenle tampon boyutunu geriye dönük olarak artıramaz.

Bu cevap, yorumunuzla, bir cevapla ve durumunuz için muhtemelen fazladan bir şey arasında sınırda. Durumunuza hitap edebilecek daha çok önerilen bir yaklaşımdır - özellikle çok geç olmadan loga ihtiyacınız olduğunu bilmeme problemi (nedensel olmayan problemler zordur) ancak sorunuzun doğrudan bir cevabı değildir.

Her durumda, yorum yapmak için çok uzun oldu. Bu yaklaşımı uygulamak için gereken tüm kodları açıkça listelemiyorum, çünkü yapılması gereken birçok uygulama kararı var; daha ayrıntılı bilgiye ihtiyacınız varsa, bunu sağlamaktan memnuniyet duyarım.

Script başa çıkmak hoş değil

İlk olarak script Yardımcı programın arabellek boyutunu artırmadan veri kaybını önlemek için bir 'stopgap' olarak önerildiği (bunun sınırsız olarak ayarlandığında güvenlik etkileri olduğu) önerildi. Bazı TLC’ye ihtiyaç duyan bir yardımcı program varsa, script bu mu. Sonra tekrar, çekirdek ekibi tarafından geliştirildi. Bunu istediğin gibi oku.

buldum script sık sık değerinden daha fazla sorun olmaktan (onu yarı-insan tarafından okunabilir hale getirmek için işleme koyduktan sonra işlemek gibi) ve bunun yerine stdout, stdin ve / veya stderr'i kaydetmek için basitleştirilmiş bir yöntem kullanmaya başlamıştır. Bir anlamda bu, senaryoyu yeniden yaratıyor ama kodlanmışın insafına kalmak yerine tam kontrolle script kayıt ayarları.

Bu yaklaşım, kabuk oturumlarınıza nispeten sorunsuz bir şekilde entegre olabilir ve nadir durumlarda terminal arabelleğini taşarsanız, bu içerikleri içeren geçici bir dosya elde edersiniz. Kaydı “temiz” tutmak için ele almanız gereken bazı temizlik adımları vardır. Ek olarak, aynı güvenlik sorunları (tüm terminal çıkışlarının günlüğü) varsayılan olarak mevcut olacaktır; Ancak günlükleri şifrelemek için basit bir yöntem var.

3 temel adım vardır:

  1. Yönlendirmeyi stdout'u (ve istenirse stderr'i) bir dosyaya ve terminale bölecek şekilde yapılandırın. Bu örneği basit tuttum ve stdin veya stderr'i dosyaya yönlendirmiyorum - ancak stdout yönlendirme örneğini anlarsanız gerisi önemsizdir.
  2. .Bashrc dosyasını bir kabuk açıldığında bu günlük kaydı başlatmak için yapılandırın.
  3. Belirli bir kabuk kapanırken bash yerleşimini kullanın TRAP oturum günlüğünü sonlandıracak kullanıcı kodunu aramak için (dosyayı silebilir, arşivleyebilir vb.)

Bu yaklaşımla, belirli bir kabuk oturumunun tüm geçmişini görmenize izin verecek görünmez bir güvenlik ağına sahip olacaksınız (yönlendirdiklerinizi temel alarak - tekrar, sadece stdout'u gösterdiğim şeyleri basitleştirmek için); İhtiyacın olmadığında orada olduğunu bile bilmemelisin.

ayrıntılar

1. Yönlendirmeyi Yapılandırma

Aşağıdaki kod parçacığı, bir günlük dosyasına işaret eden bir dosya tanımlayıcısı 3 oluşturacaktır. stdout, 3'e yönlendirilir ve teedaha sonra bu akımı terminale geri böleriz (stdout'a eşdeğer). Aynı komut / log dosyasına stderr'i önemsiz şekilde ekleyebilir, farklı bir dosyaya bağlayabilir veya olduğu gibi bırakabilirsiniz.

logFile=$(mktemp -u)
exec 3>&1 1> >(tee $logFile >&3)
  • Bu günlük dosyasını komut dosyası tarafından oluşturulandan daha temiz bulursunuz; geri alanları, satır beslemeleri ve sıklıkla istenmeyen diğer özel karakterleri saklamaz.

  • LogFile'nin şifrelenmesini istiyorsanız, tee komutundan sonra ek bir boru aşaması ekleyerek bunu oldukça kolay bir şekilde yapabileceğinizi unutmayın. openssl .

2. Günlük üretimini otomatikleştirin

.Bashrc içinde yukarıdaki ile aynı kodu ekleyin. Her yeni bir kabuk oluşturulduğunda, o oturuma özel bir günlük dosyası oluşturulur.

export logFile=$(mktemp -u)
exec 3>&1 1> >(tee $logFile >&3)
echo "Current session is being logged in $logFile"

3. Kabuk kapanırken günlüğü otomatik olarak kapat

Oturum bittiğinde günlük dosyasının silinmesini istiyorsanız, bash yerleşikini kullanabilirsiniz. trap oturumu saptama işlevi sona eriyor ve günlük dosyasına yönelik bir işlev çağırın (örneğin .bashrc içinde).

trap closeLog EXIT

closeLog () {
  rm -f "$logFile" >/dev/null 2>&1
}

Oturum günlüğü temizleme işlemi birçok farklı yolla gerçekleştirilebilir. Bu yaklaşım, 'çıkış' sinyalini yakalayarak kabuk kapandığında çağrılacaktır. Bu noktada, günlük dosyasını silebilir, taşıyabilir / yeniden adlandırabilir veya herhangi bir Temizlenecek çok şey var. Ayrıca günlük dosyalarına sahip olabilirsiniz. TRAP yerine bir cron işi tarafından temizlenir (eğer bu yaklaşım kullanılıyorsa, / tmp dizini için yapılandırılmış bir diziniz yoksa periyodik bir temizleme görevi öneririm; sanki bash kabuğu EXIT tuzağı çöküyorsa) tetiklenmeyecek).

Alt kabuklarla ilgili not

Deniz kabukları ile ilginç bir durum ortaya çıkacaktır. Mevcut olanın üstünde yeni bir etkileşimli kabuk açılırsa, yeni bir günlük oluşturulacak ve her şey yolunda gitmeli. Bu kabuktan çıkıldığında (ana öğeye dönüş), bu dosyaya giriş devam eder. Bunu daha net bir şekilde ele almak istiyorsanız - belki de alt kabuklar için ortak bir günlük tutma bile olsa (etkileşimli veya başka şekilde), yuvalanmış bir alt kabukta olduğunuzu saptamanız (.bashrc'de) ve ana öğenin günlük dosyasına yönlendirmeniz gerekir yeni bir tane yaratıyorum. Ayrıca, bir "alt tuzak" olup olmadığınızı da kontrol etmeniz gerekir; böylece 'tuzak' çağrınız ebeveynin günlük dosyasını çıkışta silmez. Yuvalanmış kabuk seviyesini, kabuk istifinizin 'derinliğini' depolayan bash çevre değişkeni SHLVL'den alabilirsiniz.

Günlüğünüzü 'temiz' tutmaya dikkat edin:

Stdin dosyasını log dosyasına yönlendirirseniz, script yardımcı programı tarafından oluşturulan birçok istenmeyen eserle sonuçlanır. Bu, yeniden yönlendirme ve dosya arasına bir filtre aşaması (örneğin sed / grep) eklenerek giderilebilir. Basitçe, oturum açmak istemediğiniz herhangi bir şeyi kaldıran bir regex oluşturun. Tamamen temizlemek için biraz derinlemesine işlem gerekir (belki de dosyaya yazmadan önce her yeni satırı tamponlamak, onu temizlemek ve yazmak). Aksi takdirde, bir geri toplamanın ne zaman 'çöp' olduğunu veya ne zaman tasarlandığını bilmek zor olacaktır.


Çözümünüzün stdout'un bir tty olarak algılanmamasına neden olduğunu unutmayın ( [ -t 1 ] döner false ). Elbette bu kafa karıştırıcı bulabilecek programlar var.
Matei David

genel olarak .bashrc, başlatılmadan önce etkileşimli bir kabuğa kaynaklanıp kaynaklanmadığını kontrol eder; bu nedenle sorunlu olacağı çoğu durumda (scp, vb. etkileşimli olmayan uzak bağlantılar) sorun olmazdı. Yine de bir şeyi kırması tamamen mümkün. Görmedim, fakat tmux gibi bir programın çöküp yanabileceğini tahmin ediyorum. Yine de, uzak bağlantılarla veya tmux gibi uygulamalarla kesinlikle çalışmayan komut dosyalarından daha iyidir. Açıklama - komut dosyası uzaktan çalışacak, ancak oluşturulan günlük dosyası korkunç.
Argonauts

Bu mükemmel bir analiz, teşekkür ederim!
JonahHuron
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.