Come eliminare i fastidi all'avvio di una GUI da un terminale?

Preferisco avviare le applicazioni della GUI da una finestra del terminale piuttosto che usando un desktop grafico. Un fastidio frequente è che spesso gli sviluppatori non hanno previsto questo tipo di utilizzo, quindi l'app stampa molti messaggi inutili, criptici o non informativi su stdout o stderr. Un ulteriore disordine sul terminale si verifica perché l'esecuzione del programma in background, con un &, genera rapporti sulla creazione e la conclusione del lavoro.

Che cosa è una soluzione alternativa per questi problemi che accettano argomenti della riga di comando e gestiscono il completamento automatico?

Correlati: /programming/7131670/make-bash-alias-that-takes-parameter

Reindirizzare immediatamente l'errore standard a /dev/nullè una cattiva idea in quanto nasconderà i primi messaggi di errore e gli errori potrebbero essere difficili da diagnosticare. Suggerisco qualcosa come il seguente start-appscript zsh:

#!/usr/bin/env zsh
coproc "$@" 2>&1
quit=$(($(date +%s)+5))
nlines=0
while [[ $((nlines++)) -lt 10 ]] && read -p -t 5 line
do
  [[ $(date +%s) -ge $quit ]] && break
  printf "[%s] %s\n" "$(date +%T)" "$line"
done &

Basta eseguirlo con: start-app your_command argument ...

Questo script genererà al massimo 10 righe di messaggi e per un massimo di 5 secondi. Si noti tuttavia che se l'applicazione si blocca immediatamente (ad esempio a causa di un errore di segmentazione), non verrà visualizzato alcun messaggio di errore. Ovviamente, puoi modificare questo script in vari modi per fare quello che vuoi ...

Nota: per far funzionare i completamenti con start-appin zsh, è sufficiente:

compdef _precommand start-app

e in bash:

complete -F _command start-app

(copiato da quello per exece timein /usr/share/bash-completion/bash_completion).

Questa risposta è per bash. Ad esempio, ecco cosa faccio nel mio .bashrc per eseguire un comando pratico evper avviare il visualizzatore PDF Evince.

ev() { (evince "$1" 1>/dev/null 2>/dev/null &) }
complete -f -o default -X '!*.pdf' ev

La prima riga definisce una funzione ev. Il nome di una funzione verrà riconosciuto quando lo si utilizza dalla riga di comando in questo modo:

ev foo.pdf

(Questo è un meccanismo diverso dagli alias e ha una priorità inferiore.) L'output di Evince su stdin e stdout viene inviato al bitbucket (/ dev / null). La e commerciale mette il lavoro in secondo piano. Il comando racchiuso tra parentesi fa sì che venga eseguito in una subshell in modo che non stampi messaggi sulla creazione del lavoro in background o sul suo completamento.

La seconda riga del mio .bashrc usa la funzione completa di bash per dire a bash che l'argomento del comando ev dovrebbe essere un file con l'estensione pdf. Questo significa che se ho anche i file foo.tex, foo.aux, ecc., Nella mia directory, posso digitare ev fooe premere il tasto Tab e Bash saprà completare il nome del file come foo.pdf.

Un'altra possibilità è quella di usare commandper passare execda un builtin speciale ad un semplice vecchio build come:

alias shh='command exec >/dev/null 2>&1'

Quindi ora puoi fare:

(shh; call some process &)

Ho appena notato che commandnon funziona zsh (come sembra fare nella maggior parte delle altre shell) , ma dove invece non funziona puoi invece fare:

alias shh='eval "exec >/dev/null 2>&1"'

... che dovrebbe funzionare ovunque.

In effetti, potresti persino fare:

alias shh='command exec >"${O:-/dev/null}" 2>&1'

Quindi potresti fare:

O=./logfile; (shh;echo can anyone hear &)
O=; (shh; echo this\? &)
cat ./logfile

PRODUZIONE

can anyone hear

Dopo una discussione di commento con @ vinc17, vale la pena notare che quasi tutto l'output della console di un'app GUI è generalmente destinato a Xtty - la sua console. Quando esegui Xun'app da un X .desktopfile, l'output che genera viene instradato al Xterminale virtuale, che è qualunque sia il tty da cui è stato lanciato Xin primo luogo. Posso indirizzare questo numero tty con $XDG_VTNR.

Stranamente però - e forse perché ho appena iniziato a usare startx- non riesco più a scrivere /dev/tty$XDG_VTNR. Questo potrebbe anche (come penso sia più probabile) avere qualcosa a che fare con il cambiamento molto recente e drastico implementato con Xorgv1.16 che gli consente di funzionare in una systemdsessione utente piuttosto che richiedere i privilegi di root .

Tuttavia, posso fare:

alias gui='command exec >/dev/tty$((1+$XDG_VTNR)) 2>&1'

(gui; some x app &)

Ora tutto l' some x appoutput della console viene instradato /dev/tty$((1+$XDG_VTNR))piuttosto che il mio xtermpty. Posso ottenere l'ultima pagina di questo in qualsiasi momento come:

fmt </dev/vcs$((1+$XDG_VTNR))

Probabilmente è buona prassi dedicare comunque un terminale virtuale per registrare l'output. /dev/consoleè generalmente già riservato per questo, anche se potresti preferire di non fare chownciò che è probabilmente necessario per poterti scrivere allegramente. Potresti avere una funzione che ti consente di fare un printk- che sostanzialmente sta stampando su /dev/console- e quindi potrei usarlo in questo modo suppongo.

Un altro modo per farlo sarebbe quello di dedicare un po ' a tali scopi. Ad esempio, è possibile mantenere xtermaperta una finestra, salvare l'output di ttyquando eseguito da lì in una variabile di ambiente e utilizzare quel valore come destinazione per guil'output di. In questo modo tutti i registri verrebbero instradati verso una finestra di registro separata, che è quindi possibile scorrere se desiderato.

Una volta ho scritto una risposta su come una cosa simile potrebbe essere fatta con la bashstoria, se ti interessa.