社内のテックトークで LT したスライドです
はじめに 開発部の ikasat です。 皆さんは git, ssh, rsync のような外部コマンドを呼び出すスクリプトを書きたくなったことはありますか? 個人的にこの類のスクリプトは最初はシェルスクリプトとして書くのですが、改修を重ねるうちに肥大化して処理も複雑になり、 後から Python のような汎用プログラミング言語で書き直すことがよくあります。 外部コマンド呼び出しを書き直す際に、Git 操作のために pygit2、 SSH 接続のために paramiko のようなライブラリをわざわざ使うのは大がかりだったり、 rsync に相当するようなこなれたライブラリが存在しなかったりする場合があります。 そのような時は標準ライブラリの subprocess モジュールを利用し、Python から外部コマンドを呼び出すことになるでしょう。 しかしながら、Python のチュートリアルペ
B! 63 0 0 0 今更ながら知ったこと。 通常の方法 in無し The for Loop (POSIX Shell Command Language) ;の省略 man bash その他の方法 参考 通常の方法 bashとかでよくやる方法は arg1.sh 1 2 3 4 5 #!/usr/bin/env bash for arg in "$@";do echo "$arg" done とする方法。 "$@"はスクリプトの引数を展開し、ダブルクォートしてあると 引数毎に分けてダブルクォートした状態で展開します。 1 2 3 4 $ ./arg1.sh a b c a b c "$*"とすると同じく展開しますがダブルクォートが全体について for文で回すと1つの引数として扱われます。 大概のシェルで同様の動作をします。 これは関数の引数も同じで、 arg2.sh 1 2 3 4 5 6
この記事は、 NTT Communications Advent Calendar 2022 4 日目の記事です。 こんにちは。 SDPF クラウド・仮想サーバーチームの杉浦です。 普段は OpenStack の開発・運用をしています。 みなさんはシェル芸と聞いてどのようなコマンドを想像しますか? 私は以下のような怖いコマンド 1 を想像していました # 無限に process を fork するコマンドです # 実行するときは自己責任でお願いします :(){ :|:& };: ですがシェル芸はもっと親しみやすくて 2 実用的なものです。 私はシェル芸のシェの字もできないくらいシェル芸初心者だったのですが、 1日1問、半年以内に習得 シェル・ワンライナー160本ノック という本を完走してシェル芸チョットワカルようになったので、本の宣伝をしつつ完走した感想を紹介しようと思います。 1日1問、
はじめに 1992 年に POSIX でシェルが標準化されて以来、シェルスクリプトの数値計算に expr コマンドは使いません。expr コマンドを使って計算していたのは Bourne シェル(古い UNIX の sh)時代の話で、現在の POSIX sh (dash、bash、ksh 等)時代では数値計算に expr コマンドは不要です。今どきはシェルの機能だけで整数の計算を行うことができます。「今どき」って一体いつからだって話なわけですが……。 注意 シェルスクリプトでパフォーマンスの話をするとすぐに「他の言語で〜」という方がいますが、私はどんなことにでもシェルスクリプトを使えなんて一言も言っていません。パフォーマンスを気にしている理由は、そこが実際にシェルスクリプトのボトルネックになるポイントだからです。そもそもシェルスクリプトと一般的な言語は言語設計レベルで得意なことが違います。ユ
はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね? ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか? まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか?
最近、リモートワークということもあり、ペアプロというかAWS、GCPなどの操作をする際に一緒に画面を見ながら作業する機会が多いです。若手の同僚がターミナルソフトを起動してコマンドを実行するのですが、傍から見ているとエイリアスなりキーバインドなりを使えば効率的に操作できるのにと思うことがあります。 最近はGUIで操作することが多いのでターミナルソフトでコマンド操作することがあまりないのかもしれませんが、私は少し前までは(クラウドしかできない)ITインフラエンジニアをやっており、プログラミングよりもコマンド操作するのが圧倒的に多かったため、ちょっとしたことならGUIよりもターミナルで操作することが多いです。Windowsを使っていますが WSL2 + Ubuntu 20.04 LTSで開発環境を整えているため、操作に不自由はほとんどしません。 この手のエイリアスやzshなどのオススメ設定はググ
会社の中でシェルスクリプトについての話をすることにしたので、このエントリはそのためのものです。 個人的な好みとかもいろいろ入ってしまっているので、そのあたりは取捨選択してください。 なぜ今シェルスクリプトを学ぶのか 公開されているSRE本をマルっとPDF化する SpotBugsのViolationレポートをMerge Requestのコメント投稿する ぼくの互換性についての考え方 何で書くか シェルスクリプトをうまく書くには ShellCheckを使う バッドパターンとその修正 line-by-lineの処理が多い lsを使う ls /directory | grep mystring ls | grep -v 'log$' lsの結果をループさせる 良いシェルスクリプトを書くためのTIPS set -euする 文字列は基本的にクオートする 局所変数にはlocalを使う 定数は読み取り専用
whichを使わない一番の理由はcoreutilsに入ってないから(commandはたいていのshellでbuiltin functionになっている)。 ash(1): command interpreter - Linux man page dash(1) - Linux manual page Bash Builtins (Bash Reference Manual) たぶんDockerfileでいろいろやっているときに身についた振る舞いだと思う。 ポータビリティを高めるとかの高い意識ではなく、何度もcommand not foundに遭遇して面倒になったことが主な動機で、そこから派生してwhichコマンドの存在を無視する(頼らない)ようになった感じ。 あと、軽量なDockerイメージを作るのがかっこいいと見做された時期があって(時期というより原則だけど)、インストールするパッケージ
シェルスクリプトは変数代入で = の前後にスペースを置けない!・・・の本当の理由を知ると優れた文法が見えてくるShellScriptBashUNIXshellPOSIX はじめに シェルスクリプトの変数代入で = の前後にスペースを置くことができない理由は、検索すれば「プログラマーの君! 勘違いするな! シェルスクリプトでは読みやすさのためにスペースを置くな!! という話」のような記事がすぐに見つかります。記事に書いてあるとおり変数代入とコマンド呼び出しと区別がつかないからです。それは間違いではないんですが、私はもう少し説明が足りないと感じています。そこで今回は = の前後にスペースを置けない本当の理由を解説したいと思います。 の前に皆さんにはこの話を読みながら、自分がシェルスクリプトの言語設計者だったとしたら、どういう言語仕様にするかを考えて欲しいです。なぜかと言うとシェルスクリプトの文
シェルスクリプトを書くのをやめる - blog.8-p.info これを見て: 夢の可能性が高くなってきたんですが、Perlのプラグマかなにかで、シェルスクリプトと混在できる……というか、存在しないサブルーチン呼び出しを外部コマンド呼び出しにするやつありませんでしたっけ— aereal / 青木華絵 (@aereal) 2021年9月16日 まじだ... https://t.co/IF6SyBR4o8— Kazuyoshi Kato (@kzys) 2021年9月16日 Shell - run shell commands transparently within perl - metacpan.org use Shell qw(cat ps cp); $passwd = cat('</etc/passwd'); @pslines = ps('-ww'), cp("/etc/passwd"
POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき!ShellScriptBashshellPOSIX はじめに find の出力を xargs にパイプで渡すというのはよく見かける使い方ですが、find -print0 | xargs -0 が使えない POSIX 準拠のシェルスクリプトでは find -exec {} + を使った方が良いです。安全かつ十分に速いからです。よく見かける -exec {} ; ではなく -exec {} + ですので間違えないようにしてください。多くのケースでは + の方が優れているのですが ; ばっかり使われているのを見ると、意外と知られてない気がします。 少しだけ予備知識として、-exec {} ; は -exec {} \; と ; をバックスラッシュでエスケープするのがよく見る使い方
TL; DR 変数をダブルクォートしない使い方は上級者向けの危険な機能です! $@ と $*(または配列の全要素)をダブルクォートしない使い方は知る必要すらありません! ShellCheck を導入すれば誰でも簡単に正しい書き方がわかります!! 2021-08-21 補足 この記事は dash や bash などの POSIX シェルの一般的な動作を解説しており zsh のデフォルトとは異なります。記事の中でも説明していますが zsh の場合はシェルのオプションを変更することで POSIX 準拠の動作に変更することができます。zsh に関しては後半の「zsh に関する注意点」も参照してください。 はじめに プログラミング言語は、言語によって記号の意味が異なることがよくあります。クォーテーションマークはその一つです。C 言語ではシングルクォートは文字リテラル(一文字)を意味し文字列はダブルク
こんにちは英語アレルギーなレガシーおじさんです 私みたいな人はGoogleさんに介助してもらわないとローマ字見ただけで蕁麻疹が出るのですがきっと他にも同じような人がいるはずと信じています。 さてそんな私の強い味方であるgoogle翻訳のCLI版であるtransコマンドですが いつの間にかUbuntuのリポジトリに取り込まれていました🎉 こいつですこいつ 今日たまたまこれ使おうと思ったらまだインストールしてない環境だったので こんなエラーが出ました $ apt show translate-shell Package: translate-shell Version: 0.9.6.11-1 Priority: optional Section: multiverse/misc Origin: Ubuntu Maintainer: Ubuntu Developers <ubuntu-deve
はじめに この記事は以下の記事で事故がなぜ起きたかを技術的に理解し筆者のtipsを共有しようと思い書きました。あくまで筆者のtipsですので、これが正しいとは限りません。 やはり、下記のコマンドが原因でした。 [root@foo script]# ls -l | sh 事故そのものは ls コマンドに -l を付けて実行してしまった事で、ls コマンドが出力したシンボリックリンクが以下の様になってしまったという話です。
bash のシェルスクリプトを書くときに、いつも脳死で以下をやっている。(同僚が整備してくれたものをコピペしている) エディタなり CI で shellcheck をまわす set -euxo pipefail と冒頭に書く こんな感じ #!/bin/bash set -euxo pipefail いつまでもコピペではさすがにアレなので、意味を調べたメモ。 shellcheck koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts イケてない書き方に警告を出してくれる それぞれの警告にはエラーコード割り振られていてとても便利 エラーコードごとに正誤例、解説が書かれているのでわかりやすい SC1000 の例 CI もそうだし、エディタのプラグインも充実 しているのでとりあえず入れておくと良い set
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く