はてなキーワード: awkとは
あんさん、Dockerとか言ってるしあんまりシェルスクリプトの凄まじい現場とか見たこと無いのでは。
シェルってのは人間の向けのコマンドの出力結果をawkとかsedで分解して後続につなげるもんなんで出力結果が変わると困る。ただ、manにはこういう処理で使えるほどの詳細な挙動は書いてないことが多い。
そして、シェルは出力結果おかしくても型とかじゃなくて文字列処理だから割りと後続処理が実行できちゃう。おかしい箇所を発見するのも時間がかかる。
そういうことが無いようにバリデーションのコードとか書き始めると複雑で何百行にもなるシェルスクリプトができて、これが一層壊れやすいし保守開発がめんどいことになる。
これは楽天モバイルアドベントカレンダーの出遅れ記事です。嘘です。すいません。
インディアンスの楽天モバイルネタ最高だったのでこの記事を書きました。
1プランでわかりやすい料金体系、最低金額は無料、契約して1年間無料というすごい携帯キャリアです。
私は今年の3月から使っており、その品質には概ね満足していました。ところが11月中頃（曖昧）から楽天モバイルの圏外が頻発するようになりました。
ローミング終了に伴い一部エリアでは使えなくなるかもという話は知っていましたが、私がいるのは都内の3線利用できる駅前エリアで今ままでもパートナー回線を使ったことがありません。
おかしいなーと思いつつちゃんとログを取ろうと思い、楽天モバイル端末のWiFiアクセスポイントをONにして手元のノートPCから疎通確認をしてログをとることに。
楽天モバイルのDNSが落ちたことはあった時はDNS設定いじればどうにかなったけど、そもそも圏外はどうしようもありません。
crontabもないし、shじゃないし、tail,awk,uniqもないし面倒でした。
5分に一回 1.1.1.1 にpingを飛ばしてその結果をログに残しました。
以下はbatで書いた処理
@echo off ping -n 1 1.1.1.1 | findstr /i "TTL" > nul if %ERRORLEVEL% equ 0 ( set ret=success ) else ( set ret=failure ) echo %date% %time% %ret% >> %~dp0check_net.log
-- tail -3 相当のps type .\check_net.log | select -last 3 2021/12/27 22:20:02.44 success 2021/12/27 22:25:06.00 failure 2021/12/27 22:30:05.99 failure -- awk '{print $1, ":", $3}' | uniq -c 相当のps type .\check_net.log | %{$tmp=($_.toString() -split("\s+"));echo ($tmp[0] + ":" +$tmp[2])} | group -NoElement Count Name ----- ---- 143 2021/12/19:success 6 2021/12/19:failure 208 2021/12/20:success 81 2021/12/20:failure 279 2021/12/21:success 9 2021/12/21:failure 221 2021/12/22:success 67 2021/12/22:failure 101 2021/12/23:failure 188 2021/12/23:success 277 2021/12/24:success 12 2021/12/24:failure 144 2021/12/25:success 69 2021/12/25:failure 287 2021/12/26:success 2 2021/12/26:failure 43 2021/12/27:failure 225 2021/12/27:success -- 時間ごと type .\check_net.log | sls failure | %{echo $_.toString().Substring(11,2)} | group -NoElement | sort Name Count Name ----- ---- 21 0 17 1 19 2 20 3 40 4 47 5 42 6 41 7 21 8 9 9 17 10 14 14 18 15 8 16 23 17 14 18 6 19 1 20 6 21 7 22 5 23
ログが不十分なのは途中でログファイル消しちゃったのと、ノートPCを閉じちゃってタスクスケジューラが止まってたタイミングがあるため
途中まで `findstr /i "TTL"` がなかったのでsuccessだけど実際は疎通できてないものがあります(pingの宛先ホストに到達できませんはsuccess扱いだった)
12/23がひどい。1日の35%繋がらない。「日本のスマホ代は高すぎる」けど繋がらないんじゃ意味ないんよ。
11~13時台は落ちてない。逆に何故。
5分に一回の計測なのでたまたまそのタイミングだけ疎通したりしなかったりってのはあるけど、その割合は落ち具合の体感と一致します。
テザリング利用では1日10GBの制限があるらしいですが、制限には引っかかっていません。
今も利用しているのは無料期間中なのと、楽天モバイル回線はYoutubeとかネットサーフィンとか止まっても許せる範囲で使っているからです。
これをメイン回線にしてたら緊急の連絡とか取れないだろうし、だいぶ困りそう。
書き込もうとしたけど、楽天モバイル回線は圏外で書き込めないので別の回線で書き込んでます。
RSRQは-15でした、どいひー
大体の場合において「bashが欲しい」という人はbashだけではなくgrepやawkやその他諸々のgnu ツールもまとめて欲しているが、それらを合わせてもwindows上で使うPowershellには機能レベルで遠く及ばないし、windows上のbash単体はLinux上のPowershell単体にも劣る。
Powershellでは、「文字列しか通さない古いパイプを通して文字列を切り貼りして受け渡しながら処理をする」なんて面倒なことはない。
bash+gnuツールだと別コマンドで文字列切り貼りしなきゃ取得できないメタデータも、Powershellならパイプでオブジェクトを渡せるから始めからオブジェクトのプロパティとして付いてくる場合が殆どだ。
windows上なら.net経由でシステムの様々な部分へのアクセスも可能だし、COMObject経由でofficeソフトそのものを直接操作もできる。
サードパーティーのモジュールで無理矢理データを弄るんじゃなくて実際にofficeファイルを吐くプログラムそのものをPowershellから操作できる。
なので、Powershellの記事によく付く「こんなのよりbash(+gnuツール)使いたい」ってのは「LinuxでPowershell使いたい」って言ってるようなもんだって分かって欲しい。
windows上においてはbashはPowershellの肩代わりは出来ない。
少し前からLinux上でPowershell動くようになったけど、LinuxユーザがPowershell一から学ぶ価値あるかと言われると、はっきり言って「あんまり無いかな」とは思う。
azure関連のコマンドモジュールがPowershellしかないヤツもまだあるみたいだから、azure触るためだけにwindows用意しなきゃならない事態を防ぐ程度の意味合いしかないような気はする。
そういうモジュールがLinux上のPowershellに対応してんのか知らんけど。
WSLでLinuxが丸々windowsに取り込まれたおかげでカジュアルなwindows上のbash需要も殆どは満たせる時代になったのは良いことだ。
別にPowershellのことを詳しく調べろとは言わないが、bashじゃwindows上のPowershellの肩代わりは出来ないって事だけは覚えておいて欲しい。
最初のプログラミング言語として最もおすすめなのは、Bourne (Again) Shell。通称sh(bash)です。shはUNIXの標準的なシェルであり、bashはその拡張です。現在、多くのLinuxディストリビューションでは、bashが標準のシェルです。以下、これらのシェルの上で動作するコマンド言語およびそれによって作られたプログラムを指して「シェルスクリプト」と呼ぶことにします。
シェルスクリプトを最初のプログラミング言語におすすめする理由は、主にその実用性にあります。ほとんどのプログラミング学習者にとって、プログラミングで実現したいことは、「10000以下の素数を求める」などの教科書の課題のようなものではなく、大量のファイルから情報を検索するとか、インターネットから定期的にコンテンツを取得する、などの具体的なタスクのはずです。シェルスクリプトを使えば、後者のような実用的なプログラムを手軽に作成できます。一方、多くのプログラミング入門書には、制御構文などの細かい説明はあっても、後者のようなトピックはあまり載っていません。というのも、そのような機能は汎用的なプログラミング言語（C、Java、Python、Rubyなど）のコアの機能ではないからです。それらの機能は通常、ライブラリによって提供されます。したがって、汎用的なプログラミング言語で実用的なことをしようと思えば、外部モジュールの読み込みや、場合によってはパッケージ管理ツールを使ったライブラリのインストール方法などを学ばなければいけません。これらは、初学者にはいささかハードルが高いです（たとえば、Webフロントエンドのツール群を初学者が独学でインストールするなどは、ほぼ不可能でしょう）。一方、シェルスクリプトでは、grep、sed、awkのようなシェル上のユーティリティは全て、他の言語における組み込みの関数と同様です。つまり、モジュールのインポートや初期化処理などを行わずに使用することができます。
また、シェルスクリプトは、より本格的な言語やフレームワークへステップアップする過程としても非常に適しています。プログラミング入門書ではほとんど語られないことですが、プログラミングにおいては「プログラミング言語以外の技術」がプログラミング言語自体と同様に重要です。たとえば、ファイルやディレクトリを操作するには、OSのファイルシステムにアクセスしなければいけませんし、インターネットからコンテンツを取得するには、HTTPというネットワークプロトコルを知らなければいけません。シェルスクリプトを使う場合、それら「プログラミング言語以外の技術」を自然に利用します。それらは、プロのエンジニアを目指す上でも欠かせない知識です。また、多くのプログラミング言語では、制御構文を用いて変数の値を更新していくプログラミングスタイルが取られます。一方、シェルスクリプトでは、コマンドの出力を他のコマンドの入力に渡してデータを変換するプログラミングスタイルが取られます。後者のスタイルは、現代のソフトウェア開発では多くの場合、良いスタイルだと認識されています。シェルスクリプトを最初に学ぶことで、そのような良いプログラミングスタイルが身につきます。
シェルスクリプトを体系的に学ぶならば、次の文献が信頼できます。
パイプでつないでawk使ってハッカー気分かもしれないけどお前の書いてるスクリプトクソクソクソオブクソだから
おとなしく
subprocess
＜追記＞
本物のハッカーである皆さんはどしどし使ってくれて大丈夫ですよ＾＾；
そうですね、熱くなって言い過ぎました。
個人がターミナルに打ち込む一度きりのコマンドはOK、ファイルに保存した瞬間に違法としましょう。
＜追追記＞
いやあ思いのほかBuzzっちゃって＾＾；
awkは適当に思いついたから入れただけでパイプ使ってるんだから他のコマンドも入ってますよ＾＾；
grepとかsedとかPythonで同様のことができる（実行時間が現実的な範囲で収まる）ならPythonの関数でお願いします。
読めないのか
読めませんよ。意図が。$1、$2とだけ書かれててそこにどういう値が入っているべきなのかコメントは書かれてませんし＾＾；
ハッカーの皆さんは当然コメントも書いてくださってますよね＾＾；
NOV1975 追記で日本語が読めない増田だということがわかったし、業務を任せられない増田ということもわかった。君は一体何の増田なんだ
昔、伊藤という優秀なCTOがおって、1週間でソーシャルブックマークサービスをこしらえたり、Linuxカーネルのソースを読んでみたり、意識の高いエントリを書いたりして、業界の尊敬を集めておった。
その伊藤が、githubのとあるプロジェクトページに目を止めた。明らかに個人開発で、プルリクの一つもなく、starも2,3というレポジトリだったが、伊藤は少し首をかしげて、感心したようにブックマークしたそうな。
それを見たユーザーが、あの伊藤さんが無言ブクマするぐらいだから、きっとこれはすごいレポジトリに違いない、これを書いたエンジニアは天才だ、と口々に言って大騒ぎになった。
件のプロジェクトはあっという間に4桁のstarがつき、contributorsもわんさか増えていく。
作者のエンジニアが気を良くして、転職ドラフトに出てみると、提示年収もうなぎのぼりに上がって、プログラマは高額年収で有力ベンチャーに転職していったそうな。
その転職先に伊藤と親しい者がいて、マネージャーが「あの伊藤さんが認めた人材です」と言うものだから、ソースを見てみるが、どうにも才能を感じぬ。
「Perlのプロジェクトなのに、ソースがどう見てもawkに見えたものでね。はてな、と思ってブクマしたのだよ」
日経xTECHの元記事を読んでもCOBOLの特徴があんまり伝わってこない感じだし、かといってそれをディスってもしょうがないので、書いてみた。
https://anond.hatelabo.jp/20190205192741
COBOLは本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyやPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルなデータ処理を想定している感じ。
SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通はJavaやRubyで全体の流れを記述してデータベース入出力をSQLで書く。COBOLもそんな感じで、全体の流れをJCLやShellスクリプト、あるいはJP1のような運用管理ソフトで書く。SQLの1個の処理に相当するのがCOBOLのコンパイル単位で、それごとにソースファイルが分割される。ひとつのソースファイルに2個以上の処理を書くこともできるけど普通はしない。ここまで理解すると古いCOBOLに1ファイル内のすべての処理に影響するグローバル変数しかないのや、今のCOBOLにコンパイル単位をまたぐ真のグローバル変数がないのも、それほどクリティカルではないことがわかると思う。もし、本当に複数の処理にまたがる値が必要なら、データベースに格納してしまえばいいんだし。
で、SQLでいうところのデータベースに相当するのがCOBOLではデータファイル。sedやawkでテキストファイルやCSVファイルを行ごとに処理するのとちょっと似てるけど、COBOLの場合は固定長ファイルという点が違う。改行文字は入ってなくて、たとえば150バイトごとに次のレコードみたいな形式。これの1レコードごとに何月何日何時に〇〇という商品を□□円で売ったとか書いてあるのが典型的なデータの内容。それを集計して今日は〇〇が何個売れて売上がどれだけあったとか、出金合計がいくらで入金合計がいくらで、みたいな財務諸表を作ったり。SQLと同じように税率なんかが書いてあるマスタデータと、日々の売り上げが書いてあるトランザクションデータがあって、突き合わせたりということもする。こういう集計処理だからUIはなくて、夜中に自動起動するようなバッチプログラムが主な使われ方。（混乱するから余談だけど、今のCOBOLはSQLを使って普通のRDBにもアクセスできる。ただ使い方としては、RDB→ファイル処理→ファイル処理→ファイル処理→ファイル処理→ファイル処理→RDBみたいに、最初と最後だけみたいなのが普通）
入出力がファイルだから今の感覚で考えるとアクセスは遅い。でもメリットもあって、1回に1行しかメモリに乗せないからどんな巨大なデータでも時間さえかければ処理できる。それこそ国民ひとりひとりの年金データとかね。あと、途中でバグや不正データで止まってもデータを失うのは最小限で済むので復旧が比較的楽だったり。
データベースの話に戻ると、テーブル定義はどこに書いてあるかというとデータファイル側ではなくてCOBOLプログラム側、というのがSQLと一番違うところかも。つまり、このデータファイルの構造はこれこれこうなっていると想定して読みます、とソースコードに自分で書く。当然実際のデータ構造がそれと違ってたらおかしくなる。
まあそんな感じで80年代くらいに会計処理をする目的だったら悪い言語ではなかったので、銀行や官公庁とか、電力水道ガスといったライフラインを扱う大企業がこぞって導入して今に至る感じ。普通の大企業は途中でSunとかに置き換えてその後Linuxやクラウドにさらに置き換えたりしたけど、最初に作ったシステムが大きければ大きいほど、重要であれば重要であるほど現代的な環境に置き換えられないというのが今の課題。