Unixの歴史の起源を伝説のゲーム「スペース・トラベル」で遊んで学ぼう！ - Qiita
ちなみに Space Travel にスコア機能やゲームのなにかを記録する機能はありません。描画は点と線だけで画像ファイルの読み込みなどは行いません。オリジナルの Space Travel は紙テープから起動してオンメモリで動くはずです。何が言いたいかというと Space Travel を動かすためにファイルシステムを作る理由はないということです。紙テープからの起動なんて時間がかかるのでは？ と思ったあなたは鋭い。1980 年頃の音楽用のカセットテープをコンピュータの記憶媒体として使っていた時代では、実際にゲームを始める前のロード時間に何分も待っていました。 初期の Unix 開発の技術は Space Travel から学んだ さて、この記事は Space Travel を通して Unix 開発の初期の歴史や、なぜケン・トンプソンは Unix を開発するに至ったのかを知ろうというのが趣旨の
いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ - Qiita
いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ShellScriptBashLinuxUNIXmacOS はじめに [ $? -eq 0 ] や [ $? -ne 0 ] は冗長でデメリットしかありません。非常に多く見かける書き方ですが、1979 年に Bourne シェルが広く公開された時からこのようなコードは必要ありませんでした。実際に当時はこのような書き方は使われておらず、このような書き方をしなければならなかった歴史的な経緯などはありません。これはなぜか広まってしまった良くない書き方です。 優れたコードとは無駄がないシンプルなコードです。丁寧なコードとは無駄な処理を書くことではありません。[ $? -eq 0 ] や [ $? -ne 0 ] は書かないほうが、簡単で読みやすくわかりやすくなります。優れた文法
![いい加減シェルスクリプトで [ $? -eq 0 ] や [ $? -ne 0 ] なんて エラー処理を書くのはやめよう！ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/4e42d360866a8ef193de27e43e50492da34de08d/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JUUzJTgxJTg0JUUzJTgxJTg0JUU1JThBJUEwJUU2JUI4JTlCJUUzJTgyJUI3JUUzJTgyJUE3JUUzJTgzJUFCJUUzJTgyJUI5JUUzJTgyJUFGJUUzJTgzJUFBJUUzJTgzJTk3JUUzJTgzJTg4JUUzJTgxJUE3JTIwJTVCJTIwJTI0JTNGJTIwLWVxJTIwMCUyMCU1RCUyMCVFMyU4MiU4NCUyMCU1QiUyMCUyNCUzRiUyMC1uZSUyMDAlMjAlNUQlMjAlRTMlODElQUElRTMlODIlOTMlRTMlODElQTYlMjAlRTMlODIlQTglRTMlODMlQTklRTMlODMlQkMlRTUlODclQTYlRTclOTAlODYlRTMlODIlOTIlRTYlOUIlQjglRTMlODElOEYlRTMlODElQUUlRTMlODElQUYlRTMlODIlODQlRTMlODIlODElRTMlODIlODglRTMlODElODYlRUYlQkMlODEmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWZhZDdkMjVkYjUxODQ5OWRhZDhiZWM3ZGMwN2ZlY2Q0%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrbzFua3NtJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0zNDA2OWFjMTI5MDIyYmE1ZjY0OTI5ZGU2ZGUwNDU5Zg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D8f12358d68288246128c01d35bcfa4b1)
findコマンドの使い方を簡単に理解するための7つのルール＋実践的な知識 - Qiita
はじめに find コマンドの使い方は、ざっくり調べただけではよくわからんとなりますが、見逃しがちなルールを知れば簡単に理解できます。find コマンドに限りませんが使い方を調べるのが面倒だからと曖昧な理解で使うと逆にもっと分からなくなって時間がかかります。急がば回れ、理解して正しく使ったほうがシンプルで楽で簡単です。この記事では find コマンドの使い方を理解するために必要なルールと使い方の実践的な知識をまとめました。 Q&A（？）: -type や -perm の説明はしないの？ ⇒ それらはドキュメントを読むか検索すればすぐにわかることで難しいポイントではありません。重要なのは基本のルールを理解することです。 関連記事 POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ 移植性の話はこちら ⇒ findコマンドのオ
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくる - Qiita
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくるShellScriptBashUNIXshellPOSIX はじめに シェルスクリプトの変数代入で = の前後にスペースを置くことができない理由は、検索すれば「プログラマーの君！ 勘違いするな！ シェルスクリプトでは読みやすさのためにスペースを置くな！！ という話」のような記事がすぐに見つかります。記事に書いてあるとおり変数代入とコマンド呼び出しと区別がつかないからです。それは間違いではないんですが、私はもう少し説明が足りないと感じています。そこで今回は = の前後にスペースを置けない本当の理由を解説したいと思います。 の前に皆さんにはこの話を読みながら、自分がシェルスクリプトの言語設計者だったとしたら、どういう言語仕様にするかを考えて欲しいです。なぜかと言うとシェルスクリプトの文
POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ - Qiita
POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ShellScriptBashshellPOSIX はじめに find の出力を xargs にパイプで渡すというのはよく見かける使い方ですが、find -print0 | xargs -0 が使えない POSIX 準拠のシェルスクリプトでは find -exec {} + を使った方が良いです。安全かつ十分に速いからです。よく見かける -exec {} ; ではなく -exec {} + ですので間違えないようにしてください。多くのケースでは + の方が優れているのですが ; ばっかり使われているのを見ると、意外と知られてない気がします。 少しだけ予備知識として、-exec {} ; は -exec {} \; と ; をバックスラッシュでエスケープするのがよく見る使い方
シェルスクリプト リファクタリング ～遅いシェルスクリプトが供養されてたので蘇生して256倍に高速化させました～ - Qiita
はじめに ことの始まりは「シェルスクリプトでツールを作ったけど速度が遅くて使い物にならなかったので供養」というツイートを見たからです。コードを見てみると、実例をあまり見ないシェルスクリプトのリファクタリング例として丁度良い内容と分量だったため記事にいたしました。記事を書くにあたりコードの利用を快く承諾していただいた @Hayao0819 様にはこの場を借りて御礼を申し上げます。 内容は章立てで構成しており、序章で事前調査をし、第一章で一般的なリファクタリング、第二章でパフォーマンスを重視したリファクタリング、終章で少し余談をして締めくくっています。最初はパイプは並列処理されるから速くなるというのは神話（そうとは限らない）についても書いていたのですが流石に長いので分けました。それでも書きたいことを色々書いていたらめちゃくちゃ長くなってしまいましたので読み物として私がどんなことを考えながらリフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
