"cp"가 재귀적일 것이라고 예상하지 못하는 경우는 언제입니까?

"cp"가 재귀적일 것이라고 예상하지 못하는 경우는 언제입니까?

cp어떤 상황에서 디렉토리에서 이 명령을 사용하고 싶지만 아직 사용할 수 없는 경우가 있습니까?아니요재귀적인가요? 고려하다:

$ tree
.
└── old
    └── inner
        └── a.txt

2 directories, 1 file

$ cp old/inner/ .
cp: omitting directory `old/inner/'

$ tree
.
└── old
    └── inner
        └── a.txt

2 directories, 1 file

그게 정확히 무슨 일을 한 걸까요? 그렇다면 왜 이 -r플래그를 사용하지 않을 것이며, 명시하지 않고 이를 암시하는 것은 어떨까요? 이 -r플래그는 일반 파일에 아무런 영향을 미치지 않습니다.

$ cp -r old/inner/a.txt .
$ ls
a.txt  old

별칭을 붙일 수 있다는 것을 알고 있지만 cpcp -r목표는 아무것도 고치는 것이 아니라 원인이 무엇인지 이해하는 것입니다.

답변1

나는 종종 디렉토리에 파일을 복사하고 싶은데, 왜 이것이 이상하게 보입니까? 그것은 당신이하고 싶은 일에 달려 있습니다. 예를 들어, 프로그램을 실행하는 데 이러한 파일이 필요하다는 가정 하에 프로젝트에서 사용하는 모든 파일을 디렉터리에 저장하는 경우도 있습니다. 또한 이전 버전이나 데이터 파일 등을 포함하는 다양한 하위 디렉터리가 있을 수도 있습니다. 프로그램을 실행하기 위해 서버로 전송하려면 다음이 필요합니다.문서하위 디렉토리가 아니므로 cp기본값이 정확히 필요한 것입니다.

가끔 하는 간단한 사실을 제외하면아니요재귀적으로 복사하려면 일반적으로 거의 모든 프로그램에서 재귀를 명시적으로 활성화해야 합니다. 이는 표준이며 사용자가 프로그램을 처음 사용할 때 기대할 수 있는 것입니다. 따라서 재귀를 기본값으로 설정하는 것은 좋은 생각이 아닙니다. 재귀를 위한 플래그를 추가 해야 하는 것은 -r예상되는 동작입니다. 일반적으로 기본적으로 재귀를 원하지 않습니다(생각 chmod하거나 grep기다리십시오 ls).

답변2

디렉터리를 반복적으로 복사하면 많은 수의 파일을 덮어쓸 가능성이 있습니다. 하나의 명령을 실수로 수행하면 많은 피해를 입힐 수 있습니다. 기본값은 비재귀적이므로 한 디렉터리를 다른 디렉터리로 복사할 때마다 명시적으로 수행하므로 이론적으로는 실행 전에 입력이 고려됩니다.

이것이 가장 좋은 예는 아니지만 두 대상이 모두 디렉터리라는 사실을 깨닫지 못한 채 실수로 다음 명령을 입력한 경우 어떤 일이 일어날지 상상해 보십시오.

cp /bin /usr # /usr/bin already exists and has important stuff in it

편집 1:한 가지 해결책은 명시적인 플래그를 추가하는 대신 사용자에게 대화형으로 메시지를 표시하고 "계속하시겠습니까?"라고 묻는 것입니다. 그러나 이는 "대화형 입력을 고집하지 마십시오"[McIlroy78]라는 UNIX 철학과 완전히 일치하지 않습니다. cp는 시간이 지남에 따라 몇 가지 중요한 변화를 겪은 오래된 UNIX 프로그램이지만 이러한 계보는 여전히 설계의 여러 측면에서 볼 수 있습니다.

편집 2:나는 몇 가지 다른 좋은 이유를 찾았습니다. 아마도 그 이상일 것입니다. StackExchange에서 하나를 찾을 수 있습니다.

  1. 쉘 스크립트에서의 사용으로 인해 명령줄 옵션과 프로그램의 기본 동작은 오래되고 일반적이므로 cp변경하기 어렵습니다. 일부 스크립트는 이 동작에 의존할 수 있습니다(디렉토리 복사 거부). 많은 쉘 스크립트에서 대화형 프롬프트는 원하는 것이 아닙니다.

  2. 파일 복사와 디렉터리 복사는 근본적으로 다른 두 가지 작업이며 이를 처리하려면 개념적으로 별도의 명령이나 옵션이 필요합니다.unix mv 프로그램에는 디렉토리에 -R(재귀) 옵션이 필요하지 않지만 cp에는 필요한 이유는 무엇입니까?

[McIlroy78] 벨 시스템 기술 저널. 벨 연구소.매킬로이 MD, EN Pinson 및 BA Tague. "유닉스 시간 공유 시스템 발전". 1978. 57(6, 2부). 피. 1902.

관련 정보