为何在Makefile中调用printf时会出现不同的行为表现？

原因分析 #

这个表现差异本质是两种场景下调用的printf实现不同导致的：

• 当Makefile的编译规则（recipe）行只有单个简单命令、不包含任何shell特殊字符（分号、重定向符、管道符等）时，GNU Make会做执行优化：不会启动shell进程，直接通过fork/exec运行外部的/usr/bin/printf程序（属于GNU coreutils组件）。这个版本的printf支持%b格式符下的\x开头十六进制转义语法，会正确把\xff解析为对应的二进制字节输出。
• 当你在同一行用分号分隔多个命令、或是添加了重定向等操作时，命令行包含shell特殊字符，Make必须启动系统默认shell（通常是sh、dash等POSIX兼容shell）来执行整行命令。此时shell会优先调用自身内置的printf实现，而绝大多数POSIX兼容shell的内置printf严格遵循POSIX标准，%b格式符仅支持八进制转义序列，不识别\x开头的十六进制转义，因此会把\xff当成普通字符串直接输出字面量。

你观察到Make打印的执行命令完全一致，是因为Make仅输出了规则行的原始字面内容，无法体现是否经过shell处理的底层差异，并非转义字符被提前吃掉的问题。

解决方案 #

你可以根据场景选择以下任意一种修复方式：

• 强制调用外部printf：写全可执行文件路径/usr/bin/printf '%b' '\xff\xff'，确保所有场景下都会调用GNU coreutils的实现
• 替换为POSIX兼容的八进制转义：\xff对应的八进制表示为\377，改写为printf '%b' '\377\377'，内置和外部printf都可以正常识别
• 在Makefile开头指定使用bash作为执行shell：添加SHELL := bash配置，bash内置的printf支持\x十六进制转义语法

内容的提问来源于stack exchange，提问作者Cactus