macOS에서 find -printf가 unknown primary 오류를 낼 때: 오류가 파이프에 묻히는 경우까지 직접 시험한 결과

한 줄 요약: 이 맥의 find 에는 -printf 가 없고 그 실패는 파이프 끝에서 종료 코드 0 으로 가려지므로, -printf 를 아는지 먼저 시험하는 함수로 감싼다.

리눅스에서 쓰던 find d -type f -printf '%p\n' 을 맥 터미널에 붙였더니 아래처럼 실패한다. 이 글은 무엇으로 바꾸면 되는지, 그리고 오류 메시지를 못 보게 가려지는 자리(파이프 끝, 변수, set -e)에서 이 실패가 어떻게 보이는지를 이 맥에서 직접 만들어 보인다.

find: -printf: unknown primary or operator

같은 오류는 공개 이슈에도 남아 있다. 2022년 4월 time-ghc-modules 이슈 #8 은 macOS 에서 이 오류가 나고 “There’s no printf flag in man find as well” 이라 적었고, 2022년 11월 fzf-lua 이슈 #564 는 macOS Ventura 13.0 에서 같은 문구가 나온 것을 담았다. 확인한 환경은 macOS 26.6.2 arm64 의 /usr/bin/find(shell_cmds-329, BSD 계열), Homebrew 의 GNU findutils 4.11.0(gfind), bash 3.2.57, 시간대 Asia/Seoul(KST)이다. GNU 쪽은 리눅스가 아니라 이 맥에 설치한 gfind 로 시험했고, stat 은 이 맥의 /usr/bin/stat 이다.

용어 몇 개. find 는 폴더 아래를 돌며 조건에 맞는 파일을 찾는 명령이다. 서식 글자는 %s 처럼 어떤 값을 찍을지 고르는 기호다. 종료 코드는 대부분의 명령에서 0이 정상, 그 밖은 실패다. 파이프(|)는 앞 명령의 출력을 뒤 명령에 넘기는 연결이고, PIPESTATUS 는 bash 가 파이프 각 명령의 종료 코드를 모아 두는 배열이며, set -e 는 명령이 실패하면 스크립트를 바로 멈추게 하는 설정이고, 표준 오류는 오류 메시지가 나가는 별도의 통로다.

이 맥의 find 에는 -printf 가 없다

/usr/bin/find 에 -printf 를 주면 위 한 줄이 표준 오류로 나오고 종료 코드는 1이다. 이 맥의 man find 에는 -printf 가 한 번도 나오지 않았고(0줄), 같은 man 은 -print0 와 -maxdepth 를 POSIX 표준에 없는 확장 기능으로 적는다. 리눅스 쪽 man7.org 의 find(1) 는 -printf format 을 “File’s name” %p, “File’s size in bytes” %s, “File’s permission bits (in octal)” %m 처럼 서식 글자 목록과 함께 적는다. 이 옵션은 GNU 쪽 기능이고 이 맥의 find 는 그것을 구현하지 않았다.

오류가 파이프와 변수 안에서는 묻힌다

오류가 눈에 보이면 차라리 낫다. 아래는 같은 명령을 맥에서 여러 자리에 넣어 본 결과다. 시험 폴더에는 일반 파일 두 개가 있고 find 는 모두 /usr/bin/find 다.

쓰는 자리	결과
그냥 실행	오류 한 줄, 종료 코드 1
find … -printf … 2>/dev/null | sort | head -5 직후의 PIPESTATUS	1 0 0 (find 만 1)
out=$(find … -printf … 2>/dev/null)	종료 코드 1, 길이 0
find … -printf … 2>/dev/null | wc -l 로 센 줄 수	0
( set -e; find … -printf … 2>/dev/null; echo 계속 )	계속이 찍히지 않고 종료 코드 1
( set -e; find … -printf … 2>/dev/null | sort; echo 계속 )	계속이 찍히고 종료 코드 0

마지막 두 줄이 이 글에서 가장 조심할 점이다. 파이프로 이어진 명령의 종료 코드는 기본적으로 마지막 명령의 것이고, 마지막이 sort 면 0 이다. 2>/dev/null 로 오류 메시지까지 버렸다면 스크립트는 실패한 줄을 모르고 다음으로 가며, 변수는 빈 문자열이 된다. 이 조건이면 리눅스에서 잘 돌던 스크립트가 맥에서 오류도 없이 “파일이 없다”고 말하는 증상이 난다. PIPESTATUS 는 bash 전용이라 이 맥의 기본 셸 zsh 에서는 빈 값이고, 같은 1 0 0 이 소문자 pipestatus 에 들어 있었다. set -o pipefail 은 시험하지 않았다.

서식 글자는 하나씩 바꾼다

GNU find 4.11.0 의 -printf 서식 하나하나를 맥의 find·stat 조합으로 바꿔서 같은 줄이 나오는지 비교했다. 시험 폴더는 d/a.txt(6바이트, 권한 640), d/sub/b log.txt(12바이트, 권한 600), 링크 d/link(→ a.txt)이고 두 파일의 수정 시각을 2026-01-02 03:04:05 로 맞췄다. sort 로 정렬한 뒤 비교했다.

GNU 서식	맥 대체	결과
%p 경로	-print	같음
%f 파일 이름	-exec sh -c 'for p; do basename "$p"; done' sh {} +	같음
%s 크기	-exec stat -f '%N %z' {} +	같음
%m 권한(8진수)	-exec stat -f '%N %Lp' {} +	일반 권한(640, 600)은 같음, 아래 참고
%TY-%Tm-%Td 수정 날짜	-exec stat -f '%N %Sm' -t '%Y-%m-%d' {} +	같음
%P 시작점 뒤 상대 경로	폴더 안에서 find . -type f -print 를 돌려 앞의 ./ 를 sed 로 지움	같음
%y 유형 글자	-type d·-type f 를 나눠 앞에 글자를 붙임	링크를 뺀 폴더·파일은 같음. 링크는 GNU 가 l d/link 를 내므로 -type l 로 따로 처리해야 함
%l 링크 대상	stat -f '%Y' d/link	둘 다 a.txt
%u %g 소유자·그룹 이름	stat -f '%Su %Sg'	같음
%d 깊이	-print 뒤 awk -F/ '{print NF-1, $0}' (시작점을 ./ 없이 d 처럼 적었을 때. ./d 나 a/d 처럼 슬래시가 더 있으면 그 개수만큼 awk 값이 커짐)	같음
%T@ 에포크 초	stat -f '%m'	GNU 1767290645.0000000000, 맥 1767290645
'%p\0'	-print0	GNU find 안에서 -printf '%p\0' 와 -print0 는 같은 바이트

세 가지만 따로 짚는다. 첫째, %T@ 는 GNU 가 소수부까지 찍는다. man7 은 @ 를 “with fractional part” 라 적는다. 이 시험 파일은 touch -t 로 맞춰서 소수부가 0 이었으나 실제 파일은 0이 아닐 수 있다. 정수 초만 필요하면 맥의 stat -f %m 으로 충분하다.

둘째, 권한 %m. 맥의 stat -f %Lp 는 setuid 같은 특수 비트와 그 뒤에 오는 0 을 빠뜨린다. 파일 모드를 4755 로 두면 GNU %m 은 4755, 맥 %Lp 는 755 였고, 모드 4005 는 GNU 4005, 맥 %Lp 는 5 였다. stat -f %p 는 파일 종류 비트까지 낸 8진수라서 끝 4자리를 8진수 숫자로 바꾸면(printf '%o' 가 앞의 0 을 지워 GNU 출력 꼴이 된다) 맞았다. 일반 권한(640, 600)만 필요하면 %Lp 로도 같았다.

p=$(stat -f '%p' 파일); printf '%o' "$((8#${p: -4}))"   # GNU 의 %m 과 같은 꼴

모드 0000 부터 7777 까지 4096개 전부에서 GNU %m 과 이 정규화 값이 달랐던 경우는 0개였다. 같은 서식 글자도 도구마다 뜻이 다른 stat 쪽 사정은 이 블로그의 stat -c 글에서 따로 다뤘다.

셋째, 순서. -print0 로 낸 이름의 정렬 전 순서는 이 시험 폴더에서는 두 find 가 같았다(d/sub/b log.txt, d/a.txt). 폴더 하나의 결과일 뿐이므로 두 find 의 출력을 비교하거나 합칠 때는 정렬하는 편이 안전하다.

두 find 에서 모두 도는 함수

-printf 를 아는 find 인지 먼저 시험하고, 되면 그걸 쓰고, 안 되면 맥 문법을 쓰면 된다. 시험은 출력과 오류를 모두 버려 실패가 변수로 새지 않는다. 처음 만든 함수는 구멍이 하나 있었다. 이름이 -dash 인 폴더를 주면 맥 find 는 옵션으로 읽어 find: illegal option -- a 와 usage 를 찍고, GNU find 는 find: unknown predicate -dash’를 찍었는데, 두 경우 모두 함수의 종료 코드는 0 이었다. 마지막 명령이sort인 파이프라서 앞 실패가 가려진 것이다. 폴더 이름이-로 시작하면./` 를 붙이는 줄을 넣어 고친 최종 함수다.

find_sizes() {   # find_sizes 폴더 : 일반 파일을 "크기 경로" 로 경로순 정렬
  local d=$1
  [ -d "$d" ] || { echo "find_sizes: $d 디렉터리 아님" >&2; return 1; }
  case $d in -*) d=./$d ;; esac
  if find "$d" -maxdepth 0 -printf '' >/dev/null 2>&1; then
    find "$d" -type f -printf '%s %p\n' | LC_ALL=C sort -k2
  else
    find "$d" -type f -exec stat -f '%z %N' {} + | LC_ALL=C sort -k2
  fi
}

PATH 맨 앞에 /usr/bin/find·/usr/bin/stat 을 가리키는 링크 폴더를 둔 경우와 gfind·gstat(coreutils) 을 find·stat 이름으로 가리키는 링크 폴더를 둔 경우에 각각 이 함수를 돌렸다. 폴더 d 는 두 쪽 모두 6 d/a.txt 와 12 d/sub/b log.txt 로 같았고, -dash 와 ./-dash 는 둘 다 1 ./-dash/-n.txt, 없는 폴더 nodir 는 두 쪽 모두 find_sizes: nodir 디렉터리 아님 과 종료 코드 1이었다. 시험 출력은 두 번 실행해 같았다. 이 함수도 sort 로 끝나는 파이프라서 대시 가드로 막은 경우 밖에서 find 가 도중에 실패하면(읽기 권한 없는 하위 폴더 등) 그 실패를 종료 코드로 알려 주지 않는다.

이 PATH 링크 폴더는 Homebrew findutils 가 안내하는 gnubin 디렉터리를 PATH 앞에 둔 맥을 흉내 낸 것이다. 이 글의 해석으로는 그런 맥에서 find 가 GNU 판이 되어 -printf 가 잘 돌겠지만, 같은 스크립트의 find -E 나 find -s 같은 맥 전용 옵션이 거꾸로 unknown predicate 로 실패한다. 실제로 gfind -E d 와 gfind d -s 는 unknown predicate 와 종료 코드 1을 냈다. 실제 gnubin 은 쓰지 않았다.

시험하지 못한 것

리눅스에서 도는 GNU find 와 다른 findutils 버전, BusyBox find, fd 같은 대체 도구, 다른 macOS 버전, zsh 에서의 set -o pipefail 동작, 줄바꿈이 든 파일 이름, 읽기 권한이 없는 폴더, 서식 글자 중 위 표에 없는 것(%k, %n, %i, 너비·정밀도 플래그)은 확인하지 않았다. gfind 4.11.0 이 GNU 쪽을 대신했다.

세 줄 요약

• 이 맥의 find 에는 -printf 가 없어 find: -printf: unknown primary or operator 와 종료 코드 1이 나오므로 서식 글자를 -print, stat -f, 경로 가공으로 하나씩 바꾼다.
• 그 실패는 파이프 끝에서는 종료 코드 0, 변수에서는 빈 문자열, 출력 줄 수를 세면 0으로 가려지고, 특수 비트가 있는 권한은 stat -f %p 의 끝 4자리를 8진수로 바꿔야 GNU 의 %m 과 같다.
• -printf 를 아는 find 인지 먼저 시험하고 -로 시작하는 폴더 이름에 ./ 를 붙인 함수로 감싸 두 find 에서 같은 줄이 나오는지 비교한다.