.bashrc再マッピングするために、以下を追加しましたless。vim
alias vsi='vim -R -c ":map Q :q!<enter>" -' # Vim Standard Input [readonly]
alias less='vsi'
その理由は、キーバインドのデフォルト設定で2つの設定ファイルを維持したくないので、vimがより便利で予測可能であると考えているからです。 （しばしば私が探しているテキストが強調表示されていないか、ビューにないため見つかりません。）
それ〜らしい「大型」ファイルを開くことができないため開発途中とそれ以降に開発されたのですがless、当時「大型」とみなされて処理できなかったのは何ですか？今日はそれは問題ではありませんか？vimorevimore
このエイリアスは依存スクリプトまたはプログラムを壊しますかless？
答え1
不完全な入力を見るのは問題です。
seq 10000 | pv -qL 10 | less
答え2
lessシェルエイリアスはスクリプトや他のコマンドに対して拡張されないため、依存スクリプトやコマンドは中断されません。
シェルエイリアスは、対話型シェルセッションを促進するためにのみ存在します。エイリアスは、子プロセスが継承した環境の一部ではないため、そのシェルセッションで開始されたシェルスクリプトおよびコマンドには渡されません。
唯一の問題は、この別名があることを忘れ、対話型シェルセッションで追加のオプションと一緒に使用し続ける場合です。その後、これらのオプションを に提供しますvim。
view代わりに使用することを検討することもできますvim -R。
「ラージファイル」に関しては、これはRAMよりもサイズが大きいか、少なくとも利用可能なRAMのかなりの部分サイズのファイルです。伝統的に、編集者はファイルを開くとファイル全体をメモリーにロードしていましたが、一部の編集者はまだこれを行います。したがって、大容量ファイルを開くと
- ゆっくり
- エディタでリソース制約（メモリ不足）が発生する可能性があります。
.swp私はVimエディタがこの問題を解決するために「スワップファイル」（ファイル名のサフィックスが付いたファイルを見たことがあるかもしれません）を使用していると思います。:help swap-fileVimに何があるのか見てください。
lessデフォルトでは、ページャはそのまま残ります。みんなパイプから読み出すとき、メモリからデータを読み込みます。使用可能なRAMよりも多くのデータを読み取ると問題が発生します。幸いなことに、読み取ったデータの最後の部分だけを強制的にメモリに保存する-B（または--auto-buffers）オプションがあります。lessしかし、これにより、以前に見た入力ラインにジャンプすることは不可能になりました。
ポケットベルmoreは時々less偽装されます（バイナリへのハードリンクのみですless）。システムのmore位置実際 more、ポケットベルは、パイプから読み取られたデータを見るときに戻るスクロールを許可しません。
内容を見るためにファイルを完全に読むless必要はありません。moreどちらもファイル内の適切な場所を探します。
答え3
たとえば、スイッチでlessコマンドを実行すると、予期しない動作が発生する可能性があります。私は以下のように少ない行番号で実行するために「-N」スイッチを使うのが好きですless -N filename。 vimに少ないエイリアスを設定すると、予想される行番号が得られません（vimの場合、「-N」スイッチは「非互換モード」はvimを「より良いパフォーマンスを提供しますが、Viと互換性が低い」（manページ） ）。あなたのユースケースがlessとvimのさまざまな動作を決して強調しないと確信できますか？