roslin

Ciapcie widziałem już w różnych miejscach, ale tutaj pojawiła się zupełnie jak hiszpańska inkwizycja.

Ciekawy post loudmaxa, cytuję w całości:

Here's my prompt string:

PS1='\[\033[01;32m\]\u@\[\033[01;31m\]\h[\w]:`if [[ $? != 0 ]]; then echo "( "; else echo ") "; fi`\[\033[00m\]'

If the previous command succeeds it shows me it's happy:

user@host[~]:) /bin/true 
user@host[~]:)

If the previous command fails, it's sad:

user@host[~]:) /bin/false 
user@host[~]:(

Oczywiście całą magię robi ta linijka:
:`if [[ $? != 0 ]]; then echo "( "; else echo ") "; fi`

Mój prompt już się do mnie uśmiecha. (:

Poszukując sposobów na powiększenie e-penisa trafiłem na temat TIP: Send SMS alerts when emerge completes. Autor, timeBandit, robił spory update (>500) pakietów i wkurzył się, kiedy mersja poległa któryś-tam-raz z rzędu chwilę po tym jak odszedł od komputera. Postanowił więc zrobić sobie powiadomienia, które dostanie, jeżeli proces będzie wymagał niańczenia. (;

Powyższy poradnik zakłada, że mamy zainstalowane:

• Klienta mailx (mail-client/mailx), aby wysyłać maile prosto z linii poleceń.
  
• MTA (mail transfer agent) by mógł go użyć mailx¹ - jak postfix, sendmail lub ssmtp.
  

Cały skrypt, który musi być uruchomiony zaraz po emerge, wygląda tak:

~/bin/emobalert

#!/bin/sh 
# Record exit status of emerge--must precede ALL other commands! 
[ $? -eq 0 ] && RESULT="PASS" || RESULT="FAIL" 

# Change next line to your mobile/SMS address 
SMS_ADDR="123456789@fajna.bramka.sms" 

LAST_PKG="$(tac /var/log/emerge.log | awk '$2 == ">>>" {print $4,$5,$6,$7; exit;}')" 
CFG_MODS="$(find /etc -iname '._cfg????_*' | wc -l)" 

mail -s"Emerge Completed" $SMS_ADDR <<-EOM 
   ${RESULT} ${LAST_PKG} 
   ::: 
   ${CFG_MODS} config updates pending 
   $* 
EOM

Musisz oczywiście odpowiednio zmienić SMS_ADDR² i zrobić skrypt wykonywalnym. Jeżeli twój numer telefonu jest poufny zadbaj o odpowiednie prawa dostępu.

Używanie skryptu to bułka z masłem:

emerge -uDv world; emobalert

To wszystko! Pamiętaj, że skrypt musi się odpowiednio uruchomić po emerge, by mógł odczytać jego exit status (zawsze używaj średnika, nigdy && czy || jako połączenia potoków).

Po zakończeniu emerge dostaniesz wiadomość:

From: root@localhost.localdomain 
(Emerge Completed) 
PASS (2 of 2) app-crypt/seahorse-2.22.3 
::: 
0 config updates pending

Można tu odczytać ostatni ebuild, który był instalowany, czy proces zakończył się sukcesem/porażką i czy czekają cię jakieś pliki konfiguracyjne do aktualizacji. Argumenty dopisane do emobalert w linii poleceń zostaną dołączone do wiadomości.

___
¹ Tutaj miałem pewien problem, ponieważ mailx nie chciał współpracować z obecnym u mnie nbsmtp. Udało się to jednak obejść.
² Szczerze mówiąc nie orientuję się jak wygląda sytuacja we wszystkich sieciach. W Plusie wysłanie wiadomości jest bardzo proste, wystarczy w polu SMS_ADDR wpisać +48mójnumertelefonu@text.plusgsm.pl i dostaniemy piękne powiadomienie
³ Zmiany przy nbsmtp nie były wielkie, korzystam z mutt i postanowiłem użyć go do odwalenia za mnie brudnej roboty. Koniec skryptu u mnie wygląda mniej więcej tak:
su -c "echo \"${LAST_PKG} ::: ${CFG_MODS} config updates pending.\" | mutt -s \"Emerge ${RESULT}\" $SMS_ADDR" - nazwa_użytkownika

Kolejny mały test. Tym razem to jakaś fikuśna kieszeń na 2.5" dysk twardy. Różowe, cieniutkie, chyba aluminiowe, opakowanie w etui z czarnej skóry (lub czegoś skórobodobnego ;). Po podłączeniu wygląda to tak:

# dmesg
usb 2-2: new high speed USB device using ehci_hcd and address 2
usb 2-2: configuration #1 chosen from 1 choice
scsi8 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
scsi 8:0:0:0: Direct-Access     HTS54104 0G9AT00          \
    MB2O PQ: 0 ANSI: 0 CCS
sd 8:0:0:0: [sdc] 78140160 512-byte hardware sectors (40008 MB)
sd 8:0:0:0: [sdc] Write Protect is off
sd 8:0:0:0: [sdc] Mode Sense: 00 14 00 00
sd 8:0:0:0: [sdc] Assuming drive cache: write through
sd 8:0:0:0: [sdc] 78140160 512-byte hardware sectors (40008 MB)
sd 8:0:0:0: [sdc] Write Protect is off
sd 8:0:0:0: [sdc] Mode Sense: 00 14 00 00
sd 8:0:0:0: [sdc] Assuming drive cache: write through
 sdc: sdc1
sd 8:0:0:0: [sdc] Attached SCSI disk
sd 8:0:0:0: Attached scsi generic sg2 type 0
usb-storage: device scan complete

Ktoś sprytny i spostrzegawczy na pewno zauważył, że sprzęt na komputerowym końcu kabla ma dwie wtyczki USB. Dlaczego? Nie mam bladego pojęcia. Jedno jest dla dodatkowego zasilania? Lub może dla stabilizacji zasilania? Ciężko powiedzieć, hdparm (wiem wiem, to nie benchmark) dawał praktycznie takie same wyniki niezależnie od ilości podłączonych wtyczek. lsusb i "dmesg" również nie dodawało nic przy wetknięciu drugiej wtyczki.

# lsusb
Bus 002 Device 002: ID 04cf:8818 Myson Century, Inc. \
    USB2.0 to ATAPI Bridge Controller

# hdparm -tT
 Timing cached reads:   1858 MB in  2.00 seconds = 929.21 MB/sec
 Timing buffered disk reads:   60 MB in  3.04 seconds =  19.73 MB/sec

Wpadł mi dziś w RSS "miesięcznik" Gentoo. Mam wrażenie, że od kiedy odszedł "tygodnik" strasznie tam wieje nudą. Zamiast odsyłaczy do bugzilli porobili jakieś... wykresiki. Podejrzewam w tym przykrywkę dla nic-nie-robienia.

Zaciekawił mnie po raz kolejny bugday. I, również po raz kolejny, rozczarował. Miałem nadzieję, że może w końcu trafi tu jakiś ciekawy bug związany z gentoo-games. Tymczasem, chyba po raz czwarty czy piąty z rzędu, "Randomly selected open bugs" są identyczne! Niedawno wszyscy się śmiali z Debiana i jego generatora liczb losowych, więc co powiedzieć o tym? Czyżby bugzilla Gentoo stała na niezałatanym Debianie? (;