タグ付けされた質問 「coreutils」

私の毎日の仕事の大部分は、同じソフトウェアの異なるバージョンなどのマシン上で使用するためのソフトウェアを開発しているbash、findとgrep。たとえばコードを簡略化するのに役立つ機能に遭遇した場合、この機能が最も古いインストール済みツールで使用できるかどうかを知ることが重要です。重要なものについては、この機能が新しいものか、インストールされている最も古いツールに何年も存在していたかどうかを知ることも役立ちます。 Linuxツール、特にGNU Core Utils に対してこれを信頼できる方法で迅速に回答する方法は何ですか？精度が低い順にいくつかの可能性： もちろん、さまざまなバージョンを実行することによるバイナリバイナリ検索（sic）は最終的な答えですが、はるかに時間がかかります。セキュリティ上の理由から、古いインストールは利用できないことがよくあります。 コードの読み取りはほぼ同じですが、機能の名前が曖昧であるか、名前が変数/関数/オブジェクトの名前に直接対応していない場合、または有効になる前に実装された場合は、非常に時間がかかる可能性があります。 変更ログ（利用可能な場合）は、通常、機能の変更をソフトウェアバージョンに関連付けます。 コミットログはヒントを提供できますが、どのバージョンに含まれるかわかりません。 マニュアルページで日付について言及することはほとんどありません。 同じことがGooglingにも当てはまり、権限のないソースをすべて除外することも難しいでしょう。

10 coreutils 

ソートする次の入力を検討してください。 cat > foo <<EOM D,,5014978 DD,,25 D,I,1972765530 D,Y,4223624 -,Y,71285059 YA,I,2 EOM 今実行してみてください sort foo これを私のLinuxボックス（gnu coreutilsバージョン6.9〜7.4）で試しても、出力はソートされません。cygwin（gnu coretuils 8.5）で実行すると、出力がソートされます。コメント？

10 bash  coreutils  sort 

質問：の簡単な使用例が必要cp --no-target-directoryです。 理解するのが難しいcp --no-target-directoryです。の説明mv --no-target-directoryはわかりますが、の使い方を想像することはできませんcp。 たとえば、コマンドmv /tmp/source /tmp/destが成功した場合、/tmp/source名前が変更されたという保証はありません。他のプロセスがディレクトリとして作成された場合/tmp/dest、/tmp/dest/source代わりに名前が変更された可能性があります/tmp/dest。ただし、mv -T /tmp/source /tmp/dest成功した場合、/tmp/source was renamed to/ tmp / dest` は問題ありません。（ソース）

10 directory  cp  coreutils 

約100,000個のファイルを含むディレクトリがあります。ls -fが1分以上ハングします。私はstraceを実行し、すぐにgetdentsを確認し始めたので、lsは明らかにディレクトリを読み取っています。また、brkへの呼び出しが多いので、lsは明らかにメモリにバッファリングしています。readdirを呼び出してファイル名を出力する簡単なプログラムを書いたところ、すぐに応答しました。ただし、ls -fは出力を提供しません。何ができますか？-fの要点は、lsがreaddir以外に何も行わないことだと思いました。ディレクトリの内容をリストするポータブルで信頼できる方法はありますか？（これはLinux上のgnuのcoreutilsからのlsであることに注意してください。） -編集- エイリアスがありましたが、「/ bin / ls -1f> / dev / null」には8〜15秒かかります。「/ bin / ls -1fx> / dev / null」には4〜11秒かかりますが、簡単なプログラムreaddirは.011秒かかります。GNU lsが吸わないようにするために何をする必要がありますか？

9 linux  ls  gnu  coreutils 

私が参照してるのコマンドの例はls、pwdとcd。また、これらはどのように構築されていますか？例はありますか？

9 command-line  source  coreutils 

UNIXライクなシステムでパス解決のプロセス（manページpath_resolutionを参照）をエミュレートしようとしています。 私のOSはLinuxで、GNU coreutils 8.7を使用しています。 解決における余分な末尾の「/」の意味を明確にするために、シェルで次のことを行いました。 mkdir this_is_dir ln -s this_is_dir this_is_link rm this_is_link this_is_linkはシンボリックリンクであるため、すべて正常で、削除しました。しかし、試みている間： mkdir this_is_dir ln -s this_is_dir this_is_link rm this_is_link/ 反響した rm: cannot remove 'this_is_link/': Is a directory さて、末尾の「/」はシンボリックリンクのフォローを引き起こしたと私は思いました。だから、私は別のコマンドを試しました：rmdir this_is_link/ そして面白い結果が出ました： rmdir: failed to remove 'this_is_link/': Not a directory 私が期待したものではありません。だから私は私の友人に彼のシステムで同じ結果が得られるかどうか確認するように頼んだ。彼は私よりも低いバージョンのcoreutilsを持っていました。結果は驚くべきものでしたrmrmdir 'this_is_link/'Not a directory。同じエラーが発生するかどうかは関係ありません。 そして、別の友人が彼のMac OSで試したところ、結果は次のようになります。rm=> 'Is a directory'、rmdir=>ディレクトリは正常に削除され、リンクは残りました。 …

8 directory  filenames  symlink  coreutils 

sort、find、grep、diffなどのUnixユーティリティは、コードをまったく記述しなくても、すばやくタスクを実行するのに非常に便利です。 彼らが内部で使用しているアルゴリズムと、特定のタスクの特定のアルゴリズムをインテリジェントに決定する方法を知りたいのですが？たとえば、sortが巨大な入力ファイルを取得する場合、データサイズごとに異なるアルゴリズムを使用しますか？ grepは、さまざまなデータセットを検索しながらアルゴリズムをインテリジェントに切り替えますか？

8 text-processing  grep  sort  coreutils