多くのCLIプログラムは、他のプログラムにパイプするのではなく、コンソールに印刷すると異なる出力を生成します。たとえば、exa色が強調されたファイルのリストが印刷されます。しかし、exa | less色はありません。
私はこれらのプログラムが通常、1つの入力または別の入力を強制するパラメータを持っていることを知っているので、解決策はこれらのパラメータを学習して配管するために使用することです。これは、次のようないくつかの問題のために普遍的な解決策ではありません。
- 各コマンドの引数を学ぶ必要がある場合、または何かをパイプしようとしたときにマンページを読むには、ワークフローで常に注意を払う必要があります。
- すべてのプログラムがこれらのパラメータを提供するわけではありません。
- 長いパイプリストにパラメータを継続的に挿入する必要があるのは面倒です。時々、チェーン全体を実行するのに長い時間がかかるため、間違った出力が表示され、他の
--colorタスクを再度追加または実行することを忘れてしまったことに気づいた瞬間は、数分を無駄にしました。
明らかに、プログラムの設計は、何かがパイプされていることを検出し、他の出力が適切であると推測することです。これは多くの場合に良いと正しい動作です。他の多くの場合、プログラムの推測が間違っていました。各プログラムのユニークなインターフェースを学び、推測を上書きするよりも、最初からプログラムにパイプされていることを知らないことで、推測を事前に防ぐことができれば、より効率的なようです。
可能ですか？プログラムがコンソールに印刷し、パイプなしで同じ出力を生成すると考えさせながら、出力をプログラムにパイプする一般的な方法は何ですか？
答えがシェルに依存する場合、次のシェルに興味があります。
bash事実上の標準なのでzshbash普遍的に互換性のあるアップグレードだからfishbashこれは、両立できない状況で改善を試みる例だからです。
に基づいてhttps://askubuntu.com/a/482826isatty問題は、プログラムをパイプするときにこれが間違っているようです。したがって、解決策は何らかの方法でコマンドをパイプすることですが、isattyそれでも本当です。しかし、実際にこれを達成する方法がわかりません。
答え1
これが良い解決策であるかどうかはわかりませんが、以下に基づいています。https://stackoverflow.com/questions/4233808/piping-data-to-linux-program-which-expects-a-tty-terminalunbufferこれは達成されたようです。
unbuffer exa | less色が表示されます。