サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
セキュリティ
qiita.com/ko1nksm
はじめに 現在、TRON プロジェクトといえば、組込みシステム向けのリアルタイム OS を開発するプロジェクトとほぼ同義です。しかし、それは2000年代以降の話で、1980年代から1990年代では組み込みシステムに限らず、独自の新しいコンピュータ体系を作るプロジェクトでした。TRON に関してのデマが多い中、この記事は初期の TRON プロジェクトの話を、当時の新聞や雑誌、坂村氏の著書や論文などを元に真実を説明しています。忠告しておきますが、当時の TRON プロジェクトのことを真面目に記事や動画にしたいなら、この記事を読まないで書くと恥をかきますよ。それぐらいこの記事と他の記事や動画には内容に圧倒的な差があります。 記事を読まないで勝手に結論づける人が多いので先に書いておきますが、パソコン用 TRON が潰れたのは、当時の多くの日本人が欲しいと思わなかったからです。構想時点では素晴らしい
以下は1983年11月23日に撮影された発売前の Windows デモ(他の GUI も含まれるので注意)と関連記事。トロンプロジェクト発足は1984年6月、トロン OS の開発が始まる1年近く前に Windows は動くデモが発表されています。 Microsoft Windows 1983 pre-Version 1.0 demo Byte Magazine 1983年12月号 (デモ版の Windows の記事) Microsoft Windows at Fall Comdex 1983 Microsoft の PC 用 OS は1981年の MS-DOS から始まり、さまざまなメーカーから MS-DOS 用の多くのアプリケーションが販売されました。多くの人はパソコンを購入しており、それらが後継 OS でも動いたことが、Windows が普及した理由の一つです。アプリケーションがほとん
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 日本航空123便墜落は1985年8月12日に発生した事故ですが、TRON 開発者が死亡した話は2008年頃にネットで生まれた悪質なデマ・陰謀論です。これを信じてしまった人は詐欺に騙されやすい人なので注意しましょうね。「日本航空 (JAL) 123便と TRON を結びつけた陰謀論」とは、トロン開発の妨害でトロン技術者が亡くなったというデマで、TRON 技術者17人が搭乗していた飛行機を米国がミサイルで撃ち落として暗殺したという陰謀論ですが、そもそも「123便にトロン技術者は一人も乗っていなかった」ことが、信頼できる複数の情報源
EPSON がかなり頑張っており NEC のシェアを奪っていることがわかりますが、その他のシェアに大きな変化はありません。PC-98(とその互換機)は 1987 ~ 1988 年に、合わせて 90% 以上のシェアを持っていたことがわかります。当時の MS-DOS のバージョンは 3.x です(3.0、3.1、3.2、3.3、3.3A、3.3B、3.3C。3.3Dなどがありました)。もちろん日本語にも対応しています。EPSON がこれだけ PC-98 のシェアを奪ったのは互換性があり、PC-98 用のソフトウェアを動かせたからです。NEC は対抗して「エプソンチェック」と呼ばれる EPSON 機では MS-DOS を動かないようにする仕組みを導入していました。 背景5 - BTRON は米国に潰されたのではない 一部で BTRON は米国に潰されたという話がありますが、実際には日本のパソコン
BTRONがWindowsに勝利できなかった理由 TRON が Windows よりも優れていたと思う人は、最新の BTRON OS に乗り換ましょう! 口先だけなのか、今、あなたがどれだけ TRON を愛しているかが試されています。 1. 「国産OS TRON」は無料ではなかった 国産OS「TRON (トロン)」が、無料で誰でもダウンロードして使えたと勘違いしている人が増えてきているようですが、1984 年に坂村氏が「無料で誰でも使えます」といって公開したのは「紙の OS の仕様書」のみです。無料というのは OS の販売価格ではなく OS を開発したメーカーが坂村氏にお金を払わなくて良い(ロイヤリティが不要)という意味です。OS は各コンピュータメーカーがそれぞれ開発するという想定でした。OS なんて誰か一人(一つの組織)が開発すればいいじゃないかと思うかもしれませんが、当時はコンピュー
はじめに Windows ではディレクトリ区切りに Unix 系 OS の / ではなくバックスラッシュ ⧵ を使い、しかも 日本語フォントでは 円マーク ¥ で表示されます。なぜこうなったかは次の独立した 2 つの理由からです。 はるか昔に JIS の文字コードの標準規格はあまり使わない ⧵ を必須の ¥ に置き換えた はるか昔にコマンドのオプション(スイッチ)としてすでに / を使っていた Microsoft は他の OS のやり方を真似するのが嫌だからとか権利侵害になりそうだから ⧵ に変更したなどという根も葉もない噂がありますが、そうではありません。むしろ Microsoft は他の OS のやり方を取り込んだんです。なお、後で解説しますが、Windows は昔からディレクトリ区切りに/ と ⧵ の両方を使えるので Unix 系 OS と互換性がないわけではありません(どっちかと言
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 2025年現在でのおすすめの zip ファイル形式の圧縮・展開(解凍)ソフトについてまとめました。本記事はファイル名を文字化けせずにやり取りできるかを重視しており、使い勝手や対応形式の多さや機能については評価の対象にしていません(が後半におまけで書いています)。一部を除きフリー(無料)で使えます。Lhaplus のような未だに Shift JIS にしか対応していない古いソフトウェアは非推奨としています。今どき Shift JIS を使う必要はありませんし、Shift JIS では一部の漢字や絵文字などを扱えず、Windows
上記の一覧を見るとわかるように、zip ファイルの 解凍機能が zip ファイルのUTF-8ファイル名に対応したのは Windows 7(2012年の修正パッチが必要)からです。しかし修正パッチを当てていない人がいるかも知れないので、Windows 7 は zipファイルの中のUTF-8ファイル名を扱えない可能性があります。延長サポートを含めれば Windows 7 は 2020年1月14日までの長いサポートがあったわけで、Windows の標準機能としては Windows 7 のサポート期間が終了するまでは、UTF-8ファイル名を zip ファイルの中に格納するわけにはいかなかったのでしょう。 そして古い Windows のサポートがようやく終了して、サポート切れの古い Windows を使っているような人もいなくなったであろうこのタイミング(Windows 11 24H2?)でやっと
はじめに macOS では濁点や半濁点が含まれるファイル名でたびたび問題が発生しています。この問題は NFD 問題と言われたり UTF-8-MAC 問題と言われることがありますが、必要な情報が正確に書かれているところは少なく、正しく解説してある所でも情報が古く(主に HFS+ 時代の話に)なっており、読むと逆に混乱してしまう場合があります。 macOS 標準アプリや誰かが作ったアプリであればバグが修正されるまで待つだけですが、自分が作ったアプリやシェルスクリプトなどではこれがどういう問題なのかを理解しなければバグが修正できません。この記事ではそれらを整理し直して、(可能な限り正確に)解説したいと思います。検証は macOS 15.3(補助的に 15.5)で行っています。 この問題は、Mac で作成した zip ファイルを Windows で展開したときに、濁点や半濁点を含むファイルに Wi
【朗報】macOS 15.4でsortコマンドのソート順がまともに修正されました! 〜 マーズとマーキュリーの間にジュピターが割り込んでいた理由sortgrepmacOSUnicodePOSIX はじめに 以前の macOS は sort コマンドで日本語を含む Unicode 文字を正しくソートできませんでした。また grep コマンドでも正規表現の文字の範囲に正しくマッチできないという問題もありました。この記事ではその問題と理由を明らかにし、その原因がどこにあるかを確認します。なおこの問題は 2025年3月31日にリリースされた macOS 15.4 で修正されたようで(ただし別のバグがあります。補足2参照)、この記事に明らかにしている問題は macOS 15.3 以前の話です。 この記事は元々「macOS の sort コマンドのソート順はデタラメだ!」というタイトルだったのですが、
はじめに curl とは対話シェルやシェルスクリプトから HTTP 通信を行うのによく使われるコマンドです。あらゆる環境(100 種類の OS)で動作し、macOS や Windows には標準でインストールされています。商用サポートもあり、互換性は非常に重視され、何年経っても同じ書き方で動きます。非常に長く使われており(1998 年生まれの 27 歳1)、そして古い情報もたくさんあります。この記事ではそういった古い情報を、より簡単で新しい curl コマンドの使い方にアップデートします。最初に結論を書いておくと、 もう -X POST -H "Content-Type: applicatoin/json" なんて書かなくていいですよ。 (記事を読まない人のためのリンク) この記事を書くにあたって以下の記事を参考にしています。この記事が書かれたのは 2015 年、現在はそれから 10 年後
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
# 終了処理($1: シグナル名) cleanup() { # 終了処理中に無視するシグナル(他に必要な場合は追加する) trap '' HUP INT QUIT PIPE TERM # ここに終了処理を書く : TODO # 自分自身にシグナルを再送信することでシェルスクリプトを終了する trap - EXIT "$1" [ "$1" = EXIT ] || kill -s "$1" $$ || exit 1 } # トラップするシグナル(他に必要な場合は追加する) for i in EXIT HUP INT QUIT PIPE TERM; do trap 'cleanup '"$i" "$i" done # ここより下に実際のシェルスクリプトの内容を書く : : 自分自身にシグナルを再送信しているところが特徴的だと思いますが、その理由についての解説がこの記事の内容で、POSIX 準拠で
はじめに ls コマンドは list の略です。list segments の略という説は Multics 関係者が否定しており間違いだと判明しています。Multics を買収し後を引き継いだハネウェル (Honeywell) の出版本には The list command という本名を省略した別名が ls であることがしっかりと書かれています。 ls を list の略と記された古い文献はいくつもあります。「諸説ある」という便利な言い訳がありますが、この件に関して言えば list 以外の諸説は見つかりません(あるというのならそれを教えてください)。みんな情報が正しいかを調べずに、どこかのページに書いてあった噂を真似して書いているだけです。この記事では、説得力がある発言として、Multics 開発の関係者である Tom Van Vleck の「ls はlist の略である」という発言」 を
プロファイルでできることは環境の設定だけです。シェルの設定は実際にはできないことはないのですが、やっても無意味なことになるのでできないとします。無意味なことになるというのは新しく起動したシェルにはプロファイルで行うシェルの設定は反映されないということです。環境の設定とは、特定のシェルに依存しない初期化処理のことで、その一つが環境変数の設定です。環境変数は OS の機能であってシェルの機能ではありません。環境の設定には、他に stty コマンドによる端末の設定や umask コマンドによる umask の設定などがありますが、プロファイルで設定することはあまりありません。 rc ファイルでは環境の設定とシェルの設定の両方ができます。シェルの設定、例えばプロンプト文字列の設定やシェルの機能を有効にしたり補完スクリプトの読み込みなどは rc ファイルに書きます。つまり、ほとんどのことは rc フ
ちなみに Space Travel にスコア機能やゲームのなにかを記録する機能はありません。描画は点と線だけで画像ファイルの読み込みなどは行いません。オリジナルの Space Travel は紙テープから起動してオンメモリで動くはずです。何が言いたいかというと Space Travel を動かすためにファイルシステムを作る理由はないということです。紙テープからの起動なんて時間がかかるのでは? と思ったあなたは鋭い。1980 年頃の音楽用のカセットテープをコンピュータの記憶媒体として使っていた時代では、実際にゲームを始める前のロード時間に何分も待っていました。 初期の Unix 開発の技術は Space Travel から学んだ さて、この記事は Space Travel を通して Unix 開発の初期の歴史や、なぜケン・トンプソンは Unix を開発するに至ったのかを知ろうというのが趣旨の
はじめに [ $? -eq 0 ] や [ $? -ne 0 ] は冗長でデメリットしかありません。非常に多く見かける書き方ですが、1979 年に Bourne シェルが広く公開された時からこのようなコードは必要ありませんでした。実際に当時はこのような書き方は使われておらず、このような書き方をしなければならなかった歴史的な経緯などはありません。これはなぜか広まってしまった良くない書き方です。 優れたコードとは無駄がないシンプルなコードです。丁寧なコードとは無駄な処理を書くことではありません。[ $? -eq 0 ] や [ $? -ne 0 ] は書かないほうが、簡単で読みやすくわかりやすくなります。優れた文法を持つシェルは短いコードで正しく動作し、良い書き方は最短の時間と最小の手間で目的を達成することができます。コマンドのエラー処理を簡潔に書くことができるのが、シェル言語の優れている点の
補足1: 上記以降のその他のシェルの歴史 ksh88: 1980年頃に開発開始。一般的に公開されていないが ksh83 や ksh86 もある pdksh: ksh88 クローンで 1987年から1989年頃に開発。その派生版を OpenBSD が採用 bash: 1988年1月に開発開始し、1989年6月に 0.99 がリリース ash: 1989年5月にリリース、その派生版をFreeBSD、NetBSD、Debian系Linux などが採用 zsh: 1990年頃に1.0がリリース ksh93: 1993 年頃に開発開始。ksh88 の大幅強化版だが完全な上位互換ではない 参考: シェルの歴史 総まとめ(種類と系統図)と POSIX の役割 〜 シェルスクリプトの現在・過去・未来 補足2: POSIX 標準化以降 1992 年に POSIX によってシェルの仕様が標準化されました。しか
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに $\color{#e02020}{\huge{\bf{それは単なる「POSIX標準規格書の用語集」じゃい!}}}$ ということで、まことしやかに POSIX がテキストファイルの仕様を決めているかのような噂が流れていますが(私も言ったことがあるかも?)、POSIX に「テキストファイルは末尾に改行を書かなければならない」なんて仕様はありません。また POSIX は「テキストファイルの末尾を改行にすべし」などとも言っていません。POSIX は「3. Definitions(定義)」で 「POSIX 標準規格書の中で使用している『
はじめに grep コマンドや sed コマンドの -e オプションや -E オプションの意味を勘違いしている例を見かけるので訂正です。 -e オプションは正規表現またはスクリプトを追加指定するためのオプションです -E オプションは拡張正規表現モードを有効にするためのオプションです -e と -E は反対の意味を持つオプションではありません。まったく異なる機能を提供しているオプションです。-e オプションは拡張正規表現でも使うことができます。 -e オプションは正規表現の追加指定 まず、なぜ -e オプションというものが作られたのか? それはハイフンで始まる正規表現を指定したり、sed スクリプトを組み立てたりするためです。 grep コマンドの話 例えば grep コマンドで -a という文字列を検索したい場合はどうするでしょうか?
はじめに CUI は英語圏では通用しないようです。CLI という正しい用語を使いましょう。というか CUI のことしか書いていない初心者向け記事、量産させすぎ😡 ❌ CUI (キャラクターユーザーインターフェース)なんて言葉は英語にはありません 🟢 CLI (コマンドラインインターフェース)が正しい用語です 🟢 GUI (グラフィカルユーザーインターフェース)も正しい用語です なんども繰り返されている話題ですが、ふと書きたくなったので書きます。 CLI (コマンドラインインターフェース)ってなに? CLI とはその名の通り、コマンドラインを使ったインターフェースのことです。つまり一般的にはシェルを使うユーザーインターフェースです。よく見るコレ↓です。 コマンドラインインターフェースとは、コマンドラインにコマンドを入力することでコンピュータを使うインターフェースです。ちなみにコマンドと
Twitterとか見て「そうだったのかー」とか言うんじゃなくて、ちゃんと調べてみましょうよ。/usr は元々ユーザーのホームディレクトリをおいていた場所ですよ。/bin などを置いていたシステムディスクの容量が足りなくなったので別ディスクだった /usr 以下を使うようになっただけです。Unix System Resources とかそんな長い名前、後付けに決まってるでしょ? 翻訳は面倒なので、DeepL(の少し手直し)です。 初期の Unix のドキュメントから URLと1972年という年から、おそらく Version 1 Unix (1971) のドキュメントだと思います。ここ 経由で見つけました。 12ページにこのようなものがあります。詳細はよくわかりませんがディレクトリ構造でしょう。 以上、/ user directory でした。 AT&T Archives: The UNIX
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
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Unix 哲学には DOTADIW: Do One Thing and Do It Well という言葉があります。日本語に訳すと「一つのことをうまくやる」となりますが、しばしば単機能のコマンドを作ることだと勘違いされています。もし勘違いしている人がいるのであれば、ぜひその人に聞いてみてください。なぜ grep コマンドはマッチした行数をカウントする機能を昔から持っているのですかと。昔からある wc コマンドがあれば grep コマンドに行数をカウントする機能をもたせる必要はないのではないかと。 -c Only a count
Unix 哲学的に考えれば、行を並び替える sort コマンドと重複行を取り除く uniq コマンドは別のコマンドであるべきなように思えます。しかし sort コマンドには -u オプションとして uniq コマンドに相当する機能が組み込まれています。なぜそうなっている(そうなってしまった)のかを「ソフトウェア作法(さくほう)」を参照しながらこの記事で明らかにしたいと思います。 関連記事 Unix哲学「一つのことをうまくやる」は単機能のコマンドを作ることではない 「誰」がuniq機能をsortコマンドに組み込んだ!? 熱烈的な Unix 哲学の信者は「どうせ Unix 哲学を理解しない GNU が便利だと思ってオプションを追加したのだろう」と考えるかもしれません。しかし uniq 機能が組み込まれたのは Version 7 Unix、つまり Unix の開発者が組み込んだのです。これは 1
はじめに 多分これはガセネタです。おそらく日本だけで出回っているガセネタです。インタプリタにはそのような定義はありません。インタプリタは「ソースコードを読み込んで意味を解釈して実行するプログラム」 です。「1行ずつ」は些細な間違いとして「機械語に変換する」は完全に間違いです。ある程度詳しい人にとっては常識だと思うのですが。 おそらくコンピュータは機械語しか動かせないから、インタプリタも最終的に機械語に変換しているはずだという間違った思い込みからこのガセネタは広まってしまっているのでしょう。機械語に変換するのは面倒な処理です。速くなるかもしれませんが変換処理しなくて良いのだから普通はしませんよ。 コンパイラとインタプリタの定義 コンパイラとは コンパイラとは、ソースコードを元に実行可能なプログラムを生成するためのプログラムです。ユーザーは(ソースコードではなく)別に生成されたプログラムを実行
「POSIX」という用語が何を指すかですが、昔は POSIX.1 しかなかったので、POSIX.1 のことです。後に POSIX.2 が誕生しました。上記のリストに POSIX.1-2001 の前に空行を入れていますが、これは 1998 年に POSIX を策定していた団体が IEEE から現在の Austin Group (IEEE PASC と The Open Group と ISO/IEC JTC 1/SC 22 のジョイントワーキンググループ)に切り替わる重要なラインです。この後に POSIX.1 シリーズのさまざまな規格と POSIX.2、そしてSUS が統合されました。現在では POSIX.2 は POSIX.1 に統合されています。今は単に POSIX といえば、POSIX.1 しかありません。 Microsoft も Linux も Apple も POSIX API・コ
次のページ
このページを最初にブックマークしてみませんか?
『@ko1nksm's My Page - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く