ターミナルからGUIを起動するときに煩わしさを解消する方法は？

グラフィカルデスクトップを使用するよりも、ターミナルウィンドウからGUIアプリケーションを起動することを好みます。頻繁に迷惑なのは、開発者がこのタイプの使用を予期していないことが多いため、アプリは多くの役に立たない、不可解な、または情報のないメッセージをstdoutまたはstderrに出力することです。バックグラウンドでプログラムを実行し、＆を付けてジョブの作成と終了のレポートを生成するため、ターミナルでさらに混乱が生じます。

コマンドライン引数を受け入れ、オートコンプリートを処理するこれらの問題の回避策は何ですか？

関連：https : //stackoverflow.com/questions/7131670/make-bash-alias-that-takes-parameter

標準エラーをすぐにリダイレクトすること/dev/nullは、早期のエラーメッセージを非表示にし、失敗を診断するのが難しいため、悪い考えです。次のstart-appzshスクリプトのようなものをお勧めします。

#!/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 &

ただ実行してください： start-app your_command argument ...

このスクリプトは、最大10行のメッセージを最大5秒間出力します。ただし、アプリケーションがすぐにクラッシュする場合（セグメンテーション違反など）、エラーメッセージは表示されないことに注意してください。もちろん、このスクリプトをさまざまな方法で変更して、必要なことを行うことができます...

注：start-appzshで補完を機能させるには、次の操作で十分です。

compdef _precommand start-app

そしてbashで：

complete -F _command start-app

（のための1つからコピーexecとtimeで/usr/share/bash-completion/bash_completion）。

この答えはbash向けです。例として、evPDFビューアーEvinceを起動するための便利なコマンドを作成するために、.bashrcで行うことを次に示します。

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

最初の行は関数を定義しますev。関数の名前は、コマンドラインで次のように使用すると認識されます。

ev foo.pdf

（これはエイリアスとは異なるメカニズムであり、優先順位は低くなります。）Evinceのstdinおよびstdoutへの出力は、bitbucket（/ dev / null）に送信されます。アンパサンドは、ジョブをバックグラウンドに配置します。コマンドをかっこで囲むと、サブシェルで実行され、バックグラウンドジョブの作成または完了に関するメッセージが出力されなくなります。

私の.bashrcの2行目は、bashの完全な関数を使用して、evコマンドの引数がpdfの拡張子を持つファイルであることをbashに伝えます。これは、ディレクトリに座っているfoo.tex、foo.auxなどのファイルもある場合、タブキーを入力して押すことができev foo、bashがファイル名をfoo.pdfとして入力することを知っていることを意味します。

別の可能性は使用することですcommand降格するexecから特別のような昔ながらの組み込みに組み込み：

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

だから今できること：

(shh; call some process &)

私はちょうどそれcommandがzsh （他のほとんどのシェルで動作するように）では動作しないことに気づきましたが、動作しない場合は代わりに行うことができます：

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

...どこでも動作するはずです。

実際、次のようなこともできます。

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

だからあなたができる：

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

出力

can anyone hear

@ vinc17とのコメントディスカッションに続いて、GUIアプリのコンソール出力のほぼすべてが、一般にXのtty（コンソール）を対象としていることは注目に値します。ファイルXからアプリを実行するX .desktopと、生成される出力はXの仮想端末にルーティングされますX。これは、最初に起動したttyでした。このtty番号はで対処できます$XDG_VTNR。

不思議なことに、そしてたぶん私が使い始めたからかもしれませんstartx-私はもはや書くだけではないようです/dev/tty$XDG_VTNR。これもあり（私は可能性が高いと思いとして）で実装は非常に最近の急激な変化に何か持っているXorg、それがもとで実行することができますv1.16 systemdというよりも、必要なユーザーセッションルート権限を。

それでも、私は行うことができます：

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

(gui; some x app &)

これで、すべてsome x appのコンソール出力が/dev/tty$((1+$XDG_VTNR))my xtermのpty ではなくにルーティングされます。この最後のページはいつでも取得できます：

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

とにかく出力をログに記録するためにいくつかの仮想端末を専用にすることはおそらくベストプラクティスです。/dev/console一般的には既にこのために予約されていますが、あなたはchownそれを気楽に書くために必要な可能性が高いことをしないことを好むかもしれません。あなたはあなたができることを可能にするいくつかの機能を持っているかもしれませんprintk-それは基本的に印刷しています/dev/console-それで私が思うようにそれを使うことができます。

これを行う別の方法は、そのような目的にptyを捧げることです。たとえば、xtermウィンドウを開いたままにして、ttyそこから実行されるときの出力を環境変数に保存し、その値をgui出力の宛先として使用できます。このようにして、すべてのログが個別のログウィンドウにルーティングされ、必要に応じてスクロールできます。

あなたが興味を持っているなら、私はかつてbash歴史で同様のことができるかについての答えを書きました。