タグ

ブックマーク / qiita.com/ko1nksm (7)

  • Unixの歴史の起源を伝説のゲーム「スペース・トラベル」で遊んで学ぼう! - Qiita

    ちなみに Space Travel にスコア機能やゲームのなにかを記録する機能はありません。描画は点と線だけで画像ファイルの読み込みなどは行いません。オリジナルの Space Travel は紙テープから起動してオンメモリで動くはずです。何が言いたいかというと Space Travel を動かすためにファイルシステムを作る理由はないということです。紙テープからの起動なんて時間がかかるのでは? と思ったあなたは鋭い。1980 年頃の音楽用のカセットテープをコンピュータの記憶媒体として使っていた時代では、実際にゲームを始める前のロード時間に何分も待っていました。 初期の Unix 開発の技術は Space Travel から学んだ さて、この記事は Space Travel を通して Unix 開発の初期の歴史や、なぜケン・トンプソンは Unix を開発するに至ったのかを知ろうというのが趣旨の

    Unixの歴史の起源を伝説のゲーム「スペース・トラベル」で遊んで学ぼう! - Qiita
    KoshianX
    KoshianX 2024/09/18
    へえ、PDP-7 でゲーム作って遊んでたのは開発に習熟するのに役立っただけでゲーム作りたさにUNIX作ったわけじゃないよと。もともと対話的なOSを作りたかったんだなあ
  • いい加減シェルスクリプトで [ $? -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
    KoshianX
    KoshianX 2024/08/21
    お、shellcheck なんてアプリが出てきてたのか。else のなかで case で分岐すればエラーコードの場合分けもできるというのはなるほどだ。
  • 元々は /usr は user の略に決まってるじゃん?ホームディレクトリを置く場所だったんだから - Qiita

    Twitterとか見て「そうだったのかー」とか言うんじゃなくて、ちゃんと調べてみましょうよ。/usr は元々ユーザーのホームディレクトリをおいていた場所ですよ。/bin などを置いていたシステムディスクの容量が足りなくなったので別ディスクだった /usr 以下を使うようになっただけです。Unix System Resources とかそんな長い名前、後付けに決まってるでしょ? 翻訳は面倒なので、DeepL(の少し手直し)です。 初期の Unix のドキュメントから URLと1972年という年から、おそらく Version 1 Unix (1971) のドキュメントだと思います。ここ 経由で見つけました。 12ページにこのようなものがあります。詳細はよくわかりませんがディレクトリ構造でしょう。 idata: / root 41. 140016 .byte 7,1 9f-.-2 41. <..

    元々は /usr は user の略に決まってるじゃん?ホームディレクトリを置く場所だったんだから - Qiita
    KoshianX
    KoshianX 2024/06/20
    “Unix System Resources とかそんな長い名前、後付けに決まってるでしょ?” そ、そうなのか。あーもう FreeBSD とか触ってたのだいぶ前だから忘れてるな、/usr/home とかあったか。俺はユーザーって読んでます
  • 祝🎉 POSIX.1-2024 (Issue 8) 改定!16年ぶりの大幅改定でシェルスクリプトはどう新しくなるのか? - Qiita

    FreeBSD では 2024-05-31 に 200112 から 200809 への変更がようやく行われました(一度間違えて 200808 と書いてしまっていますが)。 https://cgit.freebsd.org/src/commit/?id=2e30926a68 https://cgit.freebsd.org/src/commit/?id=6e0278408e macOS は FreeBSD のユーザーランドのコマンドを使用しているため、そのせいで 200112 のままだった可能性も考えられますが、シェルやカーネルは FreeBSD のものではないため、FreeBSD が変更になったからと言って macOS が更新されるとは限らないでしょう。Solaris 10 と 11 ではディレクトリごとに準拠バージョンが異なるバイナリが配置されており以下のようになります。Solaris

    祝🎉 POSIX.1-2024 (Issue 8) 改定!16年ぶりの大幅改定でシェルスクリプトはどう新しくなるのか? - Qiita
    KoshianX
    KoshianX 2024/06/17
    膨大……。uuencode で base64 使えるの標準化されたりしてんのね
  • Bourneシェルの終焉まで残り1年 ~ 新しいシェルへの移行は完了していますか? - Qiita

    はじめに 30年以上もの長い間 UNIX を支えてきた Bourne シェルも UNIX のサポート終了とともに消え去ろうとしています。みなさん、他のシェルへの移行はお済みでしょうか? 残り一年、まだ移行が済んでいないという人のために、移行のための簡単なガイドラインと各シェルの特徴をまとめました。 sh は昔は Bourne シェルのことでしたがそれも過去の話です。今どき「Bourne シェル」を解説している記事や sh のことを Bourne シェルと呼んでいる記事は情報が古い(大学関係に多い)、または古い情報を元にして書かれたか、シェルのことを正しく理解してない不正確な記事なので参考になりません。分かりやすい基準ですね。 関連記事 シェルとUNIXコマンドの未来 ~ これからの10年で起きるシェルスクリプトの変化 残り1年というのはどういうこと? Bourne シェルは POSIX に

    Bourneシェルの終焉まで残り1年 ~ 新しいシェルへの移行は完了していますか? - Qiita
    KoshianX
    KoshianX 2023/12/31
    ふーむなるほど、dash さえ使ってれば安心というわけでもないか。でもマルチバイト文字が使えないだけだしなあ。
  • echoコマンドの移植性が低い歴史的理由とPOSIXの改定方針 ~ 次期POSIXでbashのechoはPOSIX準拠になる! - Qiita

    echoコマンドの移植性が低い歴史的理由とPOSIXの改定方針 ~ 次期POSIXでbashのechoはPOSIX準拠になる! はじめに 実は bash に組み込まれた echo コマンドは POSIX に準拠していません。しかし 2023 年に予定されている次期 POSIX (Issue 8) の改定で、POSIX 準拠の動作になります。🎉🎉🎉 私のこの言い方には違和感を感じるかもしれません。「POSIX に違反している bash が問題点を修正して、POSIX に準拠させるのではないのか?」と。いいえ違います。POSIX 側が仕様を修正することで、bash は何も変更せずに過去のバージョンも含めて POSIX に準拠するようになります。面白いですね。 この記事は echo コマンドの移植性の問題の歴史を振り返りながら、それを例に POSIX 標準化団体がどのような方針で標準規格を

    echoコマンドの移植性が低い歴史的理由とPOSIXの改定方針 ~ 次期POSIXでbashのechoはPOSIX準拠になる! - Qiita
    KoshianX
    KoshianX 2023/01/13
    POSIXにこだわるなと。echo の非互換問題は残り続けるのか。$'...' が標準化されるというのはありがたいな。未サポートのシェルは対応するんだろうか。
  • 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 {} \; と ; をバックスラッシュでエスケープするのがよく見る使い方

    POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき! - Qiita
    KoshianX
    KoshianX 2021/09/14
    え、これ知らなかったな。posix もこんなアップデートされ続けてるんだなあ
  • 1