Makefileを便利コマンドメモとして使うことに対する違和感 | takeokunn's blog
追記この記事に対するyasunoriの補足記事はこちら。 https://blog.yasunori0418.dev/p/appendix-makefile/ IntroductionyasunoriがZennに書いた「職場のプロジェクトに必ず配置しちゃうMakefileの話」というのがバズっています。 「コマンドが覚え辛い」という、どのプロジェクトにもあるような問題を「Makefileをコマンドメモとして整える」ことによって解決するという記事でした。 SNSやvim-jp slackを見ていると賛同の声が多い印象を受けています。 https://b.hatena.ne.jp/entry/s/zenn.dev/loglass/articles/0016-make-makefile 私個人も過去に同様のMakefileを作ったことがあるし、現職でもMakefileが入っているプロジェクトがあ
sudo su とかしてる人はだいたいおっさん
sudo su と sudo -s はほぼ同じ。実行されるシェルが異なることがある。 sudo su - と sudo -i もほぼ同じ。環境変数のクリア的な意味だと sudo su - の方が強い。 以下は別に読まなくてもいい。 su 別のユーザーでシェルを実行するコマンド。自分は「す」とか「えすゆー」とかと呼んでる。 元は super user とか switch user とか substitute user の略だったらしい。 デフォルトでは root になるが、引数でユーザー名を指定するとそのユーザーになる。 新ユーザーのデフォルトのシェルとして設定されているシェルが実行される。 入力するパスワードは新ユーザーのパスワード。 ~% su Password: (rootのパスワード) root@hostname:/home/tmtms# id uid=0(root) gid=0(r
【Go Dependencies コマンド】go install,go get,go mod download,go mod tidy
【Go Dependencies コマンド】go install,go get,go mod download,go mod tidy Goの開発をする際に、外部のモジュールやパッケージが必要になることが多いです。 Goにはモジュールやパッケージをダウンロード、インストールするためのコマンドが多く用意されていて、それぞれの振る舞いの違いや用途について理解するのに苦労しました。 本記事では、私が普段使うコマンドを列挙し、振る舞いや用途について言及していけたらと思います。 前提 Go Modulesに関するコマンドはGoのバージョンに大きく依存するため、バージョンには注意する必要があります 本記事はGo 1.19を対象としています go get <package-name> go getはgo.modファイルに記載された依存関係を更新し、go.modファイルを更新します この過程で、指定したパ
aws cli で DynamoDB を使う - Qiita
aws dynamodb create-table --table-name 'cities' \ --attribute-definitions '[{"AttributeName":"key","AttributeType": "S"}]' \ --key-schema '[{"AttributeName":"key","KeyType": "HASH"}]' \ --provisioned-throughput '{"ReadCapacityUnits": 5,"WriteCapacityUnits": 5}' TABLE='cities' aws dynamodb put-item --table-name $TABLE --item '{ "population": { "N": "38164" }, "date_mod": { "S": "1950-6-22" }, "key"
JSON を行単位にわかりやすく展開してくれるコマンド gron がピンポイントでとても便利
JSON を行単位にわかりやすく展開してくれるコマンド gron がピンポイントでとても便利 2022-06-13-1 [Programming] コマンドラインでの JSON の操作には jq (軽量JSONパーサ)[2017-10-24-1] を使っています。万能で便利なんですが、奥まったところにある値だけを取りたいときとかちょっと面倒なんですよね。ちらっと値を見たいだけなのにおおげさになっちゃいがち。 ということで、 gron というのを使ってみました。 GitHub - tomnomnom/gron: Make JSON greppable!JSONをgrepしやすくするコマンドラインツールgronの紹介 - Qiitagronでjsonの扱いが楽になった話 – Tower of Engineers あ、これでいいや。 いわゆる「顧客（＝私）が本当に必要だったもの」だわ。 例えば、
＠IT：Windows TIPS -- Tips：巨大なサイズのファイルを簡単に作る方法
巨大なファイルを使ってディスクやネットワークの速度を測定する ディスクやネットワークなどの性能（速度）がどのくらい出ているかを手っ取り早く調べるには、ある程度大きなデータファイルを用意しておいて、その読み書き速度や送受信速度を調べると簡単だ。 厳密なベンチマークツールがなくても、ファイルをコピーさせながら、その速度をタスクマネージャーやパフォーマンスモニターで見たり、完了するまでの時間を測定したりするだけでも大まかな速度は計測できる。 これを行うには、数十～数百GB以上のサイズのテストファイルが必要になる。本Tech TIPSでは、「fsutil.exe」というコマンドを利用して、こうした巨大なファイルを簡単かつ素早く作成する方法を紹介する。 fsutilコマンドで巨大なファイルを作成する Windows OSで巨大なファイルを作成するには「fsutil.exe」というコマンドがとても便利
Perlでコマンドラインオプションの解析に Getopt::Long を使う時、絶対に忘れてはいけない引数 - たごもりすメモ
Perlでコマンドラインオプションをparseしようと思うと組込みモジュールとしては Getopt::Std と Getopt::Long がある。が、long style option *1 つまり --option-name のようなオプションを解釈してくれるのは Getopt::Long だけだ。なので普通はこちらを使おう。 ただし 絶対にデフォルト、つまり以下のようにして使ってはいけない。 use Getopt::Long; my (@primary, @secondary, $silent); GetOptions( "server-primary|p=s" => \@primary, "server-secondary|s=s" => \@secondary, "silent|S" => \$silent ); これダメ！ 絶対ダメ！ 死ぬ！ 最初に結論を書く 必ず以下のように
shell のちょっとしたテクニック - odz buffer
後輩が cat README | tr ' ' '\n' | sort | uniq -c | sort -nr | head てなテクニックを見て、びっくりしたみたいな話をしていたのだが、こういうパイプラインを利用するテクニックを学んでいないのは色々損な気がする。 ていうか、サーバで丸一日以上かかるような処理を実行するのもしょっちゅうなのに、GNU screen も nohup も知らないってのはいろいろ支障があるような気もするのだが、だれも教えないものかなぁ。 ということで、bash or zsh のちょっとしたテクニックとか*1。リダイレクトとかパイプラインは略。 連続実行 単純に連続実行。 % foo; barfoo が正常終了したときだけ bar を実行 % foo && barfoo が正常終了しなかったときだけ bar を実行 % foo || bar&&、||は本来は論理演
404 Blog Not Found:There's more than one way to kill'em
2006年11月02日18:30 カテゴリ一日一行野郎 There's more than one way to kill'em こういう「他のコマンドを組み合わせても可能な便利系コマンド」を覚えるのは、よしあしだと思う。 Unixという考えかた Mike Gancarz / 芳尾 桂 訳 [原著: The Unix Philosophy] 技術メモ帳 - pgrep, pkill を使用してプロセスを殺す最近、会社でシェルの操作方法について教えているのだが、 pgrep / pkill / skill / pidof といった 便利なプロセス操作系コマンドを知らない人が実に多い。 例えば、pgrepはOS Xにはない。killallならあるけど。ちなみにFreeBSDには全部あるのだけど、使っている人はあまり見ないなあ。 現在のshellはaliasも充実しているので、例えば alias
技術メモ帳 - pgrep, pkill を使用してプロセスを殺す
最近、会社でシェルの操作方法について教えているのだが、 pgrep / pkill / skill / pidof といった 便利なプロセス操作系コマンドを知らない人が実に多い。 プロセスを殺すというのは、よくある作業なので 今回はコレについて書いてみる。 たとえば、これらのコマンドを知らない人が、 指定した名前のプロセスを kill する手順はだいたい 以下のようなものになることだろう。 $ ps aux | grep プロセス名 | grep -v 'grep' # コマンドの出力結果から pid を目で確認 12345 ... .. hoge .. .. $ kill 12345 この作業は非常に面倒で退屈だ。 もし殺さなければならないプロセスがたくさんあったときは どうするのだろうか。 おまけに、grep コマンド自身が候補に含まれてしまう事があるのだが、 grep -v grep
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linuxコマンドのお勉強 再帰的にパーミッションを変更 - Qiita
ls よりも exa を使おう！モダンな Linux コマンド達を紹介 - Qiita
「教えてください！！！」（1） Linux Square － ＠IT