"cp"가 기존 파일을 자동으로 덮어쓰도록 설계된 이유는 무엇입니까? [폐쇄]

기본 재정의 동작은 cpPOSIX에 지정되어 있습니다.

3. source_file이 일반 파일 형식인 경우 다음 단계를 수행해야 합니다.

   3.a. dest_file이 존재하고 이전 단계에서 작성된 경우 동작은 지정되지 않습니다. 그렇지 않고 dest_file이 있으면 다음 단계를 수행하십시오.

   3.ai -i 옵션이 적용되는 경우 cp 유틸리티는 표준 오류에 대한 프롬프트를 작성하고 표준 입력에서 한 줄을 읽어야 합니다. 응답이 긍정적이지 않으면 cp는 source_file에 대해 더 이상 작업을 수행하지 않고 나머지 파일을 계속 처리합니다.

   3.a.ii dest_file에 대한 파일 디스크립터는 dest_file을 경로 매개변수로 사용하고 O_WRONLY 및 O_TRUNC Bitwise를 사용하는 POSIX.1-2017 시스템 인터페이스 볼륨에 정의된 open() 함수와 동일한 작업을 수행하여 얻습니다. OR oflag 인수로 사용됩니다.

   3.a.iii.파일 설명자를 얻으려는 시도가 실패하고 -f 옵션이 유효한 경우, cp는 POSIX.1-에 정의된 unlink() 함수와 동일한 작업을 수행하여 파일 설명자를 얻으려고 시도해야 합니다. 2017 dest_file로 호출된 시스템 인터페이스 볼륨 경로 매개변수로 파일을 제거합니다. 이 시도가 성공하면 cp는 3b단계로 진행합니다.

POSIX 사양이 작성되었을 때 기본 재정의 동작에 대한 기본 가정이 포함된 수많은 스크립트가 이미 존재했습니다. 이러한 스크립트 중 다수는 cron 작업이나 기타 백그라운드 작업과 같이 사용자가 직접 존재하지 않고 실행되도록 설계되었습니다. 행동을 바꾸면 그들을 파괴할 것입니다. 필요한 경우 강제 재정의 옵션을 추가하기 위해 이를 검사하고 수정하는 것은 이점이 거의 없는 힘든 작업으로 간주될 수 있습니다.

게다가 Unix 명령줄은 초보자의 학습 곡선을 희생하더라도 숙련된 사용자가 효율적으로 작업할 수 있도록 항상 설계되었습니다. 사용자가 명령을 입력하면 컴퓨터는 사용자가 추측하지 않고 해당 명령을 의미할 것으로 기대합니다. 잠재적으로 파괴적인 명령에 주의하는 것은 사용자의 책임입니다.

원래 Unix가 개발되었을 때 시스템은 최신 컴퓨터에 비해 메모리와 대용량 저장 공간이 거의 없었으며 경고 및 프롬프트를 덮어쓰는 것은 낭비적이고 불필요한 사치로 여겨졌을 수 있습니다.

POSIX 표준이 작성될 때 선례가 확고히 확립되었으며 표준 작성자는 POSIX 표준의 장점을 잘 알고 있었습니다.이전 버전과의 호환성을 깨지 않습니다.

cp또한 다른 사람들이 설명했듯이 모든 사용자는 쉘 별칭을 사용하거나 대체 명령을 작성 하고 수정하여 $PATH표준 시스템 명령보다 먼저 대체 명령을 찾고 원하는 경우 그런 방식으로 보안을 확보함으로써 스스로 이러한 기능을 추가/활성화할 수 있습니다 .

그러나 이렇게 하면 자신에게 위험이 초래된다는 것을 알게 될 것입니다. cp명령이 대화식으로 사용될 때 한 방향으로 실행되고 스크립트에서 호출될 때 다른 방식으로 실행되는 경우 차이점이 있다는 것을 기억하지 못할 수도 있습니다. 다른 시스템에서는 자신의 시스템의 경고와 프롬프트에 익숙해졌기 때문에 부주의해질 수 있습니다.

스크립트의 동작이 여전히 POSIX를 준수하는 경우 대화형 사용 시 프롬프트에 익숙해진 다음 많은 복사를 수행하는 스크립트를 작성한 다음 실수로 무언가를 다시 덮어썼다는 것을 알게 될 수 있습니다.

스크립트에서 프롬프트도 강제로 표시하는 경우 사용자 없이 컨텍스트(예: 백그라운드 프로세스 또는 크론 작업)에서 실행될 때 명령은 무엇을 수행합니까? 스크립트가 중단되거나, 중단되거나, 덮어쓰게 됩니까?

일시 중단 또는 중단은 자동으로 완료되어야 하는 작업이 완료되지 않음을 의미합니다. 때로는 덮어쓰지 않는 것 자체도 문제를 일으킬 수 있습니다. 예를 들어 오래된 데이터가 최신 데이터로 대체되는 대신 다른 시스템에서 두 번 처리될 수 있습니다.

명령줄의 강력한 기능은 다음과 같은 사실에서 비롯됩니다.명령줄에서 어떤 작업을 수행하는 방법을 알게 되면 스크립트를 작성하여 해당 작업이 자동으로 수행되도록 하는 방법을 암묵적으로 알게 됩니다.. 그러나 이는 대화형으로 사용하는 명령이 스크립트 컨텍스트에서 호출될 때에도 정확히 동일하게 작동하는 경우에만 해당됩니다. 대화형 사용과 스크립트 사용 간의 동작에 큰 차이가 있으면 고급 사용자를 짜증나게 할 수 있는 인지 부조화가 발생할 수 있습니다.

cp유닉스의 시작부터. Posix 표준이 작성되기 오래 전에 존재했습니다. 사실입니다. Posix는 cp이와 관련하여 기존 동작을 공식화합니다.

우리는 남자가 진짜 남자이고 여자가 진짜 여자이고 털복숭이 작은 생물이었던 시대(1970-01-01)에 대해 이야기하고 있습니다. 그 당시에는 코드를 추가하면 프로그램이 더 커졌습니다. Unix를 실행하는 최초의 컴퓨터가 PDP-7(144KB RAM으로 업그레이드 가능!)이었기 때문에 이는 당시 문제가 되었습니다. 그래서 그 물건은 작고, 매우 효율적이며, 안전 기능도 없습니다.

따라서 그 당시에는 나중에 후회할 일을 하는 것을 컴퓨터가 막을 수 있는 능력이 없었기 때문에 자신이 무엇을 하고 있는지 알아야 했습니다.

(Zevar에는 멋진 만화가 있습니다. "zevar cerveaux Assiste par ordordur"를 검색하여 컴퓨터의 진화를 찾아보세요. 또는 시도해 보세요.http://a54.idata.over-blog.com/2/07/74/62/dessins-et-bd/le-CAO-de-Zevar---reduc.jpg존재하는 한)

정말로 관심이 있는 사람들을 위해(댓글에서 약간의 추측을 보았습니다): cp첫 번째 Unix의 원래 코드는 약 두 페이지의 어셈블리 코드였습니다(C는 나중에 나왔습니다). 관련 부분은 다음과 같습니다.

sys open; name1: 0; 0   " Open the input file
spa
  jmp error         " File open error
lac o17         " Why load 15 (017) into AC?
sys creat; name2: 0     " Create the output file
spa
  jmp error         " File create error

(그래서 어렵다 sys creat)

그리고, 그렇게 하면: Unix 버전 2가 사용됩니다(코드 조각).

mode = buf[2] & 037;
if((fnew = creat(argv[2],mode)) < 0){
    stat(argv[2], buf);

creat이는 테스트나 보호 장치가 없으면 어려운 일이기도 합니다. V2 Unix용 C 코드는 cp55줄 미만이라는 점에 유의하세요!

이러한 명령은 스크립트에서도 사용하기 위한 것이므로 사람의 감독 없이 실행될 수 있으며 많은 경우 대상을 재정의하기를 원하기 때문입니다(Linux 쉘의 철학은 사람이 자신이 무엇을 하고 있는지 알고 있다는 것입니다).

또한 다음과 같은 몇 가지 보호 장치도 있습니다.

• GNU cp에는 -n|--no-clobber​
• 여러 파일을 하나로 복사하면 cp마지막 파일이 디렉터리가 아니라고 불평합니다.

"cp"의 디자인은 Unix의 원래 디자인으로 거슬러 올라갑니다. 사실 유닉스 디자인 뒤에는 농담 반으로 부르는 것보다 약간 덜한 일관된 철학이 있습니다.더 나쁠수록 더 좋다^* .

기본 아이디어는 코드를 단순하게 유지하는 것이 실제로 완벽한 인터페이스를 갖거나 "올바른 일을 하는 것"보다 더 중요한 디자인 고려 사항이라는 것입니다.

• 단순성 - 디자인은 구현과 인터페이스 모두에서 단순해야 합니다.인터페이스보다 구현 단순성이 더 중요. 단순성은 디자인에서 가장 중요한 고려 사항입니다.

• 정확성 - 디자인은 관찰 가능한 모든 측면에서 정확해야 합니다. 단순한 것이 올바른 것보다 약간 낫습니다.

• 일관성 - 디자인이 너무 일관성이 없어야 합니다. 어떤 경우에는 단순성을 위해 일관성이 희생될 수 있지만덜 일반적인 상황을 처리하는 디자인 부분을 버리는 것이 좋습니다.구현 복잡성이나 불일치를 도입하는 대신.

• 완전성 - 디자인은 가능한 한 많은 실제 상황을 다루어야 합니다. 합리적으로 예상되는 모든 상황이 다루어져야 합니다. 다른 품질을 위해 무결성이 희생될 수 있습니다. 실제로 구현 단순성이 훼손될 때마다 완전성이 희생되어야 합니다. 단순성이 유지되면 완전성을 위해 일관성이 희생될 수 있습니다. 특히 인터페이스의 일관성은 가치가 없습니다.

^{(내 것을 강조하다)}

1970년에 "이 파일을 복사하고 싶습니다"라는 사용 사례를 기억하세요.오직복사하는 사람에게 "만약 존재하지 않았다면"이라는 말은 상당히 드문 사용 사례입니다. 그것이 당신이 원하는 것이라면, 복사하기 전에 확인하거나 심지어 스크립트를 작성할 수도 있을 것입니다.

이 기사의 저자는 이러한 설계 접근 방식을 사용하는 운영 체제가 당시 구축된 다른 모든 운영 체제보다 성능이 뛰어난 이유에 대한 자신의 이론을 가지고 있습니다.

"나쁠수록 좋다"는 철학의 또 다른 이점은 프로그래머가 좋은 성능과 적절한 리소스 사용을 달성하기 위해 일부 보안, 편의성 및 번거로움을 희생하는 데 익숙하다는 것입니다. 뉴저지 방식으로 작성된 프로그램은 소형 및 대형 시스템 모두에서 잘 실행되며, 코드는 바이러스 위에 작성되었기 때문에 이식성이 뛰어납니다.

원본 바이러스는 기본적으로 좋아야 한다는 점을 기억하는 것이 중요합니다. 그렇다면 휴대 가능한 한 바이러스 확산은 보장됩니다. 일단 입소문이 나면 기능을 90%에 가깝게 향상시키려는 압력이 있을 것입니다. 그러나 사용자는 옳은 것보다 더 나쁜 것을 받아들이도록 조건화되었습니다. 따라서 "나쁠수록 좋다"는 소프트웨어는 먼저 수용을 얻고, 두 번째로 사용자 기대치를 낮추고, 세 번째로 거의 올바른 수준까지 개선됩니다.

^{* - 또는 저자(다른 사람은 없음)가 "뉴저지 방법"이라고 부르는 것입니다} .