Watch at Ease세상을 읽고, 일상의 답을 찾다.

기술 · 실용 가이드

sed -i가 Linux에서는 되지만 macOS에서 실패합니까? 편집 전에 인자 경계를 증명하세요

sed implementation과 정확한 argv를 확인하고 변환을 preview한 뒤 backup 또는 temporary-file 교체 정책을 선택합니다.

ko sed argument boundary diagram
오리지널 편집 일러스트: verify the sed implementation and argument boundary. Watch at Ease

sed -i가 Linux에서는 되고 macOS에서 실패할 때 화면에 보이는 command만으로는 부족합니다. GNU와 BSD 계열 sed는 suffix를 다르게 정의하고 shell이 실제 token을 결정합니다.

source를 보존하고 implementation과 stdout preview를 확인한 다음 backup 또는 교체 분기를 시험하면 portability 수정이 파괴적 편집이 되는 것을 막을 수 있습니다.

implementation과 정확한 인자 보존

실행 파일 경로, version 출력, OS, shell, 전체 command와 생성된 filename을 기록합니다. 모든 차이를 quoting 오류라고 부르지 말고 어떤 sed가 인자를 해석했는지 먼저 증명합니다.

변경 전에 shell 변수와 배열을 확장합니다. Linux에서 복사한 command는 화면상 비슷해도 BSD 계열 sed에 도달한 token 경계가 다를 수 있습니다.

in-place suffix 규칙 분리

GNU sed의 -i suffix는 선택 사항입니다. suffix가 없으면 backup 없이 덮어쓰고, 있으면 원본을 backup 이름으로 바꿉니다. -Ei와 -iE는 같지 않습니다.

FreeBSD manual은 -i 다음에 extension을 요구합니다. 빈 extension은 backup을 만들지 않고, 값이 있으면 backup 이름이 됩니다. extension을 검증할 데이터로 다룹니다.

편집 전에 변환 preview

복사본에서 -i를 제거하고 stdout을 새 temporary file에 씁니다. 입력과 비교하고 line count, encoding과 예상 pattern 일치를 확인합니다.

이렇게 하면 sed program과 교체 동작을 분리할 수 있습니다. preview가 틀리면 regex mode, escape, delimiter 또는 newline을 먼저 수정합니다.

범위가 명확한 portable 전략

통제된 환경에서는 implementation을 판별해 명시적 backup suffix가 있는 검증된 분기를 사용합니다. portable script라면 temporary output을 검증한 뒤 교체합니다.

다른 implementation이 거부할 수 있는 sed --version만 사용하지 마세요. 실패를 처리하는 implementation test, build contract 또는 표준 temporary-file 절차를 사용합니다.

종료 증거와 rollback 확인

no match, multiple match, 공백이 있는 path, 마지막 newline, 기존 backup 이름을 시험하고 모든 runner에서 결과, exit code와 backup policy를 확인합니다.

처음에는 소규모로 배포합니다. 의도한 내용만 바뀌고 관련 없는 bytes가 유지되며 예상 files만 존재해야 성공입니다. 실패하면 입력과 argv를 보존합니다.

ko sed preview and replacement diagram
오리지널 편집 일러스트: preview and compare before replacing the source file. Watch at Ease