find가 때때로 명령줄 경로 인수와 일치하는 이유는 무엇입니까?

find지정된 디렉터리 트리를 탐색하고 발견된 각 파일에 대해 지정된 표현식을 평가합니다. 순회는 지정된 경로에서 시작됩니다. 작동 방식을 요약하면 다음과 같습니다 find . -name foo.

• 명령줄의 첫 번째 경로:.
  • basename( .)이 패턴과 일치합니까 foo? 아니, 그러니 아무것도 하지 마세요.
    이것은 /tmp/foo동일한 디렉토리의 또 다른 이름입니다. 하지만 find그것을 모릅니다(알려고 노력해서도 안 됩니다).
  • 경로가 디렉터리인가요? 네, 반복해서 살펴보세요. 목록의 항목을 열거 .하고 각 항목에 대해 반복 프로세스를 수행합니다.
    • 디렉토리는 비어 있습니다. 및 및 .이외의 항목은 포함되어 있지 않으며 재귀적으로 탐색되지 않습니다. 그리고 작업이 완료되었습니다...find

그리고 find /tmp/foo:

• 명령줄의 첫 번째 경로:/tmp/foo
  • basename( foo)이 패턴과 일치합니까 foo? 네, 조건이 충족되었습니다.
    • 이 조건과 연관된 작업이 없으므로 경로를 인쇄하는 기본 작업이 수행됩니다.
  • 경로가 디렉터리인가요? 네, 반복해서 살펴보세요. 목록의 항목을 열거 /tmp/foo하고 각 항목에 대해 반복 프로세스를 수행합니다.
    • 디렉토리는 비어 있습니다. 및 및 .이외의 항목은 포함되어 있지 않으며 재귀적으로 탐색되지 않습니다. 그리고 작업이 완료되었습니다...find

.와 은 /tmp/foo동일한 디렉터리이지만 find동일한 동작을 보장하기에는 충분하지 않습니다. 이 find명령에는 동일한 파일에 대한 경로를 구별하는 방법이 있으며 -name그 중 하나가 술어입니다. find /tmp/foo -name foo시작 디렉터리 및 그 아래에 명명된 모든 항목과 일치합니다 foo. find . -name .시작 디렉터리만 일치합니다( .재귀 순회 중에는 찾을 수 없음).

테스트가 적용되기 전에는 명령줄 매개변수가 표준화되지 않습니다. 따라서 결과는 사용된 경로에 따라 달라집니다(심볼릭 링크가 포함된 경우).

cd /tmp
mkdir foo
ln -s foo bar
find /tmp/foo -name foo
find /tmp/bar -name foo

"귀하의 경우"에서는 두 호출 모두 동일한 결과를 제공하므로 (더) 혼란스러울 수 있습니다. -mindepth 1시작점(POSIX가 아닐 수도 있음)을 무시하려는 경우에 사용할 수 있습니다.

(gnu) find는 명령줄 인수에 대한 비교를 시작하고 거기에서 디렉터리 구조로 드릴다운할 때 명령에 제공된 경로에서 찾은 일치 항목을 표시합니다(따라서 -maxdepth 0테스트를 기본 수준이나 명령줄 인수로만 제한하는 반면, 설명된 -mindepth 1대로 명령줄 인수를 건너뜁니다 man find. 이것이 find /tmp/foo -name 'foo'디렉터리 자체가 비어 있어도 일치 결과가 나오는 이유입니다.

find . -name 'foo'반면에 .(dot)은 동일한 inode에 대한 하드 링크처럼 작동하는 특수 파일이기 때문에 아무 것도 생성되지 않습니다 /tmp/foo. 이는 기호 링크나 제한된 표현식 셸의 경로 이름 확장이 아닌 별도의(특수하지만) 파일 이름과 같습니다. 따라서 주어진 예에서 명령줄 인수에 find를 통해 적용된 첫 번째 테스트에서는 .실제로 에 정의된 이름 패턴과 일치하는 항목이 없기 때문에 일치하는 항목이 표시되지 않습니다 -name 'foo'. /tmp/foo/.패턴 테스트는 -name경로의 기본 이름에 대해서만 수행되므로(참고자료 man find참조), 그렇게 되지도 않습니다 ..

이 동작은 사용자 관점에서 예상되거나 직관적이지 않을 수 있지만(예, 처음에는 저도 혼란스러웠습니다), 이는 버그를 구성하지 않지만 매뉴얼 및 정보 페이지에 설명된 내용과 일치합니다. 논리적 및 기능적 대응(gnu) 조회.

foo상대 검색을 시작한 디렉터리에 지정된 개체가 없습니다.

시작 디렉터리로 절대 이름을 사용할 때 보고할 때 gfind문제가 있다는 가정이 맞습니다 ./tmp/foo

Gfind표준과의 모든 편차로 인해 다른 표준을 찾은 것처럼 보입니다. sfind이것을 로 추천합니다 schilytools.

-name디렉터리 검색 결과에 적용됩니다. 언급한 두 가지 경우 모두 작업 foo에서 디렉터리 항목을 반환하지 않습니다.readdir()