AWKで実装されたGit、Aho
(github.com/djanderson)- AhoはAWKで実装されたGitで、Gitの内部構造とGNU AWKの新機能を探るためのトイプロジェクト
- 目的は実用ではなく娯楽と教育であり、Gitの代替ツールとして使うためのプロジェクトではない
- 実行には
gawk5.0以上が必要で、zlib圧縮には現在pigzを使用し、それ以外はGNU coreutilsが提供される環境を前提としている - Linuxの大半では実行可能だが、BSD/Mac環境にはあまり適していない
- 実装済みの機能は
init、add/rm、status、commit、読み取り専用のconfig、cat-fileで、ネットワーク機能であるcloneとpushを追加する予定はない
Ahoの目的と範囲
- Ahoは「AWKで実装されたGit」を目指すプロジェクト
- Modern AWKが1行スクリプト以上のことをこなせることを示すためのトイプロジェクト
- Gitの内部構造とGNU AWKの新機能を探ることに焦点を当てている
- 実用的な用途よりも、娯楽と教育のためのプロジェクト
実行環境
- 必要な実行環境は次のとおり
gawk5.0以上- zlib圧縮用の
pigz - GNU coreutils
- ほとんどのLinuxでは実行できるが、BSDやMac環境には適していない
基本的な使用の流れ
source ./modpathで環境を準備した後、aho initを実行すると、.ahoディレクトリに空のGitリポジトリが初期化されるaho add -v .はファイルを追加しながら、.gitignore、LICENSE、README.md、aho、aho.awk、include/*.awkのような項目を出力する- 新しいファイルを作成した後、再度
aho add -v .を実行すると、そのファイルも追加される .aho/配下にはGitに似た構造が作られるbranchesconfigdescriptionHEADindexobjectsrefs/headsrefs/tags
GIT_DIR=.aho git ls-files --stageにより、Gitツールが.ahoリポジトリのインデックス項目を読み取る例が示されている
実装済みの機能と残りの作業
- 完了済みの機能
initadd/rmstatuscommit- 読み取り専用の
config cat-file
- まだ完了していない機能
resetbranchswitchls-files
ネットワーク機能は除外
- ネットワーク機能を追加する予定はない
- GNU AWKでネットワーク機能を実装することは可能だが、Ahoに
cloneやpushを入れる予定はない - コントリビューションとして、AWKやGitに関する知識の向上に役立つ意見を歓迎している
1件のコメント
Hacker News のコメント
Awk は素晴らしい。Unix 系ならほぼどこにでもある完全なプログラミング言語なのに、実際にはパイプされた標準出力からテキスト片を抜き出す 1 行コマンドとして主に使われているように思う
しかし Awk は汎用スクリプト言語としても使えるし、この用途では多くの面で Bash より優れている。現場で Awk スクリプトをもっと頻繁に見かけない理由が気になる。Perl がシェル、Awk、sed の長所を 1 つの言語にまとめようとし、その後、人々が Perl を悪く見て離れていった流れのせいかもしれない
[1] NetBSD ソースコードからの任意の抜粋: https://github.com/NetBSD/src/blob/trunk/sys/dev/eisa/devlis...
誰もそれをうまくやれなかったという意味ではないが、業界全体での成功率が低かったため、Perl はかなり悪い評判を得ることになった
Awk の復活を見たい。Awk は大きく拡張するのがそれほど容易ではないので、小さな Awk として始まったプロジェクトが、次の人に数千行規模の Awk コードベースとして引き継がれる危険は小さい。その代わり、比較的早い段階で、より拡張性があり保守しやすい言語で書き直されることになる
楽しかったし、Perl はまた使うつもりだ。Awk もこれほど素晴らしいと分かったので、いつか使うかもしれない
[1] https://github.com/csdvrx/hdisk/
いくつかの関数と合計 20 行強のコード、そして sort と uniq のパイプをいくつか使うだけで済み、かなり速かった。特に先頭に LC_ALL=C を付けるとさらに速い
[0]: なぜこのような作業が不要になるほどオブザーバビリティがきちんと整っていなかったのか、と聞かれれば、その指摘は間違っていないが、時には与えられた現実の中で生きなければならない
[1]: gawk がリストを作りながら一意にソートできることは知っている。障害対応の終盤で疲れていて、
| sort | uniq -c | sort -rnの方がずっと思い出しやすかった[1].a: sort に
-u引数があることも知っている。カウントは提供しないし、一意化も uniq の実装よりかなり遅いHN 好みの人々が Perl を「クールではない」と見なしたため、Perl と Perl で書かれたすべてのコードには、今や賞味期限が付いたようなものだ。しかし Awk は POSIX 標準なので、そうした人々が消し去ることはできない
0、""、実際に何もないことが、すべて同じ偽値になる数値は Lua のように、数値を表す文字列と区別されない。ところが不思議と気にならない。数値は数値として、文字列は文字列として必ず保ちたいなら、値の前に
#や$のような印を付けて、後でsubstr()で取り除けばよいThe AWK Programming Language, Second Edition が 2023 年 9 月に出た
https://awk.dev
初版は 1988 年に出版され、ここで読める: https://archive.org/details/pdfy-MgN0H1joIoDVoIC7
議論: https://news.ycombinator.com/item?id=13451454
次のようなコードを見ると、
function read_objfile(obj, objpath, bytes, end_of_header, header, end_of_type, type, size, bytes_after_header)で大きな空白の後にある引数はローカル変数だ。値を渡すことはできるが、そう使うために作られたものではないGNU Awk に本物のレキシカル変数を束縛する
let文を入れるパッチを書き、function read_objfile(obj, objpath) { @let (bytes, end_of_header, header, end_of_type, type, size, bytes_after_header) { } }のように書けるようにした残念ながらプロジェクトには拒否され、名前を変えた GNU Awk のフォークを作るよう勧められたので、そうした
https://www.kylheku.com/cgit/egawk/about/
Linuxのコマンドラインが最高の開発環境だと言う理由を聞かれたら、よく挙げるツールの一つが Awk です。基本的なAwkを知っているだけでも、少ない記述で多くのことができ、IDEのほうがむしろ鈍く感じ始めます
Awkを学びたい、かつ講義形式の学習が合っているなら、数年前にLinux Fest Northwest向けに作った発表をYouTubeに録画してあります: https://youtu.be/E5aQxIdjT0M
CTRL+Dのようなシーケンスは入力を打ち切ってしまう可能性があり、私の知らない他のエッジケースも何十個もあって、最悪のタイミングで噛みついてくるでしょうAwkは印象的なツールですが、台座に載せて祭り上げると弱点が見えなくなります。本格的な作業は、より専門化され現代的な、その作業に合ったツールへ移したほうがよい場合があります
IDEが行うことの大半はテキスト編集作業ではなく、コードを理解し、変更できるよう支援することです。間違っていると言いたいわけではなく、その発言の観点が気になります
最初はこの名前が日本語の俗語で「馬鹿」を意味する aho(アホ)から来ているのだと思いましたが、Alfred Ahoが
awkのaであることを思い出しました。もしかすると両方かも?素晴らしいプロジェクトであり、良いアイデアです。基礎を理解することは、他のプロジェクトや問題を見る別の視点を与えてくれます
以前、AwkでWebベースのWikiを作ったことがあります。理由は、メモリが非常に少ないLinksysルーターを使っていたからです
Wikiがどのように動くのか、Awkで何ができるのか、その両方を学ぶのに役立ちました。依存できるライブラリがないので基礎部分を自分で実装する必要があり、そのおかげでしっかり理解できました
「ここにネットワーク機能を追加する予定はない。もちろん可能ではあるが、cloneやpushはない」と言っていますが、同じコンピューター上の別ディレクトリにあるリポジトリからでも git clone はできますし、pushもできます
GNUユーティリティといくつかのプログラム、そしておそらくそれ以上はあまり使わずに、性能と機能の面で専用ツールを超える万能のデータベース兼処理ツールを作れるのではないか、という考えがずっと残っています。そう感じるのは私だけでしょうか?
関連しているかもしれません
sed-chess: https://news.ycombinator.com/item?id=37896854
awk-raycaster: https://github.com/TheMozg/awk-raycaster
https://github.com/soimort/translate-shell
これが開発当時にはなかったcppawkを使っていれば、
#includeを使えたはずです。ファイル基準の相対パスでうまく動作し、AWKPATHは不要です前処理済みのプログラムを単一ファイルとして「ビルド」することもできるので、その後はcppawkが不要になります
https://www.kylheku.com/cgit/cppawk/about/