2 ポイント 投稿者 GN⁺ 2024-02-12 | 1件のコメント | WhatsAppで共有
  • AhoはAWKで実装されたGitで、Gitの内部構造とGNU AWKの新機能を探るためのトイプロジェクト
  • 目的は実用ではなく娯楽と教育であり、Gitの代替ツールとして使うためのプロジェクトではない
  • 実行にはgawk 5.0以上が必要で、zlib圧縮には現在pigzを使用し、それ以外はGNU coreutilsが提供される環境を前提としている
  • Linuxの大半では実行可能だが、BSD/Mac環境にはあまり適していない
  • 実装済みの機能はinitadd/rmstatuscommit、読み取り専用のconfigcat-fileで、ネットワーク機能であるclonepushを追加する予定はない

Ahoの目的と範囲

  • Ahoは「AWKで実装されたGit」を目指すプロジェクト
  • Modern AWKが1行スクリプト以上のことをこなせることを示すためのトイプロジェクト
  • Gitの内部構造とGNU AWKの新機能を探ることに焦点を当てている
  • 実用的な用途よりも、娯楽と教育のためのプロジェクト

実行環境

  • 必要な実行環境は次のとおり
    • gawk 5.0以上
    • zlib圧縮用のpigz
    • GNU coreutils
  • ほとんどのLinuxでは実行できるが、BSDやMac環境には適していない

基本的な使用の流れ

  • source ./modpathで環境を準備した後、aho initを実行すると、.ahoディレクトリに空のGitリポジトリが初期化される
  • aho add -v .はファイルを追加しながら、.gitignoreLICENSEREADME.mdahoaho.awkinclude/*.awkのような項目を出力する
  • 新しいファイルを作成した後、再度aho add -v .を実行すると、そのファイルも追加される
  • .aho/配下にはGitに似た構造が作られる
    • branches
    • config
    • description
    • HEAD
    • index
    • objects
    • refs/heads
    • refs/tags
  • GIT_DIR=.aho git ls-files --stageにより、Gitツールが.ahoリポジトリのインデックス項目を読み取る例が示されている

実装済みの機能と残りの作業

  • 完了済みの機能
    • init
    • add/rm
    • status
    • commit
    • 読み取り専用のconfig
    • cat-file
  • まだ完了していない機能
    • reset
    • branch
    • switch
    • ls-files

ネットワーク機能は除外

  • ネットワーク機能を追加する予定はない
  • GNU AWKでネットワーク機能を実装することは可能だが、Ahoにclonepushを入れる予定はない
  • コントリビューションとして、AWKやGitに関する知識の向上に役立つ意見を歓迎している

1件のコメント

 
GN⁺ 2024-02-12
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 を置き換えたが、多くの場合逆効果になった。他のプログラマーが読みやすく、中規模から大規模のプログラムにまで拡張できる Perl コードを、単純で広く理解される方法で書く手段がなかったからだ
      誰もそれをうまくやれなかったという意味ではないが、業界全体での成功率が低かったため、Perl はかなり悪い評判を得ることになった
      Awk の復活を見たい。Awk は大きく拡張するのがそれほど容易ではないので、小さな Awk として始まったプロジェクトが、次の人に数千行規模の Awk コードベースとして引き継がれる危険は小さい。その代わり、比較的早い段階で、より拡張性があり保守しやすい言語で書き直されることになる
    • 人々がどう思おうと関係なく、Perl が気に入っていることに気づいた。最近作ったのはプログラム可能なパーティションエディタだ。sfdisk でパーティションを空にするのに似ているが、単純な削除以上のことをしたかったし、MBR と GPT のパーティションテーブルを組み合わせてハイブリッドを作りたかった
      楽しかったし、Perl はまた使うつもりだ。Awk もこれほど素晴らしいと分かったので、いつか使うかもしれない
      [1] https://github.com/csdvrx/hdisk/
    • Awk はものすごく有用だ。今週、大量の GB に及ぶ Postgres ログをパースして、「毎時ちょうどの直後の数分間に、最も多くクエリを投げていたユーザーは誰だったのか?」に答えるスクリプトを書いた
      いくつかの関数と合計 20 行強のコード、そして sort と uniq のパイプをいくつか使うだけで済み、かなり速かった。特に先頭に LC_ALL=C を付けるとさらに速い
      [0]: なぜこのような作業が不要になるほどオブザーバビリティがきちんと整っていなかったのか、と聞かれれば、その指摘は間違っていないが、時には与えられた現実の中で生きなければならない
      [1]: gawk がリストを作りながら一意にソートできることは知っている。障害対応の終盤で疲れていて、| sort | uniq -c | sort -rn の方がずっと思い出しやすかった
      [1].a: sort に -u 引数があることも知っている。カウントは提供しないし、一意化も uniq の実装よりかなり遅い
    • Perl が悪いという判断が、Awk ルネサンスの大きな原動力だ。最初から Perl を学ばなかった開発者たちはシェルと Python の隙間を埋める何かを求めており、私のように渋々 Perl を捨てた開発者もいる
      HN 好みの人々が Perl を「クールではない」と見なしたため、Perl と Perl で書かれたすべてのコードには、今や賞味期限が付いたようなものだ。しかし Awk は POSIX 標準なので、そうした人々が消し去ることはできない
    • AWK が好きだ。文字列中心の型付けは、Javascript プログラマーでさえ顔を赤らめるほどだ。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

    • この35 年の間隔は、編集者が「それで第 2 版はどうなっていますか?」と尋ねてきたときに聞かせるのにちょうどいい話だ
    • Brian Kernighan も参加している。K&R C の「K」であり、さらに多くの Unix 伝説の主役だ
  • 次のようなコードを見ると、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/

    • そちらの判断にも一理あると思う。gawk はすでに awk と異なる点が多すぎる。さらに区別される構文を追加するなら、単にフォークして別の名前を付けた方がよい
  • Linuxのコマンドラインが最高の開発環境だと言う理由を聞かれたら、よく挙げるツールの一つが Awk です。基本的なAwkを知っているだけでも、少ない記述で多くのことができ、IDEのほうがむしろ鈍く感じ始めます
    Awkを学びたい、かつ講義形式の学習が合っているなら、数年前にLinux Fest Northwest向けに作った発表をYouTubeに録画してあります: https://youtu.be/E5aQxIdjT0M

    • その一方で、Unicode対応が追加されたのはかなり遅く、おそらく2年ほど前のことです。他のシェルツールと同じく、パイプで内容をAwkに渡す場合にもエッジケースがあります
      CTRL+D のようなシーケンスは入力を打ち切ってしまう可能性があり、私の知らない他のエッジケースも何十個もあって、最悪のタイミングで噛みついてくるでしょう
      Awkは印象的なツールですが、台座に載せて祭り上げると弱点が見えなくなります。本格的な作業は、より専門化され現代的な、その作業に合ったツールへ移したほうがよい場合があります
    • AwkがどうやってIDEを置き換えるのですか? Awkは好きですし、時間をかけて学べば強力だということも分かっていますが、IDEがなかったら生産性は大きく落ちていたはずです
      IDEが行うことの大半はテキスト編集作業ではなく、コードを理解し、変更できるよう支援することです。間違っていると言いたいわけではなく、その発言の観点が気になります
  • 最初はこの名前が日本語の俗語で「馬鹿」を意味する aho(アホ)から来ているのだと思いましたが、Alfred Ahoが awka であることを思い出しました。もしかすると両方かも?

    • 両方だと思います。「Git」ももともと「間抜けな人」を意味する俗語だったので、気の利いた名前です
    • 最近聞いたのはReservation Dogsでした: https://en.wiktionary.org/wiki/aho#Navajo
    • 両方だと思います。本当に巧妙な言葉遊びです
  • 素晴らしいプロジェクトであり、良いアイデアです。基礎を理解することは、他のプロジェクトや問題を見る別の視点を与えてくれます
    以前、AwkでWebベースのWikiを作ったことがあります。理由は、メモリが非常に少ないLinksysルーターを使っていたからです
    Wikiがどのように動くのか、Awkで何ができるのか、その両方を学ぶのに役立ちました。依存できるライブラリがないので基礎部分を自分で実装する必要があり、そのおかげでしっかり理解できました

  • 「ここにネットワーク機能を追加する予定はない。もちろん可能ではあるが、cloneやpushはない」と言っていますが、同じコンピューター上の別ディレクトリにあるリポジトリからでも git clone はできますし、pushもできます

    • その通りです。ただ、ブランチがあるとローカルクローンを作る必要性はある程度下がります。実際にはローカルのgitリポジトリの複製にはrsyncを使っています。問題は何が最善かということです
    • あまりに当たり前なのに、gitを10年使っていて一度も試そうと思ったことがありませんでした
  • GNUユーティリティといくつかのプログラム、そしておそらくそれ以上はあまり使わずに、性能と機能の面で専用ツールを超える万能のデータベース兼処理ツールを作れるのではないか、という考えがずっと残っています。そう感じるのは私だけでしょうか?

  • 関連しているかもしれません
    sed-chess: https://news.ycombinator.com/item?id=37896854
    awk-raycaster: https://github.com/TheMozg/awk-raycaster

  • これが開発当時にはなかったcppawkを使っていれば、#include を使えたはずです。ファイル基準の相対パスでうまく動作し、AWKPATH は不要です
    前処理済みのプログラムを単一ファイルとして「ビルド」することもできるので、その後はcppawkが不要になります
    https://www.kylheku.com/cgit/cppawk/about/