macOS에서 head -n -1이 illegal line count 오류를 낼 때: 오류가 빈 결과로 새는 경우와 마지막 줄만 빼는 법을 직접 시험한 결과When head -n -1 fails with illegal line count on macOS: how the error leaks into an empty result, and how to drop the last lines, as tested
리눅스식 head -n -1 이나 head -n -N 이 든 스크립트를 macOS 에서 돌려 오류를 만났거나, 오류 없이 결과가 비어 당황한 독자가 원인을 가려내고 마지막 줄 N개를 빼는 방법을 맥에서 얻게 돕는다.
이 맥(26.6.2)의 head 는 음수 줄 수(-1·-2)를 거부해 illegal line count 와 종료 코드 1을 내고, head -n 0 도 거부한다. 2>/dev/null 로 오류를 숨기면 결과가 빈 파일이 되고, 뒤에 wc 같은 명령이 붙으면 pipefail 없이는 종료 코드도 0이 되어 줄 수가 0으로 새며, sed '$d' 와 awk 는 마지막 줄 하나를, awk 링 버퍼 함수는 N=1·2·5 를 시험한 열 가지 입력에서 GNU head 와 같은 바이트로 뺐다.
스크립트에서 head -n 에 음수를 주는 곳을 찾아 값을 어디에 쓰는지 확인하고, 마지막 한 줄이면 sed '$d' 로, N줄이면 아래 awk 함수(N=1·2·5 만 시험)로 바꾼 뒤 맥에서 ghead 와 같은 결과가 나오는지 비교한다.
목차
한 줄 요약: 이 맥(26.6.2)의 head 는 음수 줄 수를 거부하고 종료 코드 1을 내므로, 마지막 줄 하나는 sed ‘$d’ 로, N줄(1·2·5 시험)은 awk 함수로 빼고, 오류를 숨기는 파이프에서는 결과가 비는지 따로 확인해야 한다.
리눅스에서 쓰던 head -n -1 파일(마지막 줄만 빼고 출력)을 맥 터미널에 붙였더니 아래처럼 실패한다. 이 글은 무엇으로 바꾸면 되는지, 그리고 오류를 지나친 스크립트에서 결과가 어떻게 조용히 비는지를 이 맥에서 직접 돌려 보인다. tail -n +K 로 바꿔도 되느냐는 물음에는, 숫자만 바꾸면 같은 줄이 나오지 않는다는 것이 답이다.
head: illegal line count -- -1같은 사정은 공개 기록에도 있다. 2014년 Tarsnap 사용자 메일링 리스트에는 FreeBSD 9.2 에서 백업 스크립트가 head: illegal line count -- -31 을 낸다는 글이 올라왔고, Tarsnap 개발자는 head 의 음수 줄 수 옵션이 이식되지 않는다고 답했다. 확인한 환경은 macOS 26.6.2 arm64 의 /usr/bin/head(BSD 계열), Homebrew 의 GNU coreutils 9.11 에 든 ghead, bash 3.2.57, macOS 기본 awk(버전 20200816)다. 시험 스크립트는 LC_ALL=C 로 두 번씩 돌려 같은 출력을 확인했다.
용어 몇 개. head 는 입력의 앞쪽 줄을 보여 주는 명령이다. 종료 코드는 명령이 끝나며 남기는 숫자로 0이 정상이다. 파이프(|)는 앞 명령의 출력을 뒤 명령의 입력으로 넘기는 연결이고, 2>/dev/null 은 오류 메시지를 버리는 표기다. GNU 는 리눅스 대부분이 쓰는 명령 모음이고, 맥의 명령은 BSD 계열이라 옵션이 다르다.
이 맥의 head 는 음수 줄 수를 받지 않는다
세 줄(a b c)짜리 파일로 시험했다. head -n -1 과 head -n -2, head --lines=-1 은 모두 head: illegal line count -- 숫자 로 끝났고 종료 코드는 1이었다. 바이트 수를 음수로 준 head -c -1 도 head: illegal byte count -- -1 과 종료 코드 1이었다. head -n 0 도 같은 오류와 종료 코드 1이다. GNU ghead -n 0 은 아무것도 출력하지 않고 종료 코드 0으로 끝났다. 없는 파일에 head -n -1 을 줘도 파일이 없다는 말 없이 같은 줄 수 오류가 먼저 나왔다. 이 맥의 man head 는 사용법을 head [-n count | -c bytes] [file ...] 로만 적고 음수는 언급하지 않는다. GNU 쪽 설명서는 -n [-]num 에서 - 를 붙이면 “마지막 num 줄만 빼고 출력한다”고 적는다. 즉 이 맥의 man head 에는 음수 형태가 없고, 내가 읽은 GNU 설명서와 시험한 ghead 에는 있다(다른 구현이나 POSIX 명세는 확인하지 못했다).
오류가 빈 결과로 새는 자리
오류 메시지를 2>/dev/null 로 버린 스크립트가 어떻게 되는지 시험했다. 결과 파일에 저장하는 형태에서는 파일이 0줄 0바이트로 비었다.
# bash 3.2 기준(zsh 에서는 PIPESTATUS 가 아니라 소문자 pipestatus)
cat abc.txt | head -n -1 2>/dev/null > out.txt # out.txt 는 0바이트
cat abc.txt | head -n -1 2>/dev/null >/dev/null; echo "${PIPESTATUS[*]}" # 0 1
n=$(head -n -1 abc.txt 2>/dev/null | wc -l | tr -d ' ') # n=[0]head 가 파이프 맨 끝이면 파이프 전체의 종료 코드가 head 의 1이라 호출하는 쪽이 알아챌 수 있다. 하지만 뒤에 wc -l 이 붙으면 PIPESTATUS 는 1 0 이고 파이프 전체의 종료 코드는 wc 의 0이 되며(pipefail 이 없을 때), 위 마지막 줄처럼 남은 줄 수가 오류 없이 0으로 나왔다. set -o pipefail 을 켜고 같은 head | wc 를 돌리면 종료 코드 1이 올라왔다. 기대는 2였고 [ "$n" -eq 2 ] 검사는 실패했다. 그러니 이 값을 그대로 믿고 쓰는 스크립트는 데이터가 사라진 채 계속 도는 셈이다.
set -e 아래에서 body=$(head -n -1 파일 2>/dev/null) 처럼 대입으로 받으면 스크립트가 종료 코드 1로 그 자리에서 멈췄고, set -eu -o pipefail 에 cat 파일 | head -n -1 을 넣었을 때도 1로 멈췄다. 같은 set -e 아래에서도 n=$(head -n -1 파일 2>/dev/null | wc -l | tr -d ' ') 처럼 head 뒤에 wc 가 붙은 대입은 멈추지 않고 n=[0] 으로 통과했다. 즉 head 가 대입의 끝이면 오류가 잡히고, 파이프 중간이면 pipefail 을 켜기 전에는 조용하다.
마지막 줄만 빼는 방법
마지막 한 줄만 빼려면 sed '$d' 가 가장 짧다. $ 는 마지막 줄을, d 는 지운다는 뜻이다. awk 로는 한 줄을 늦춰 찍는다(awk 'NR>1{print prev} {prev=$0}'). 마지막 N줄을 빼려면 N+1 칸짜리 링 버퍼(돌려 쓰는 저장 공간)로 줄을 N개 뒤로 미룬다.
dropn() { # 사용: dropn 파일 N
awk -v n="$2" 'n<0{n=0} {buf[NR%(n+1)]=$0} NR>n{print buf[(NR-n)%(n+1)]}' "$1"
}
dropn_stdin() { # 사용: seq 1 7 | dropn_stdin N (파이프로 받는 형태, 시험한 코드)
awk -v n="$1" 'n<0{n=0} {buf[NR%(n+1)]=$0} NR>n{print buf[(NR-n)%(n+1)]}'
}열 가지 입력(빈 파일, 한 줄, 개행 없는 한 줄, 두 줄, 개행 없는 세 줄, 세 줄, 마지막이 빈 줄, CRLF 줄바꿈, 한글, 1000줄)에 N 을 1·2·5 로 주고 ghead -n -N 과 바이트 단위(cmp)로 비교했다. sed '$d' 와 awk 한 줄은 N=1 열 가지 모두, dropn 은 N=1·2·5 서른 가지 모두 같았다. 개행 없는 마지막 줄(a\nb\nc)은 ghead·sed '$d'·awk 한 줄이 od 로 찍은 4바이트 a\nb\n 으로 같았고, dropn 은 위 cmp 비교로 같음을 확인했다. dropn 을 파이프로 받는 형태(seq 1 7 | awk ...)도 N=1·2·5 에서 ghead 와 같았다. 반면 “줄 수를 세고 head -n 숫자 로 자르기”(wc -l 로 전체를 세고 N 을 빼서 head 에 준다)는 개행 없는 세 줄 입력에서 N=1·2 일 때 ghead 와 달랐다. wc -l 은 개행 문자만 세므로 마지막 줄에 개행이 없으면 한 줄을 덜 세기 때문이다. 이 방법은 파이프로 쓸 수 없는 것도 단점이다.
마지막 바이트 하나를 빼는 head -c -1 은 시험한 대체법이 없다. 끝의 개행 하나를 지우는 perl -pe 'chomp if eof' 가 abc\n 한 입력에서 ghead -c -1 과 같은 abc 를 냈을 뿐이고, 개행 없는 입력에서는 다르게 동작할 수 있으며 시험하지 않았다.
tail -n +32 로 숫자만 바꾸면 같은 줄이 나오지 않는다
앞의 Tarsnap 글에서 개발자는 head -n -X 를 sort -rn | tail +$(X+1) 로 바꾸자고 했다. 값으로 거꾸로 정렬(sort -rn)한 뒤 뒤쪽을 자르는 방식이다. 다른 참가자는 이를 풀어 쓰며 head -n -31 과 tail -n +32 를 “functionally identical” 이라 불렀고, 개발자는 한 숫자 차이(off-by-one)만 조정하면 된다고 답했다. 이 글의 시험은 그 스크립트의 입력을 열어 보지 않았으므로 공개 기록이 틀렸다는 증명이 아니다. 시험한 것은 tail -n +32 만 head -n -31 자리에 넣었을 때다. 이미 오름차순인 1100 줄에서 69 의 69줄이고, 맥의 ghead -n -31 은 1tail -n +32 는 32~100 의 69줄이다. 줄 수는 같지만 앞쪽을 남기느냐(head) 뒤쪽을 남기느냐(tail)가 반대라서 내용은 다르다. 40줄과 62줄에서도 줄 수만 같고 내용은 달랐다.
sort -rn | tail -n +32 는 같은 오름차순 입력에서 69~1 의 69줄을 냈고, 다시 오름차순으로 정렬하면 ghead -n -31 과 같았다. 그러나 이것은 입력이 이미 정렬된 정수라서 맞아떨어진 것이다. sort -rn 은 순서를 뒤집는 것이 아니라 값으로 정렬한다. 3, 1, 2 세 줄에서 ghead -n -1 은 3,1 을 냈는데 sort -rn | tail -n +2 는 2,1 을 내서 다른 줄이 지워졌다. 줄 순서를 정말 뒤집는 맥의 tail -r 을 쓴 tail -r 파일 | tail -n +(N+1) | tail -r 은 같은 3, 1, 2 에서 3,1 로 ghead 와 같았고, 문자 줄 네 개에 N=1·2·3 을 줘도 같았다. 다만 끝 줄에 개행이 없는 a\nb\nc 에서는 ghead -n -1 이 a\nb\n 을 냈는데 이 tail -r 방식은 a\n 만 냈다. 그러므로 tail 로 바꿀 때는 입력의 정렬 상태와 끝 개행을 확인해야 하고, “마지막 줄을 뺀다”는 뜻을 그대로 옮기는 sed '$d' 나 dropn 이 이 점에서 안전하다. 맥의 tail -n +3 은 3번째 줄부터 끝까지를 내서(3 4 5) 앞쪽 줄을 빼는 데는 그대로 쓸 수 있다.
시험하지 못한 것
리눅스에서 실제로 도는 GNU head 는 쓰지 못했고 이 맥의 ghead 9.11 이 대신한다. zsh, 다른 macOS 버전, 아주 큰 파일에서의 속도와 메모리(dropn 은 N+1 줄을 메모리에 둔다), NUL 바이트가 든 입력, 여러 파일을 한꺼번에 주는 경우의 ==> 파일 <== 머리글, -q·-v 옵션, GNU 의 K·M 같은 크기 접미사는 확인하지 않았다. head -n -0 은 시험 표에 넣지 않았고, 따로 돌려 보니 개행 없는 a\nb 입력에서 dropn 에 N=0 을 주면 끝에 개행을 붙여 4바이트를 내고 ghead -n -0 은 3바이트를 내서 달랐다. 그래서 dropn 은 N 이 1 이상일 때만 쓴다. 공개 기록은 메일링 리스트 두 글의 본문만 읽었고 그 스크립트 자체는 열어 보지 않았다. 이 글의 결과는 이 맥 한 대에서 얻은 것이다.
세 줄 요약
- 이 맥(26.6.2)의 head 는
-n -1·-c -1같은 음수와-n 0까지 illegal line count(또는 byte count)와 종료 코드 1로 거부하고, GNUghead는 이를 받는다. 2>/dev/null로 오류를 숨기면 결과 파일이 0바이트가 되고, head 뒤에wc -l이 붙으면pipefail없이는 종료 코드 0으로 줄 수가 0이 되어 조용히 틀린다.- 마지막 한 줄은
sed '$d', N줄(1·2·5 시험)은 awk 링 버퍼 함수로 열 가지 입력에서ghead와 바이트까지 같았고,tail -n +32는 숫자만 바꾸면 같은 줄을 내지 못한다.
To help a reader who ran a script with Linux-style head -n -1 or head -n -N on macOS and hit an error, or got an empty result with no error, find the cause and get a way to drop the last N lines on a Mac.
The head on this Mac (26.6.2) rejects negative line counts (-1 and -2) with illegal line count and exit code 1, and it rejects head -n 0 as well. Hiding the error with 2>/dev/null leaves the result file empty, and when a command like wc follows, the exit code is 0 without pipefail and the line count leaks out as 0. sed '$d' for the last line and an awk ring buffer function (tested with N=1, 2 and 5) matched GNU head byte for byte on ten inputs.
Find the places in your scripts where head -n gets a negative number and check what the value is used for, replace it with sed '$d' for the last line or the awk function below for N lines (tested only with N=1, 2 and 5), then compare on a Mac that the result matches ghead.
Contents
One-line summary: The head on this Mac (26.6.2) rejects negative line counts with exit code 1, so drop the last line with sed ‘$d’ and the last N lines (tested with 1, 2 and 5) with an awk function, and check separately whether the result is empty wherever a pipe hides the error.
You ran head -n -1 file (print everything except the last line), which you used on Linux, in a Mac terminal, and it fails like this. This article shows on this Mac what to replace it with, and how a script that skips past the error ends up with a silently empty result. As for whether you can just switch to tail -n +K, the answer is that changing only the number does not give the same lines (see below).
head: illegal line count -- -1The same situation shows up in public records. A 2014 post on the Tarsnap users mailing list reported a backup script printing head: illegal line count -- -31 on FreeBSD 9.2, and the Tarsnap developer answered that head’s negative line count option is not portable. The environment I checked is macOS 26.6.2 arm64 with /usr/bin/head (BSD family), ghead from Homebrew’s GNU coreutils 9.11, bash 3.2.57, and the default macOS awk (version 20200816). I ran each test script twice with LC_ALL=C and got the same output both times.
A few terms. head is a command that shows the first lines of its input. The exit code is the number a command leaves when it ends, and 0 means success. A pipe (|) connects one command’s output to the next command’s input, and 2>/dev/null throws error messages away. GNU is the command set most Linux systems use, while the Mac’s commands are BSD family and have different options.
The head on this Mac does not accept negative line counts
I tested with a three-line file (a b c). head -n -1, head -n -2 and head --lines=-1 all ended with head: illegal line count -- number and exit code 1. head -c -1, which gives a negative byte count, printed head: illegal byte count -- -1 with exit code 1. head -n 0 also gets the same error and exit code 1, while GNU ghead -n 0 prints nothing and exits with 0. Giving head -n -1 a file that does not exist also produced the same line count error first, with no word about the missing file. The man page of head on this Mac lists the usage only as head [-n count | -c bytes] [file ...] and says nothing about negatives. The GNU manual says that with -n [-]num, a leading - prints all but the last num lines. So the man page of head on this Mac has no negative form, while the GNU manual I read and the ghead I tested do (I did not check other implementations or the POSIX specification).
Where the error leaks into an empty result
I tested what happens to a script that throws the error message away with 2>/dev/null. In the form that saves to a result file, the file ended up with 0 lines and 0 bytes.
# bash 3.2 (in zsh it is lowercase pipestatus, not PIPESTATUS)
cat abc.txt | head -n -1 2>/dev/null > out.txt # out.txt is 0 bytes
cat abc.txt | head -n -1 2>/dev/null >/dev/null; echo "${PIPESTATUS[*]}" # 0 1
n=$(head -n -1 abc.txt 2>/dev/null | wc -l | tr -d ' ') # n=[0]When head is at the end of the pipe, the exit code of the whole pipe is head’s 1, so the caller can notice. But once wc -l is attached after it, PIPESTATUS is 1 0 and the exit code of the whole pipe becomes wc’s 0 (when pipefail is off), and as in the last line above, the remaining line count came out as 0 with no error. Turning on set -o pipefail and running the same head | wc gave exit code 1. The expected value was 2, and the check [ "$n" -eq 2 ] failed. A script that trusts this value just keeps running after the data has vanished.
Under set -e, receiving the output by assignment, as in body=$(head -n -1 file 2>/dev/null), stopped the script right there with exit code 1, and cat file | head -n -1 under set -eu -o pipefail also stopped with 1. Under the same set -e, however, an assignment where wc follows head, such as n=$(head -n -1 file 2>/dev/null | wc -l | tr -d ' '), did not stop and passed with n=[0]. So the error is caught when head ends the assignment, and it is silent when head is in the middle of a pipe until you turn on pipefail.
How to drop just the last lines
To drop only the last line, sed '$d' is the shortest. $ means the last line and d means delete. With awk you print one line late (awk 'NR>1{print prev} {prev=$0}'). To drop the last N lines, delay lines by N using a ring buffer (a storage space that is reused in a circle) with N+1 slots.
dropn() { # usage: dropn file N
awk -v n="$2" 'n<0{n=0} {buf[NR%(n+1)]=$0} NR>n{print buf[(NR-n)%(n+1)]}' "$1"
}
dropn_stdin() { # usage: seq 1 7 | dropn_stdin N (the pipe form, the code I tested)
awk -v n="$1" 'n<0{n=0} {buf[NR%(n+1)]=$0} NR>n{print buf[(NR-n)%(n+1)]}'
}I used ten inputs (empty file, one line, one line with no trailing newline, two lines, three lines with no trailing newline, three lines, a blank last line, CRLF line endings, Korean text, and 1000 lines) with N set to 1, 2 and 5, and compared against ghead -n -N byte by byte (cmp). sed '$d' and the one-line awk matched for all ten inputs with N=1, and dropn matched for all thirty combinations of N=1, 2 and 5. Three lines with no trailing newline (a\nb\nc) came out as the same 4 bytes, a\nb\n, printed with od for ghead, sed '$d' and the one-line awk, and dropn was confirmed equal by the cmp comparison above. The form where dropn takes a pipe (seq 1 7 | awk ...) also matched ghead for N=1, 2 and 5. On the other hand, “count the lines, then cut with head -n number” (count everything with wc -l, subtract N, and pass that to head) differed from ghead on the three-line input with no trailing newline when N was 1 or 2. wc -l counts only newline characters, so it counts one line fewer when the last line has no newline. That method also cannot be used with a pipe.
head -c -1, which drops the last byte, has no alternative I tested. Only perl -pe 'chomp if eof', which removes one trailing newline, gave abc, the same as ghead -c -1, on the single input abc\n, and it may behave differently on input with no trailing newline, which I did not test.
Changing only the number to tail -n +32 does not give the same lines
In the Tarsnap post above, the developer proposed replacing head -n -X with sort -rn | tail +$(X+1), which sorts values in reverse and cuts from the end. Another participant restated this by calling head -n -31 and tail -n +32 “functionally identical,” and the developer replied that only the number off by one needs adjusting. My test did not open that script’s input, so it does not prove the public record wrong. What I tested is dropping tail -n +32 alone into the place of head -n -31. On 100 lines that are already in ascending order, ghead -n -31 gives 69 lines, 1 to 69, while this Mac’s tail -n +32 gives 69 lines, 32 to 100. The counts are the same, but one keeps the front (head) and the other keeps the back (tail), so the contents differ. With 40 and 62 lines too, only the counts matched and the contents differed.
sort -rn | tail -n +32 gave 69 lines, 69 down to 1, on the same ascending input, and sorting that back in ascending order matched ghead -n -31. But that worked only because the input was already sorted integers. sort -rn does not reverse the order; it sorts by value. On the three lines 3, 1, 2, ghead -n -1 gave 3,1 while sort -rn | tail -n +2 gave 2,1, so a different line was removed. tail -r file | tail -n +(N+1) | tail -r, which uses this Mac’s tail -r to truly reverse the line order, gave 3,1 on the same 3, 1, 2, matching ghead, and it also matched with four text lines and N=1, 2 and 3. However, on a\nb\nc with no trailing newline, ghead -n -1 gave a\nb\n while this tail -r method gave only a\n. So when you switch to tail, you have to check the input’s sort state and trailing newline, and sed '$d' or dropn, which carry the meaning “drop the last lines” directly, are safer on this point. On this Mac tail -n +3 prints from line 3 to the end (3 4 5), so it is fine for dropping lines at the front.
What I did not test
I could not use the GNU head that actually runs on Linux, and ghead 9.11 on this Mac stands in for it. I did not check zsh, other macOS versions, speed and memory on very large files (dropn keeps N+1 lines in memory), input containing NUL bytes, the ==> file <== headers when several files are given, the -q and -v options, or GNU size suffixes such as K and M. I left head -n -0 out of the test table, and when I ran it separately, on the input a\nb with no trailing newline, dropn with N=0 added a trailing newline and gave 4 bytes while ghead -n -0 gave 3 bytes, so they differed. That is why dropn should be used only when N is 1 or more. For the public records I read only the bodies of the two mailing list posts and did not open the script itself. The results in this article come from this one Mac.
Three-line summary
- The head on this Mac (26.6.2) rejects negatives such as
-n -1and-c -1, and even-n 0, with illegal line count (or byte count) and exit code 1, while GNUgheadaccepts them. - Hiding the error with
2>/dev/nullleaves the result file at 0 bytes, and whenwc -lfollows head the exit code is 0 withoutpipefailand the line count silently becomes 0. sed '$d'for the last line and the awk ring buffer function for N lines (tested with 1, 2 and 5) matchedgheadbyte for byte on ten inputs, while changing only the number totail -n +32does not give the same lines.