macOS에서 mv -t가 illegal option 오류를 낼 때: 여러 파일을 한 폴더로 옮기는 맥의 방법을 GNU mv와 나란히 시험한 결과When mv -t fails with illegal option on macOS: how to move many files into one folder on a Mac, tested side by side with GNU mv
리눅스식 mv -t 줄을 맥에서 돌려 오류를 만났거나, 오류를 숨긴 스크립트가 파일을 안 옮기고 지나간 독자가 맥에서 여러 파일을 한 폴더로 안전하게 옮기는 방법을 고르게 돕는다.
이 맥(26.6.2)의 mv 는 -t·-T·-u·-b 네 개와 긴 옵션 다섯 개, 모두 아홉 가지를 종료 코드 64로 거부하고 아무것도 옮기지 않는다. 폴더를 마지막에 두는 형태로 바꾸면 되지만 -t 가 해 주던 폴더 점검이 사라지므로, 폴더가 없을 때 파일 이름이 바뀌는 것을 막는 점검과 이름 겹침 때 조용히 덮어쓰는 것을 아는 것이 필요하다.
스크립트의 mv -t 줄을 아래 find -exec sh -c 한 줄이나 mv_t 함수로 바꾸고, mv 오류를 2>/dev/null 로 버리거나 || true 로 덮는 곳이 없는지, 서로 다른 폴더의 같은 이름 파일이 없는지 확인하라.
목차
한 줄 요약: 맥의 mv 는 -t 를 종료 코드 64로 거부하고 아무것도 옮기지 않으므로, 폴더를 마지막 인자로 둔 find -exec sh -c 한 줄이나 아래 mv_t 함수로 바꾸고 폴더 점검을 직접 붙인다.
리눅스에서 find . -name '*.log' -exec mv -t archive {} + 로 로그를 한 폴더에 모으던 줄을 맥 터미널에서 돌리면 파일은 그대로이고 오류 문구만 남는다. 이 글은 맥의 mv 가 무엇을 거부하는지, 오류를 버린 스크립트가 어떤 상태로 남는지, 맥에서 같은 일을 하는 방법이 GNU mv -t 와 무엇이 같고 무엇이 다른지를 이 맥에서 직접 돌려 보인다.
mv: illegal option -- t
usage: mv [-f | -i | -n] [-hv] source target
mv [-f | -i | -n] [-v] source ... directory확인한 환경은 macOS 26.6.2 arm64 의 /bin/mv 와 bash 3.2.57 이고 날짜는 2026-11-02 이다. 시험은 모두 이 맥의 /bin/mv 로 돌렸다. /bin/mv 를 경로째 부른 시험에서는 오류 접두어가 /bin/mv: 로 찍혔고, 그냥 mv 로 치면 위처럼 mv: 로 시작한다. 비교 기준인 GNU mv 는 Homebrew 의 coreutils 9.11 이 gmv 라는 이름으로 이 맥에 있어 직접 돌렸다. 시험 스크립트 세 개를 두 번씩 돌렸고 두 번째 출력은 첫 번째와 글자까지 같았다. 같은 usage 문구는 2018년 FreeBSD 에서 mv -fT 를 쓰다 막힌 shipit 이슈에도 그대로 나온다. 맥의 mv 도 BSD 계열이라 같은 문구를 낸다.
용어 몇 개. 종료 코드는 명령이 끝나며 남기는 숫자로 0이 정상이다. GNU 는 많은 리눅스 배포판이 쓰는 명령 모음이고 맥의 명령은 BSD 계열이라 이름이 같아도 옵션이 다르다. -t 는 “이 폴더로 옮겨라”를 옵션으로 먼저 알려 주는 GNU 의 방식이고, 맥은 폴더를 마지막 인자로만 받는다.
맥의 mv 가 거부하는 옵션과 받는 옵션
src/a.log 하나를 dest 로 옮기는 줄에 옵션만 바꿔 가며 종료 코드와 오류 첫 줄, 파일이 옮겨졌는지를 쟀다. 맥은 -t, -T, -u, -b 와 긴 옵션 --target-directory=, --no-target-directory, --update, --backup, --verbose 아홉 가지를 모두 종료 코드 64로 거부했고 파일은 하나도 옮겨지지 않았다. 짧은 옵션은 illegal option -- t 처럼 글자를 보여 주지만 긴 옵션은 어느 옵션인지 알려 주지 않고 illegal option -- - 만 보여 준다. 반대로 -v 와 -n 은 맥도 받아서 종료 코드 0으로 옮겼다. gmv 는 열두 줄 전부 종료 코드 0이었다.
맥의 man mv 는 두 번째 형태를 mv [-f | -i | -n] [-v] source ... directory 로 적고, 마지막 인자가 이미 있는 폴더면 모든 원본을 그 폴더 안으로 옮긴다고 설명한다. GNU 쪽 설명서(저장한 페이지는 coreutils 9.12 판이고 비교에 쓴 gmv 는 9.11 이다)는 mv [option]... -t directory source... 를 따로 적고 -n 에 대해서는 “다른 플랫폼과 종료 코드가 달라 더 이상 권하지 않는다(deprecated)“고 쓴다.
오류를 버리면 파일은 그대로이고 종료 코드만 남는다
이 오류가 번거로워 2>/dev/null 을 붙인 스크립트가 어떻게 되는지 쟀다. src 에 .log 파일 세 개를 두고 맥의 mv -t dest 를 네 모양으로 돌렸다. 어느 쪽도 파일은 dest 로 가지 않고 src 에 세 개가 그대로 남았다. 표의 마지막 줄은 같은 줄을 gmv 로 돌린 대조다.
| 줄 | 종료 상태 |
|---|---|
find src -name '*.log' -exec mv -t dest {} + 2>/dev/null |
find 가 1 |
find src -name '*.log' -exec mv -t dest {} \; 2>/dev/null |
find 가 0 |
find src -name '*.log' | xargs mv -t dest 2>/dev/null |
find 0, xargs 1 |
mv -t dest src/*.log 2>/dev/null || true |
0 |
같은 줄을 gmv 로 (-exec gmv -t dest {} +) |
find 0, 세 파일 이동 |
\; 형태는 안쪽 명령이 전부 실패해도 find 가 0으로 끝났다. 이 때문에 “find 가 0이니 됐겠지”라는 판단이 위험하다. set -e 를 켠 스크립트에서 xargs … 2>/dev/null 줄은 다음 줄의 echo 없이 종료 코드 1로 멈췄고, mv -t dest src/*.log 2>/dev/null 은 64로 멈췄으며, || true 로 덮으면 echo 까지 가서 종료 코드 0으로 끝났다. 오류를 버린 xargs 줄 다음에 ls dest | wc -l 을 하면 0, ls src | wc -l 은 3이었다. 옮긴 뒤 폴더를 비웠다고 믿고 src 를 지우는 정리 스크립트라면 이 자리가 사고 지점이다.
맥에서 같은 일을 하는 네 가지 방법
아래 입력으로 gmv -t 와 나란히 돌렸다. src 아래에 a.log, sub/a.log(내용이 다름), sub/b.log, sub/deep/c.log, 이름에 공백이 있는 sp ace.log, 대시로 시작하는 -dash.log, 한글.log, 이름 가운데 줄바꿈이 있는 파일, 그리고 옮기지 않을 keep.txt 를 두고 .log 를 전부 dest 로 모으는 일이다.
# A. 폴더를 마지막 인자로 넘기는 find -exec + (배치 실행)
find src -name '*.log' -exec sh -c 'd=$1; shift; mv -- "$@" "$d"/' _ dest {} +
# B. 파일마다 한 번씩
find src -name '*.log' -exec mv -- {} dest/ \;
# C. xargs -I (NUL 구분)
find src -name '*.log' -print0 | xargs -0 -I{} mv -- {} dest/
# D. BSD xargs 의 -J (NUL 구분, 여러 파일을 한 번에)
find src -name '*.log' -print0 | xargs -0 -J % mv -- % dest/네 방법 모두 종료 코드 0이었고 .log 여덟 개가 모두 옮겨져 dest 에 일곱 개가 있었으며(a.log 두 개가 한 이름으로 겹쳤다) src 에는 keep.txt 만 남았다. 공백·대시·한글·줄바꿈이 든 이름도 모두 그대로 옮겨졌다. 같은 줄에서 -print0/-0 을 빼고 find … | xargs -I{} mv -- {} dest/ 로 하면 줄바꿈이 든 이름이 두 조각으로 갈려 rename src/new to dest/new: No such file or directory 가 나오고 종료 코드 1, 그 파일은 src 에 남았다. 공백이 든 이름은 -I{} 가 줄 단위로 읽어서 옮겨졌다. 사용자가 이름에 줄바꿈을 넣을 일은 드물지만 파일 이름을 받는 도구라면 -print0 형태로 쓰는 편이 맞다.
이름 겹침에서 gmv -t 와 다른 점이 있다. a.log 가 두 곳에 있는 이 입력에서 gmv -t 는 will not overwrite just-created 'dest/a.log' with 'src/sub/a.log' 를 내고 종료 코드 1로 끝났으며 sub/a.log 를 src 에 남기고 dest/a.log 에는 첫 번째 내용(top-a)이 있었다. 네 가지 맥 방법은 아무 말 없이 종료 코드 0으로 끝났고 dest/a.log 는 sub-a 였다. 먼저 옮긴 top-a 가 덮여 사라진 것이다. 이 실행에서는 find 가 src/a.log 를 먼저 내놓아 sub/a.log 가 이겼는데, 어느 쪽이 남는지는 find 가 내놓는 순서에 달려 있다.
-n 을 붙이면 맥도 덮어쓰지 않았다. a.log 두 개만 대상으로 mv -n 을 돌리면 종료 코드 0, dest/a.log 는 top-a, sub/a.log 는 src 에 남았다. 어느 파일이 건너뛰어졌는지 알려 주는 문구는 없다. gmv -n 도 같은 결과에 종료 코드 0이었다. 그래서 이름이 겹칠 수 있는 입력이면 -n 을 붙이거나, 옮기기 전에 같은 이름이 있는지 find … -exec basename {} \; | sort | uniq -d 같은 식으로 먼저 센다.
-t 가 해 주던 폴더 점검이 사라진다
폴더가 없을 때가 가장 놀라웠다. gmv -t nodir src/a.log 는 target directory 'nodir': No such file or directory 를 내고 종료 코드 1로 끝났고 a.log 는 그대로였다. 맥에서 폴더를 마지막에 두는 형태로 바꾼 mv -- src/a.log nodir 는 nodir 가 없으면 종료 코드 0으로 a.log 의 이름을 nodir 로 바꿔 버렸다. 시험이 끝난 뒤 nodir 는 폴더가 아니라 top-a 가 든 일반 파일이었다. 파일이 하나일 때는 “마지막이 폴더면 안으로, 아니면 이름 바꾸기”라는 첫 번째 형태로 읽히기 때문이다. 원본이 둘 이상이면 mv: nodir is not a directory 로 종료 코드 1이었다.
끝에 슬래시를 붙여 nodir/ 로 쓰면 하나일 때도 mv: rename src/a.log to nodir/: No such file or directory 로 종료 코드 1이었고 파일은 그대로였다. 대상이 일반 파일일 때 원본 둘로 쟀더니 notdir/ 은 mv: notdir/ is not a directory, 종료 코드 1이었다. 그래서 위 A~D 는 모두 dest/ 처럼 슬래시를 붙여 썼고, 폴더가 실제로 있는지 직접 확인하는 점검까지 넣으면 아래처럼 된다. 폴더가 없을 때 이 점검은 대상 폴더가 아님: nodir 를 내고 find 가 1로 끝났으며 src 에 .log 여덟 개가 그대로 남았다. 폴더가 있고 이름 겹침이 없는 입력에서는 find 가 0이었고 .log 일곱 개가 모두 dest 로 갔다.
find src -name '*.log' -exec sh -c '[ -d "$1" ] || { echo "대상 폴더가 아님: $1" >&2; exit 1; }; d=$1; shift; mv -- "$@" "$d"/' _ dest {} +인자가 아주 많을 때와 쓸 만한 함수
폴더 하나에 파일이 2만 개 있을 때를 쟀다. 이름 하나가 약 70바이트라 인자 전체가 이 맥의 한도(getconf ARG_MAX 가 1048576)를 넘는다. mv_t dest src/*.log(안에서 mv -- src/*.log dest/ 와 같은 확장이 일어난다)도 gmv -t dest src/*.log 도 Argument list too long 으로 종료 코드 126이었고 dest 는 0개였다. find -exec sh -c … {} + 는 인자를 나눠서 실행해 종료 코드 0에 dest 2만 개, xargs -0 -J % 도 2만 개였다. 파일이 많을 수 있는 입력은 * 를 그대로 쓰지 말고 find 로 넘긴다.
적은 수의 파일을 명령줄에서 직접 옮길 때 쓰라고 아래 함수도 시험했다. 인자가 없으면 64, 폴더가 아니면 1을 내고 아무것도 옮기지 않는다.
mv_t() { # mv_t 대상폴더 파일... (GNU mv -t 대신)
local d=$1
shift
if [ $# -eq 0 ]; then echo "mv_t: 옮길 파일이 없다" >&2; return 64; fi
if [ ! -d "$d" ]; then echo "mv_t: 폴더가 아니다: $d" >&2; return 1; fi
mv -- "$@" "$d"/
}mv_t dest src/a.txt "src/b c.txt" src/-d.txt 에 줄바꿈이 든 이름 하나를 더해 공백·대시 시작·줄바꿈 이름을 포함한 네 개를 한 번에 옮기면 종료 코드 0에 dest 네 개였다. 폴더가 없을 때(nodir)와 대상이 일반 파일일 때(notdir)는 종료 코드 1에 원본이 그대로였고 nodir 도 만들어지지 않았다. 없는 원본(zzz.txt)을 주면 mv: rename src/zzz.txt to dest/zzz.txt: No such file or directory 와 종료 코드 1이었다. 이름이 겹치면 이 함수도 덮어썼다. x.txt 가 src 와 dest 에 모두 있을 때 mv_t dest src/x.txt src/y.txt 는 종료 코드 0에 dest/x.txt 가 새 내용(new-x)이 되었다. 마지막 줄만 mv -n -- "$@" "$d"/ 로 바꾼 변형은 종료 코드 0에 dest/x.txt 가 옛 내용(old-x)으로 남고 src/x.txt 도 src 에 남았으며 y.txt 는 옮겨졌다. 건너뛴 파일을 알려 주는 문구는 없으므로, 겹칠 수 있으면 이 변형을 쓰고 겹침을 먼저 센다.
시험하지 못한 것
리눅스에서 GNU mv 를 직접 돌린 대조(이 맥의 gmv 9.11 로 대신함), 다른 macOS 버전과 zsh, 파일 시스템이 다른 곳으로 옮길 때(복사 후 삭제)의 동작, 권한·ACL·확장 속성이 바뀌는지, 폴더를 옮기는 경우, 원본이 둘 이상일 때 끝 슬래시 nodir/, 심볼릭 링크 폴더에 거는 맥의 -h, gmv 설치 절차는 시험하지 않았다. 이름 겹침 때 어느 쪽이 남는지는 find 의 출력 순서에 달려 있어 이 맥의 이 입력 한 가지에서만 쟀다. 공개 기록은 2018년의 mv -T 한 건이고 -t 오류 자체를 다룬 공개 글은 찾지 못했으며 검색량은 확인하지 않았다.
세 줄 요약
- 맥(26.6.2)의 mv 는 -t·-T·-u·-b 네 개와 긴 옵션 다섯 개, 모두 아홉 가지를 종료 코드 64로 거부하고 파일을 하나도 옮기지 않으며, 오류를 버리면 find -exec ; 는 0으로 끝나 성공처럼 보인다.
- find -exec sh -c … {} + 와 xargs -0 -J % 는 공백·대시·한글·줄바꿈 이름까지, mv_t 는 공백·대시·줄바꿈 이름을 옮겼지만 -t 와 달리 이름 겹침 거부가 없고 -d 폴더 점검은 직접 붙인 한 줄과 mv_t 에만 있다.
- 폴더가 없을 때 mv – 파일 nodir 은 종료 코드 0으로 파일 이름을 바꿔 버리므로 끝 슬래시나 -d 점검을 붙이고, 파일이 많으면 * 대신 find 를 써서 인자 한도(126)를 피한다.
To help a reader who ran a Linux-style mv -t line on a Mac and hit an error, or whose script hid the error and went on without moving anything, choose a safe way to move many files into one folder on the Mac.
The mv on this Mac (26.6.2) rejected nine forms (the four short options -t, -T, -u, -b and five long options) with exit code 64 and moved nothing. Putting the folder last fixes the move, but the folder check that -t gave you is gone, so you need your own check against a missing folder turning into a rename, and you need to know that a name collision overwrites silently.
Replace the mv -t lines in your scripts with the find -exec sh -c one-liner or the mv_t function below, and check that nothing discards the mv error with 2>/dev/null or covers it with || true, and that no two folders hold files with the same name.
Contents
One-line summary: The Mac’s mv rejects -t with exit code 64 and moves nothing, so switch to a find -exec sh -c line with the folder as the last argument, or the mv_t function below, and add the folder check yourself.
If you run the Linux line find . -name '*.log' -exec mv -t archive {} + in a Mac terminal to gather logs into one folder, the files stay where they were and only an error message remains. This article shows, from runs on this Mac, what the Mac’s mv rejects, what state a script is left in when the error is discarded, and what is the same and different between the Mac ways of doing the job and GNU mv -t.
mv: illegal option -- t
usage: mv [-f | -i | -n] [-hv] source target
mv [-f | -i | -n] [-v] source ... directoryThe environment was /bin/mv on macOS 26.6.2 arm64 with bash 3.2.57, on 2026-11-02. All tests ran this Mac’s /bin/mv. Where it was called by its full path the error prefix was printed as /bin/mv:, and typing plain mv starts the line with mv: as above. The GNU mv used for comparison is Homebrew’s coreutils 9.11, which is on this Mac under the name gmv. I ran three test scripts twice each, and the second output matched the first character for character. The same usage text appears in a 2018 shipit issue from FreeBSD, where mv -fT was rejected. The Mac’s mv is also BSD-derived and prints the same text.
A few terms. The exit code is the number a command leaves when it ends, and 0 means success. GNU is the command set many Linux distributions use, while the Mac’s commands are BSD-derived, so even with the same name the options differ. -t is GNU’s way of announcing the destination folder up front as an option, whereas the Mac accepts the folder only as the last argument.
Options the Mac’s mv rejects and accepts
I changed only the option on a line that moves one file, src/a.log, into dest, and measured the exit code, the first error line, and whether the file moved. The Mac rejected nine forms with exit code 64 and moved no file: -t, -T, -u, -b and the long options --target-directory=, --no-target-directory, --update, --backup and --verbose. A short option shows its letter, as in illegal option -- t, but a long option does not say which one it was and shows only illegal option -- -. On the other hand -v and -n are accepted by the Mac and moved the file with exit code 0. gmv returned exit code 0 on all twelve lines.
The Mac’s man mv writes the second form as mv [-f | -i | -n] [-v] source ... directory and explains that when the last argument is an existing folder, every source goes into it. The GNU manual (the page I saved is the coreutils 9.12 edition, while the gmv I compared is 9.11) lists mv [option]... -t directory source... as a separate form, and says of -n that it is deprecated because its exit status differs from other platforms.
If you discard the error, the files stay and only an exit code is left
I measured what happens to scripts that added 2>/dev/null because the error was a nuisance. I put three .log files in src and ran the Mac’s mv -t dest in four shapes. In none of them did a file reach dest, and all three stayed in src. The last row of the table is the same line run with gmv as a contrast.
| Line | Exit status |
|---|---|
find src -name '*.log' -exec mv -t dest {} + 2>/dev/null |
find returned 1 |
find src -name '*.log' -exec mv -t dest {} \; 2>/dev/null |
find returned 0 |
find src -name '*.log' | xargs mv -t dest 2>/dev/null |
find 0, xargs 1 |
mv -t dest src/*.log 2>/dev/null || true |
0 |
the same line with gmv (-exec gmv -t dest {} +) |
find 0, three files moved |
The \; form ended with find returning 0 even though every inner command failed. That makes “find returned 0, so it must have worked” a dangerous judgment. In a script with set -e, the xargs … 2>/dev/null line stopped with exit code 1 without running the echo on the next line, mv -t dest src/*.log 2>/dev/null stopped with 64, and covering it with || true reached the echo and ended with exit code 0. After the discarded xargs line, ls dest | wc -l gave 0 and ls src | wc -l gave 3. If a cleanup script believes the folder was emptied and then deletes src, this is where the accident happens.
Four Mac ways of doing the same job
I ran them side by side with gmv -t on the following input. Under src there are a.log, sub/a.log (different contents), sub/b.log, sub/deep/c.log, sp ace.log with a space in the name, -dash.log starting with a dash, 한글.log, a file with a newline in the middle of its name, and keep.txt, which is not to be moved. The job is to gather every .log into dest.
# A. find -exec + (batched), folder passed as the last argument
find src -name '*.log' -exec sh -c 'd=$1; shift; mv -- "$@" "$d"/' _ dest {} +
# B. one run per file
find src -name '*.log' -exec mv -- {} dest/ \;
# C. xargs -I (NUL-separated)
find src -name '*.log' -print0 | xargs -0 -I{} mv -- {} dest/
# D. BSD xargs -J (NUL-separated, many files per run)
find src -name '*.log' -print0 | xargs -0 -J % mv -- % dest/All four ended with exit code 0, all eight .log files were moved so that dest held seven (two a.log files collided on one name), and only keep.txt remained in src. Names containing a space, a dash, Hangul and a newline were all moved intact. If you drop -print0/-0 and run find … | xargs -I{} mv -- {} dest/, the name with a newline splits into two pieces, rename src/new to dest/new: No such file or directory appears, the exit code is 1, and that file stays in src. The name with a space was moved because -I{} reads line by line. People rarely put newlines in file names, but a tool that receives file names is better off using the -print0 form.
There is a difference from gmv -t on name collisions. On this input, where a.log exists in two places, gmv -t printed will not overwrite just-created 'dest/a.log' with 'src/sub/a.log', ended with exit code 1, left sub/a.log in src, and dest/a.log held the first content (top-a). The four Mac ways ended silently with exit code 0 and dest/a.log was sub-a. The top-a that had been moved first was overwritten and lost. In this run find emitted src/a.log first so sub/a.log won, but which one survives depends on the order find emits.
With -n the Mac did not overwrite either. Running mv -n on just the two a.log files gave exit code 0, dest/a.log was top-a, and sub/a.log stayed in src. No message says which file was skipped. gmv -n gave the same result with exit code 0. So when names may collide, add -n, or count duplicate names first with something like find … -exec basename {} \; | sort | uniq -d.
The folder check that -t gave you is gone
The case of a missing folder was the most surprising. gmv -t nodir src/a.log printed target directory 'nodir': No such file or directory and ended with exit code 1, and a.log stayed. On the Mac, mv -- src/a.log nodir, the form with the folder last, ended with exit code 0 and renamed a.log to nodir when nodir did not exist. After the test, nodir was not a folder but an ordinary file containing top-a. With a single source the line is read as the first form, “rename if the last argument is not a folder”. With two or more sources it printed mv: nodir is not a directory and exited with 1.
With a trailing slash, nodir/, even a single source gave mv: rename src/a.log to nodir/: No such file or directory and exit code 1, and the file stayed. When the target was an ordinary file, measured with two sources, notdir/ gave mv: notdir/ is not a directory and exit code 1. That is why A to D above all use a slash as in dest/, and if you also add a check that the folder really exists, it looks like this. With no such folder, in the test script the check printed the Korean-language message 대상 폴더가 아님: nodir (meaning “not a directory”; the code block below uses an English message), find ended with 1, and all eight .log files stayed in src. With the folder present and no name collision, find returned 0 and all seven .log files went to dest.
find src -name '*.log' -exec sh -c '[ -d "$1" ] || { echo "not a directory: $1" >&2; exit 1; }; d=$1; shift; mv -- "$@" "$d"/' _ dest {} +When there are very many arguments, and a usable function
I measured a folder holding 20,000 files. One name is about 70 bytes, so the whole argument list exceeds this Mac’s limit (getconf ARG_MAX gives 1048576). Both mv_t dest src/*.log (which expands to the same thing as mv -- src/*.log dest/ inside) and gmv -t dest src/*.log failed with Argument list too long and exit code 126, and dest held 0 files. find -exec sh -c … {} + splits the arguments across runs and ended with exit code 0 and 20,000 files in dest, and xargs -0 -J % also gave 20,000. When the input may be large, do not use * directly; hand it to find.
For moving a small number of files by hand on the command line, I also tested the function below. With no arguments it returns 64, and if the target is not a folder it returns 1 and moves nothing.
mv_t() { # mv_t destination-folder files... (instead of GNU mv -t)
local d=$1
shift
if [ $# -eq 0 ]; then echo "mv_t: no files to move" >&2; return 64; fi
if [ ! -d "$d" ]; then echo "mv_t: not a directory: $d" >&2; return 1; fi
mv -- "$@" "$d"/
}Moving four files at once with mv_t dest src/a.txt "src/b c.txt" src/-d.txt plus one name containing a newline gave exit code 0 and four files in dest: a name with a space, one starting with a dash, and one with a newline. With a missing folder (nodir) and with an ordinary file as the target (notdir) the exit code was 1, the sources stayed, and nodir was not created. A missing source (zzz.txt) gave mv: rename src/zzz.txt to dest/zzz.txt: No such file or directory and exit code 1. On a name collision this function overwrote too. With x.txt in both src and dest, mv_t dest src/x.txt src/y.txt ended with exit code 0 and dest/x.txt held the new content (new-x). A variant with only the last line changed to mv -n -- "$@" "$d"/ ended with exit code 0, dest/x.txt kept the old content (old-x), src/x.txt stayed in src, and y.txt was moved. No message says which file was skipped, so if collisions are possible use this variant and count the collisions first.
What I did not test
I did not test a direct run of GNU mv on Linux (the gmv 9.11 on this Mac stood in for it), other macOS versions or zsh, moves across file systems (copy then delete), whether permissions, ACLs or extended attributes change, moving folders, a trailing slash such as nodir/ with two or more sources, the Mac’s -h for symbolic links to folders, or the gmv installation steps. Which file survives a name collision depends on the order find emits, and I measured it on this one input on this Mac. The public record is one 2018 case about mv -T; I found no public article about the -t error itself, and I did not check search volume.
Three-line summary
- The Mac’s mv (26.6.2) rejects nine forms (the four short options -t, -T, -u, -b and five long options) with exit code 64 and moves no file, and when the error is discarded, find -exec ; ends with 0 and looks like a success.
- find -exec sh -c … {} + and xargs -0 -J % moved names with spaces, dashes, Hangul and newlines, and mv_t moved names with spaces, dashes and newlines, but unlike -t none refuses a name collision, and the -d folder check exists only in the hand-added one-liner and mv_t.
- With no such folder, mv – file nodir renames the file with exit code 0, so add a trailing slash or a -d check, and for many files use find instead of * to avoid the argument limit (126).