make を実行したら
Makefile:2: *** missing separator. Stop.と出て止まった。原因はほとんどの場合、レシピ行（コマンドを書く行）の先頭がタブになっていないことです。まずはエラーメッセージにある行番号の行を開いて、行頭がタブかスペースかを確認してください。それで大半は解決します。タブに直したのにまだ消えない、という場合の原因もこの記事に順にまとめてあります。挙動はすべて手元の GNU Make で実際に再現して確認しています。
仕様の詳細は GNU Make 4.4 日本語マニュアル 第5章「ルールのレシピの書き方」 を参照してください。この記事はその実例・トラブルシューティング版です。
エラーメッセージの Makefile:2: の部分（ファイル名と行番号）を見て、そのMakefileの該当行を開きます。多くの場合、行頭がスペースになっているだけです。
まずは、patsubst の使い方から。
SRCS = main.c util.c parser.c
OBJS = $(patsubst %.c,%.o,$(SRCS))これで OBJS は main.o util.o parser.o になります。% がワイルドカードで、「.c で終わる各単語を、同じ名前の .o に置き換える」という意味です。この記事は patsubst を軸に、周辺でよく一緒に使う wildcard filter foreach までを逆引きでまとめたチートシートです。挙動はすべて手元の GNU Make で実行して確認しています（macOS標準の 3.81 と Homebrew の 4.4.1。関数の意味はこの範囲で違いはありませんでした）。
網羅的な仕様は GNU Make 4.4 日本語マニュアル 第8章「テキストを変換する関数」 にあります。この記事はその逆引き版です。
$(patsubst 検索パターン,置換パターン,対象の文字列) の3引数です。対象の文字列を空白で区切った単語ごとに、検索パターンにマッチしたものだけを置換パターンに差し替えます。
AI エージェント系の週間の利用状況確認ページ(Weekly Usage Limit Page)を探すときに迷子になるのでまとめておきました。
Codex, Claude Code, GitHub Copilot について調べてます。
「JOIN とだけ書いたら INNER JOIN になるのか」「LEFT JOIN と LEFT OUTER JOIN は違うのか」という疑問への答えを先に書くと、どちらもまったく同じものです。INNER と OUTER は書いても書かなくても意味の変わらないキーワードで、省略しても結果は 1 行も変わりません。
この記事では、省略形の対応表と「では実際どこまで省いて書くか」の指針、そして JOIN の省略とよく混同される「カンマ結合(FROM a, b)」がなぜ別物なのかを、実際に動かした結果つきで整理します。動作確認は 2026年7月に PostgreSQL 17.10 / MySQL 8.4.10 / SQLite 3.51.0 と Oracle Database Free(23ai系, 23.26.2.0.0)で行いました。JOIN そのものの種類と結果の違いは SQL の JOIN の種類と違いまとめ — INNER/LEFT/RIGHT/FULL/CROSS【2026年更新】 にまとめているので、そちらもどうぞ。
古い Oracle のコードを読んでいると、FROM にテーブルをカンマで並べて WHERE で結合したり、WHERE a.id = b.id(+) のように (+) が付いていたりする SQL に出会います。これは Oracle が ANSI の JOIN 構文に対応する前から使われてきた旧記法で、(+) は Oracle 独自の外部結合演算子です。
結論から言うと、カンマ結合+WHERE は INNER JOIN、(+) は LEFT JOIN / RIGHT JOIN に対応します。この記事では実際の Oracle Database で両者の結果が一致することを確認しながら、書き換えの対応表と、書き換え時に踏みやすい Oracle 固有の癖をまとめます。なお、Oracle 公式マニュアルも新しく書くなら ANSI 構文を推奨しています(後述)。
実測環境は Docker の gvenzl/oracle-free:23-slim-faststart(バナー表記は Oracle AI Database 26ai Free Release 23.26.2.0.0)です。比較用の PostgreSQL 17.10 / MySQL 8.4.10 も Docker で動かしています。サンプルは次の2表です。
INNER JOIN と LEFT JOIN の違いは一言でいうと、相手のいない行を結果に残すかどうかです。INNER JOIN(内部結合)は両方のテーブルに対応する行があるものだけを返し、LEFT JOIN(左外部結合)は左のテーブルの行を全部残して、相手がいない行は右側の列を NULL で埋めます(これを NULL パディングと呼びます)。
この記事では同じデータに両方を実行して結果を見比べたあと、条件を ON に書くか WHERE に書くかで LEFT JOIN の結果が変わる罠と、「LEFT JOIN は遅いのか」という疑問を扱います。実行結果はすべて PostgreSQL 17.10 で実際に確認したもので、ON と WHERE の罠については MySQL 8.4.10 でも同じ結果になることを確認しています。JOIN 全種類のまとめは SQL の JOIN の種類と違いまとめ — INNER/LEFT/RIGHT/FULL/CROSS【2026年更新】 にあります。
社員表 emp と部署表 dept を使います。
続きを読む INNER JOIN と LEFT JOIN の違い — 結果がどう変わるか実例で確認Android で「アプリを終了したい」と調べると、finish()、finishAndRemoveTask()、moveTaskToBack(true) が候補に出てきます。名前だけ見ると似ていますが、やっていることは違います。
この記事では、最小 Activity で実際にログを取り、3つの違いを整理します。
ImageMagick で JPEG や PNG を処理していると、次のような警告に出会うことがあります。
identify: CorruptImageProfile `bad.jpg' (XMP) @ warning/profile.c/ValidateXMPProfile/2011.
これは画像に埋め込まれた XMP メタデータを ImageMagick が XML として読もうとして、壊れていると判断したときの警告です。画像のピクセル変換そのものが失敗しているとは限りません。
この記事では、壊れた XMP 入りの JPEG を手元で作って、xmp:validate を付けたときに何が起きるかを確認します。
xmp:validate は ImageMagick の -define で指定する設定です。
公式の defines ページでは、xmp:validate={true,false} は「画像に埋め込まれた XMP プロファイルを検証する」と説明されています。
XMP は、ざっくり言うと画像に入る XML 形式のメタデータです。撮影・編集ソフト・権利情報・説明文などが入ることがあります。ImageMagick 側では、XML delegate が有効なビルドだと、この XMP を XML として読めるか確認できます。
手元の ImageMagick 7.1.2-27 では、xmp:validate=true を明示したときに CorruptImageProfile ... (XMP) の警告を確認しました。公式説明には「デフォルトで検証」とありますが、少なくともこの環境では、素の identify や変換では警告が出ませんでした。バージョンやビルド設定で挙動が違う可能性があるので、まず自分の環境で確認するのがよいです。
確認環境は以下です。
Version: ImageMagick 7.1.2-27 Q16-HDRI aarch64 e4c2b403b:20260705 https://imagemagick.org Features: Cipher DPC HDRI Modules Delegates (built-in): bzlib freetype heic jng jpeg lcms ltdl lzma png tiff webp xml zlib zstd
まず、わざと XML として壊れた XMP ファイルを作ります。
printf '\xff\xfe\x00\x00not xml\n' > bad.xmp magick -size 32x32 xc:white base.jpg
普通に -profile bad.xmp すると環境によっては追加時点で警告されるので、ここでは xmp:validate=false を付けて、壊れた XMP を持つ JPEG を作ります。
magick base.jpg -define xmp:validate=false -profile bad.xmp bad.jpg
XMP プロファイルが入っていることは identify -verbose で確認できます。
magick identify -verbose bad.jpg 2>/dev/null | grep -Ei 'profiles|profile-xmp'
出力:
Profiles:
Profile-xmp: 12 bytes
xmp:validate=true を付けて identify します。
magick identify -define xmp:validate=true bad.jpg echo $?
手元ではこうなりました。
bad.jpg JPEG 32x32 32x32+0+0 8-bit Grayscale Gray 256c 210B 0.000u 0:00.001 identify: CorruptImageProfile `bad.jpg' (XMP) @ warning/profile.c/ValidateXMPProfile/2011. 0
ここで大事なのは、終了コードが 0 のままだったことです。つまり、少なくともこのケースでは「警告は出るが、コマンドとしては成功」です。スクリプトが stderr の文字列を見て失敗扱いしている場合は別ですが、終了コードだけを見る処理なら失敗にはなりません。
ログに警告を出したくないだけなら、-quiet で警告は消えました。
magick identify -quiet -define xmp:validate=true bad.jpg echo $?
出力:
bad.jpg JPEG 32x32 32x32+0+0 8-bit Grayscale Gray 256c 210B 0.000u 0:00.001 0
ただし、これは警告を黙らせるだけです。壊れた XMP は画像内に残ります。
XMP の検証自体を止めるなら、入力ファイルより前に -define xmp:validate=false を置きます。
magick identify -define xmp:validate=false bad.jpg echo $?
出力:
bad.jpg JPEG 32x32 32x32+0+0 8-bit Grayscale Gray 256c 210B 0.000u 0:00.000 0
変換でも同じ考え方です。
magick -define xmp:validate=false bad.jpg out.png
-define は入力を読む前に効かせたいので、迷ったら入力ファイル名より前に置くのが安全です。
壊れた XMP が不要なら、検証を止めて読み込み、そのあとで XMP プロファイルだけ削除します。
magick -define xmp:validate=false bad.jpg +profile xmp clean-no-xmp.jpg echo $?
出力:
0
削除後のファイルを確認します。
magick identify -verbose clean-no-xmp.jpg 2>/dev/null | grep -Ei 'profiles|profile-xmp'
出力は空でした。さらに、削除後のファイルは xmp:validate=true で読んでも警告が出ません。
magick identify -define xmp:validate=true clean-no-xmp.jpg echo $?
出力:
clean-no-xmp.jpg JPEG 32x32 32x32+0+0 8-bit Grayscale Gray 256c 165B 0.000u 0:00.000 0
XMP だけでなく、EXIF や ICC などのプロファイル、コメント類も落としてよいなら -strip が使えます。
magick -define xmp:validate=false bad.jpg -strip clean-strip.jpg echo $?
出力:
0
-strip は画像を軽くしたいときには便利ですが、色管理の ICC プロファイルや撮影情報も落ちます。Web用サムネイルなら問題ないことが多い一方、印刷・写真管理・権利情報を残したい用途では雑に使わない方がよいです。
目的別に分けると、こうです。
| 目的 | コマンド例 | 注意 |
|---|---|---|
| 警告をログに出したくないだけ | magick identify -quiet -define xmp:validate=true bad.jpg | XMP は残る |
| XMP 検証をスキップしたい | magick -define xmp:validate=false input.jpg output.png | 壊れた XMP を温存する場合がある |
| XMP だけ消したい | magick -define xmp:validate=false input.jpg +profile xmp output.jpg | XMP 内の説明・権利情報も消える |
| 全メタデータを消してよい | magick -define xmp:validate=false input.jpg -strip output.jpg | EXIF/ICC/コメントも消える |
Webアプリの画像変換で「ユーザー投稿画像を縮小して表示するだけ」なら、-define xmp:validate=false と -strip の組み合わせで済むことが多いです。逆に、写真のメタデータや色プロファイルを大事にする処理では、-strip ではなく +profile xmp のように削除対象を絞った方が安全です。
xmp:validate は、画像のピクセルではなく XMP メタデータの検証に関わる設定です。CorruptImageProfile ... (XMP) が出ても、まずは終了コード、出力ファイル、XMP が必要かどうかを分けて見た方がよいです。
今回の手元検証では、警告が出ても終了コードは 0、-quiet は警告を隠すだけ、xmp:validate=false は検証を止める、+profile xmp と -strip はメタデータを実際に削除する、という違いが確認できました。
関連:
ECOOP（European Conference on Object-Oriented Programming）は、1987年から毎年ヨーロッパで開かれているプログラミング言語分野の国際会議です。名前のとおりオブジェクト指向プログラミングの会議として始まり、現在はプログラミング言語全般を扱う、ヨーロッパで最も歴史の長い年次会議になっています。
先にお断りしておくと、当サイト（ecoop.net）はこの会議とは無関係の個人サイトです。「ecoop」で検索してここへ着いた方の多くは会議を探していると思うので、この記事で会議の概要と、公式情報・論文の入手先をまとめておきます。
Makefileを書いていると、$@ や $< みたいな記号や、= と := の使い分けで手が止まりがちです。この記事は変数まわりだけを逆引きでまとめたチートシートです。挙動はすべて手元の GNU Make で実行して確認しています。
もっと踏み込んだ仕様は GNU Make 4.4 日本語マニュアル 第6章「変数の使い方」 を参照してください。この記事はその逆引き版です。
= と := の違い（ここだけは押さえる）いちばん引っかかるのがこれです。
= … 遅延展開。右辺は使うときに評価される。:= … 即時展開。右辺はその行を読んだ時点で評価される。次の Makefile で違いが出ます。