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

cp다음 명령으로 테스트 했습니다.

$ ls
first.html   second.html  third.html

$ cat first.html
first

$ cat second.html
second

$ cat third.html
third

그런 다음에 복사 first.html합니다 second.html.

$ cp first.html second.html

$ cat second.html
first

second.html오류없이 파일 을 자동으로 덮어 씁니다. 그러나 동일한 이름의 파일을 끌어서 놓아 데스크탑 GUI에서 수행하면 first1.html자동으로 접미사가 붙습니다 . 이렇게하면 실수로 기존 파일을 덮어 쓰지 않습니다.

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을 경로 인수로 사용하여 호출 된 POSIX.1-2017의 시스템 인터페이스 볼륨에 정의 된 open () 함수와 동등한 조치를 수행하고 O_WRONLY 및 O_TRUNC의 비트 단위 OR을 oflag 인수.

   3.a.iii. 파일 디스크립터 확보 시도가 실패하고 -f 옵션이 유효한 경우, cp는 dest_file을 사용하여 호출 된 POSIX.1-2017의 시스템 인터페이스 볼륨에 정의 된 unlink () 함수와 동등한 조치를 수행하여 파일 제거를 시도합니다. 경로 인수로. 이 시도가 성공하면 cp는 3b 단계를 계속합니다.

POSIX 사양을 작성할 때 기본 덮어 쓰기 동작에 대한 기본 가정이있는 많은 스크립트가 이미 존재했습니다. 이러한 스크립트는 대부분 크론 작업이나 기타 백그라운드 작업과 같이 사용자가 직접 방문하지 않고 실행되도록 설계되었습니다. 행동을 바꾸면 그것들이 깨졌을 것입니다. 필요할 때마다 덮어 쓰기를 강제 할 수있는 옵션을 추가하기 위해 모두를 검토하고 수정하는 것은 최소한의 이점을 가진 거대한 작업으로 간주되었을 것입니다.

또한 유닉스 커맨드 라인은 초보자에게 어려운 학습 곡선을 희생하더라도 숙련 된 사용자가 효율적으로 작업 할 수 있도록 항상 설계되었습니다. 사용자가 명령을 입력 할 때, 컴퓨터는 사용자가 전혀 추측하지 않고 실제로 명령을 의미한다고 기대해야합니다. 잠재적으로 파괴적인 명령에주의하는 것은 사용자의 책임입니다.

원래 유닉스가 개발되었을 때, 시스템은 경고와 프롬프트를 덮어 쓰는 현대 컴퓨터와 비교했을 때 메모리와 대용량 저장 공간이 너무 적어서 낭비적이고 불필요한 사치품으로 여겨졌습니다.

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

또한 다른 사용자가 설명했듯이 모든 사용자는 쉘 별명을 사용하거나 교체 cp명령을 작성하고 $PATH표준 시스템 명령 이전에 대체품을 찾도록 수정 하여 기능을 추가하거나 활성화 할 수 있습니다. 원하는.

그러나 그렇게하면 자신에게 위험을 초래할 수 있습니다. 은 IF cp명령 한 대화 형으로 사용하는 방법과 스크립트에서 호출 다른 방식으로 동작합니다, 당신은 차이가 존재 함을 기억하지 않을 수 있습니다. 다른 시스템에서는 시스템의 경고 및 프롬프트에 익숙해 져 부주의하게 될 수 있습니다.

스크립트의 동작이 여전히 POSIX 표준과 일치하면 대화식으로 프롬프트에 익숙해 질 수 있고 대량 복사를 수행하는 스크립트를 작성한 다음 실수로 다시 덮어 쓴 것을 발견 할 수 있습니다.

스크립트에서도 프롬프트를 표시하면 백그라운드 프로세스 또는 크론 작업과 같이 사용자가없는 컨텍스트에서 명령을 실행할 때 명령이 수행하는 작업은 무엇입니까? 스크립트가 중단, 중단 또는 덮어 쓰기됩니까?

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

명령 행의 강력한 기능 중 일부는 명령 행에서 무언가를 수행하는 방법을 알고 나면 스크립트를 통해 자동으로 수행하는 방법을 암시 적으로 알 수 있다는 사실에서 비롯 됩니다 . 그러나 대화식으로 사용하는 명령이 스크립트 컨텍스트에서 호출 될 때도 동일하게 작동하는 경우에만 해당됩니다. 대화 형 사용과 스크립트 사용 사이의 동작에 중대한 차이가있을 경우 파워 사용자에게는 짜증나는 일종의인지 부조화가 발생합니다.

cp유닉스의 시작에서 온다. Posix 표준이 작성되기 훨씬 전에있었습니다. 실제로 : Posix cp는 이와 관련 하여 기존 동작을 공식화했습니다 .

우리는 Epoch (1970-01-01)에 대해 이야기하고 있는데, 남자가 진짜 남자 였을 때, 여자는 진짜 여자 였고 작은 생물을 털었습니다 ... 당시에는 추가 코드를 추가하면 프로그램이 더 커졌습니다. Unix를 실행 한 첫 번째 컴퓨터가 PDP-7 (144KB RAM으로 업그레이드 가능)이기 때문에 문제가되었습니다. 따라서 안전 기능이없는 작고 효율적이었습니다.

따라서 그 당시에는 컴퓨터에 나중에 후회하는 일을 막을 힘이 없었기 때문에 현재하고있는 일을 알아야했습니다.

(Zevar의 멋진 만화가 있습니다. 컴퓨터의 진화를 찾기 위해 "zevar cerveaux assiste par ordinateur"를 검색 하십시오 . 또는 http://perinet.blogspirit.com/archive/2012/02/12/zevar-et- 존재하는 한 cointe.html )

정말로 관심이있는 사람들을 위해 (주석에서 약간의 추측을 보았습니다) : cp첫 번째 유닉스 의 원본 은 약 2 페이지의 어셈블러 코드였습니다 (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)

그리고 우리가 그 동안 : 유닉스 버전 2가 사용되었습니다 (코드 조각)

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

creat테스트 나 보호 수단이 없으면 어렵습니다 . V2 Unix의 C 코드 cp는 55 줄 미만입니다!

이러한 명령은 스크립트에서 사용하기위한 것이며, 어떤 종류의 인간 감독 없이도 실행될 수 있으며, 실제로 대상을 덮어 쓰려는 경우가 많기 때문에 (Linux 쉘의 철학은 인간이 그는하고있다)

여전히 몇 가지 보호 조치가 있습니다.

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

"한 번에 한 가지만합니까?"

이 의견은 일반적인 설계 원칙에 대한 질문처럼 들립니다. 종종, 이것에 관한 질문은 매우 주관적이며, 우리는 정답을 쓸 수 없습니다. 이 경우 질문을 닫을 수 있음에 유의하십시오.

때로는 개발자가 디자인에 대해 글을 썼기 때문에 원래 디자인 선택에 대한 설명이 있습니다. 그러나 나는이 질문에 대한 좋은 대답이 없습니다.

cp이런 식으로 설계된 이유 는 무엇 입니까?

문제는 유닉스가 40 세 이상이라는 것입니다.

지금 새 시스템을 작성중인 경우 다른 설계를 선택할 수 있습니다. 그러나 다른 답변에서 언급했듯이 Unix를 변경하면 기존 스크립트가 중단됩니다.

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

짧은 대답은 "모르겠습니다"입니다 :-).

그것은 cp단지 하나의 문제 라는 것을 이해하십시오 . 원래 명령 프로그램 중 어느 것도 파일 덮어 쓰기 또는 삭제를 방지하지 못했다고 생각합니다. 출력을 재 지정할 때 쉘에도 비슷한 문제점이 있습니다.

$ cat first.html > second.html

이 명령은 또한 자동으로 덮어 씁니다 second.html.

이 모든 프로그램을 어떻게 다시 디자인 할 수 있을지 생각하고 싶습니다. 약간의 추가 복잡성이 필요할 수 있습니다.

나는 이것이 설명의 일부라고 생각한다. 초기 유닉스는 간단한 구현을 강조했다 . 이에 대한 자세한 설명은이 답변의 끝 부분에 링크 된 "더 나은 것이 좋습니다"를 참조하십시오.

이미 존재하는 > second.html경우 오류와 함께 중지되도록 변경할 수 second.html있습니다. 그러나 앞에서 언급했듯이 때때로 사용자 는 기존 파일을 교체하려고합니다. 예를 들어, 그녀는 복잡한 명령을 작성하여 원하는 것을 할 때까지 여러 번 시도 할 수 있습니다.

rm second.html필요한 경우 사용자가 먼저 실행할 수 있습니다 . 이것은 좋은 타협 일 수 있습니다! 자체 단점이 있습니다.

1. 사용자는 파일 이름을 두 번 입력해야합니다.
2. 사람들은 또한를 사용하여 많은 문제를 겪습니다 rm. 그래서 나는 rm더 안전하게 만들고 싶습니다 . 그러나 어떻게? rm각 파일 이름 을 표시하고 사용자에게 확인을 요청하면 이제 그녀 는 한 줄 대신 세 줄의 명령 을 작성해야 합니다. 또한, 너무 자주해야한다면, 습관을 들이고 "y"를 입력하여 생각없이 확인합니다. 따라서 매우 성 가실 수 있으며 여전히 위험 할 수 있습니다.

최신 시스템에서는 명령을 설치하고trashrm 가능한 경우 대신 사용하는 것이 좋습니다 . 휴지통 스토리지의 도입은 예 를 들어 단일 사용자 그래픽 PC에 대한 좋은 아이디어였습니다 .

또한 원래의 Unix 하드웨어의 한계, 즉 RAM 및 디스크 공간 제한, 느린 프린터에 표시되는 출력 , 시스템 및 개발 소프트웨어 의 한계를 이해하는 것이 중요하다고 생각합니다 .

명령 에 대한 파일 이름을 빠르게 입력하기 위해 원래 Unix에는 탭 완성 기능 이 없었습니다 rm. 또한 원래 Bourne 셸에는 명령 기록이 없습니다 (예 :에서 위 화살표 키를 사용하는 경우 bash).

프린터 출력에서는 라인 기반 편집기를 사용 ed합니다. 시각적 텍스트 편집기보다 배우기가 어렵습니다. 현재 행을 인쇄하고 변경 방법을 결정한 후 편집 명령을 입력해야합니다.

사용 > second.html은 라인 편집기에서 명령을 사용하는 것과 조금 비슷합니다. 그 효과는 현재 상태에 따라 다릅니다. ( second.html이미 존재하는 경우 내용이 삭제됩니다). 사용자가 현재 상태를 잘 모를 ls경우 ls second.html먼저 실행해야합니다 .

설계 원칙으로서의 "간단한 구현"

유닉스 디자인에 대한 대중적인 해석이 시작됩니다.

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

...

가브리엘은 MIT 접근 방식보다 "Worse is better"가 더 성공적인 소프트웨어를 생산했다고 주장했다. 예를 들어 소프트웨어를 새로운 시스템으로 포팅하는 것이 훨씬 쉬워집니다. 따라서 [더 나은] 프로그램을 개발하고 배포 할 수있는 기회가 있기 훨씬 전에 그 사용이 빠르게 확산 될 것입니다 (1 차 우위).

https://ko.wikipedia.org/wiki/Worse_is_better

"cp"의 디자인은 Unix의 원래 디자인으로 돌아갑니다. 실제로 유닉스 디자인 뒤에는 일관된 철학이 있었는데, 이는 반 농담으로 볼 때 Worse-is-Better ^* 보다 약간 적었습니다 .

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

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

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

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

• 완전성-디자인은 실용적 많은 중요한 상황을 포함해야합니다. 합리적으로 예상되는 모든 사례를 다루어야합니다. 다른 품질을 위해 완성도를 희생 할 수 있습니다. 실제로 구현의 단순성이 위태로워 질 때마다 완전성을 희생해야합니다. 단순성이 유지되면 완전성을 달성하기 위해 일관성을 희생 할 수 있습니다. 인터페이스의 일관성은 특히 가치가 없습니다.

^{( 중점 광산 )}

이것은 1970 년을 기억하면서 "이 파일이 존재하지 않는 경우 에만 이 파일을 복사하고 싶습니다 "의 사용 사례는 복사를 수행하는 사람에게는 매우 드문 사용 사례였습니다. 그것이 당신이 원하는 것이라면, 당신은 복사하기 전에 상당히 확인할 수있을 것이고, 그것은 심지어 스크립트 될 수도 있습니다.

그 설계 방식을 가진 OS가 그 당시에 구축 된 다른 모든 OS보다 우월한 이유 인 이유에 관해서는, 에세이의 저자도 그에 대한 이론을 가지고있었습니다.

더 좋지 않은 철학의 또 다른 이점은 프로그래머가 안전성과 편의성을 희생하고 좋은 성능과 적당한 자원 사용을 얻는 데 어려움을 겪고 있다는 것입니다. 뉴저지 방식을 사용하여 작성된 프로그램은 소형 컴퓨터와 대형 컴퓨터 모두에서 잘 작동하며, 코드는 바이러스 위에 작성되므로 이식성이 뛰어납니다.

초기 바이러스는 기본적으로 양호해야한다는 것을 기억하는 것이 중요합니다. 그렇다면, 바이러스 확산은 이식 가능한 한 보장된다. 일단 바이러스가 확산되면 기능을 90 %에 가깝게 늘려서 바이러스를 개선해야 할 압력이 있지만, 사용자는 이미 옳은 것보다 더 나쁜 상태로 받아 들여지기로되어 있습니다. 따라서 더 나빠진 소프트웨어는 먼저 수용을 받고, 두 번째는 사용자의 기대치를 줄이며, 세 번째는 거의 옳은 수준으로 개선 될 것입니다.

^{*-또는 "뉴저지 접근 방식"이라고 불리는 저자는 아무도 없습니다} .

주요 이유는 GUI가 대화식으로 정의되어 있고 바이너리와 같은 /bin/cp것은 모든 종류의 장소에서 호출 할 수있는 프로그램 일뿐입니다 (예 : GUI ;-)). 오늘도 대다수의 전화 /bin/cp는 쉘 명령을 입력하는 사용자가있는 실제 터미널이 아니라 HTTP 서버, 메일 시스템 또는 NAS에서 온 것입니다. 대화 형 환경에서는 사용자 오류에 대한 기본 제공 보호 기능이 완벽합니다. 간단한 바이너리에서는 그렇지 않다. 예를 들어, GUI는 /bin/cp실제 작업을 수행하기 위해 백그라운드에서 호출 할 가능성이 높으며 사용자에게 방금 요청한 경우에도 표준에 대한 안전 질문을 처리해야합니다!

/bin/cp원한다면 안전한 래퍼를 작성하는 것은 사소한 날부터 시작되었습니다 . * nix 철학은 사용자에게 간단한 빌딩 블록을 제공하는 /bin/cp것입니다.