우선 제가 Unix에 대해 지식이 부족하다는 점을 양해해 주시기 바랍니다. 그것이 바로 제가 여기 있는 이유입니다. Mac에서 파일을 검색하는 AppleScript를 만들고 다음을 사용하여 훨씬 빠르게 만들었습니다.
set MySubfolderTextList to do shell script "find " & MyDirectory & " -type d"
일반 유닉스에서는 이렇게 될 것이다.find MyDirectory -type d
그러면 이름이 지정된 폴더의 최상위 수준에서 반복적으로 시작하는 모든 하위 폴더 목록이 제공됩니다 MyDirectory. 이제 일반 AppleScript를 사용하여 만든 이전 루틴에 비해 속도가 놀랍습니다. 하지만 문제는 수천 개의 하위 디렉터리가 있는 폴더에서 이 스크립트를 실행할 때 몇 초 동안 작은 비치볼이 나온다는 것입니다. 몇 시간 또는 몇 분 동안 다음 중 하나를 나타냅니다. 발생했거나 시스템이 충돌했습니다. 검색 진행 상황에 대해 Unix로부터 피드백을 받을 수 있었으면 좋겠습니다. 그렇지 않으면 프로그램이 충돌하여 클라이언트가 당황하게 될 것입니다.
답변1
설마. find는 디렉토리 트리에 무엇이 있는지 모르고 대신 모든 디렉토리 목록을 재귀적으로 읽어서 찾는다는 점을 고려하세요. (말장난해서 죄송합니다.) 예를 들어 두 개의 첫 번째 수준 디렉터리가 있을 수 있습니다. 하나는 파일 1개, 다른 하나는 파일 1,000,000개입니다.
프로그램이 먼저 트리를 검색하여 모든 파일의 수와 크기를 찾은 다음 이를 사용하여 완료를 추정할 수 있으므로 트리 복사와 같은 작업은 다릅니다. 이는 파일 크기가 명시적으로 저장되므로 크기를 찾기 위해 전체 파일을 읽을 필요가 없기 때문에 수행할 수 있습니다. 그러나 내가 아는 한, 일반적인 파일 시스템은 트리의 파일 수에 대한 정보를 유지하지 않습니다. (불가능하다는 말은 아니지만 일부 시스템이 가능하더라도 해당 정보를 사용하려면 find를 수정해야 합니다.)
이제 비치볼 느낌과 꽁꽁 얼어붙는 느낌에 대해서는 실행 중에 UI가 차단되도록 하위 프로세스를 동기적으로 실행하는 건가요? 이것은 일반적으로 나쁜 생각이며 "아직 검색 중..."이라는 멋진 메시지를 표시하면서 백그라운드에서 외부 프로그램을 실행하는 방법을 찾고 싶을 수도 있습니다. 사용자가 참을성이 없으면 검색을 중단하도록 선택할 수 있습니다.
답변2
pv줄 수를 세는 명령이 있으면 이를 사용할 수 있습니다. 예를 들어
find ~ -type d | pv -l -F '%b dirs found' >/tmp/output