답변:
locate(1)find(1)속도 보다 한 가지 큰 장점이 있습니다.
find(1)그러나 다음 보다 많은 장점이 있습니다 locate(1).
find(1)AT & T Unix의 첫 번째 버전으로 돌아가는 기본 입니다. Busybox를 통해 컷 다운 임베디드 리눅스에서도 찾을 수 있습니다 . 보편적입니다.
locate(1)보다 훨씬 젊습니다 find(1). 초기 조상은 locate(1) 1983 년까지 등장하지 않았으며 , GNU findutils 와 4.4BSDlocate 에 채택되었을 때 1994 년까지 " " 로 널리 이용되지 않았다 .
locate(1)또한 비표준 이므로 기본적으로 모든 위치에 설치되지 않습니다. 일부 POSIX 유형 OS는 옵션으로 제공하지 않으며, 사용 가능한 경우 사용 가능한 최소 기능 세트를 지정하는 독립 표준이 없기 때문에 구현에 원하는 기능이 없을 수 있습니다.
거기이다 사실상의 표준 인 BSD는locate(1) 하지만, 다른 두 가지 맛에만 때문입니다 locate해당 옵션의 모든 구현 : -0, -c, -d, -i, -l, -m, -s,와 -S. mlocateBSD 6 추가 옵션을하지 구현 locate: -b, -e, -P, -q, --regex와 -w. GNU는locate 여섯 플러스 또 다른 구현 사 : -A, -D,을 -E, 그리고 -p. (나는 별명과 -?vs -h와 같은 사소한 차이점을 무시하고 --help있습니다.)
BSD 와 Mac OS X은 BSD를 제공 locate합니다.
대부분의 Linux는 GNU locate를 제공하지만 mlocate대신 Red Hat Linux 및 Arch가 제공 됩니다. 데비안은 기본 설치로 설치하지 않지만 기본 패키지 리포지토리에서 두 버전을 모두 제공합니다. 둘 다 한 번에 설치하면 " locate"가 실행됩니다 mlocate.
Oracle은 2014 년 12 월에 릴리스 된 11.2 이후mlocate Solaris 에서 출하되었습니다 . 이전에는 Solaris에 기본적으로 설치되지 않았습니다. (아마, 이것은와 솔라리스 '명령 호환성 줄이기 위해 이루어졌다 오라클 리눅스 되고, Red Hat Enterprise Linux를 기반으로 도 사용합니다 .)locatemlocate
IBM AIX는 여전히 모든 버전을 제공하지 않습니다 locate, 적어도 AIX 7.2로 당신은 GNU를 설치하지 않는 findutils으로부터 Linux 응용 프로그램 용 AIX 도구 상자 .
HP-UX는 또한 나타납니다 부족한 locate기본 시스템에.
오래된 "실제"유닉스는 일반적으로의 구현을 포함하지 않았습니다 locate.
find(1)많은 함수, 부울 연산자 등 을 포함한 강력한 표현식 구문이 있습니다 .
find(1)단순한 이름 이상의 파일을 선택할 수 있습니다. 다음을 통해 선택할 수 있습니다.
이름으로 파일을 찾을 때 정규 표현식을 사용하여 모든 버전의 , 또는 GNU 또는 BSD 버전에서 파일 글 로빙 구문 을 사용하여 검색 할 수 있습니다 .find(1)
현재 버전은 locate(1)glob 패턴 을 허용 find하지만 BSD locate는 정규 표현식을 전혀 사용하지 않습니다. 나와 같고 다양한 머신 유형을 사용해야하는 경우 또는에 grep대한 의존성을 개발하는 것보다 필터링을 선호 합니다 .-r--regex
locatefind때문에 보다 더 강력한 필터링이 필요합니다 ...
find(1)반드시 전체 파일 시스템을 검색 할 필요는 없습니다. 일반적으로 서브 디렉토리, 조작하려는 모든 파일이 들어있는 상위 디렉토리를 가리 킵니다. locate(1)구현 의 일반적인 동작은 패턴과 일치하는 모든 파일을 분출하여 grep필터링으로 남겨두고 분화를 크기로 줄입니다.
(악보 : locate /시스템의 모든 파일 목록을 얻을 수 있습니다!)
사용자 권한에 따라 출력을 제한 하는 locate(1)것과 유사한 변형 slocate(1)이 있지만 이는 locate주요 운영 체제 의 기본 버전이 아닙니다 .
find(1)찾은 파일뿐만 아니라 찾은 파일에 대한 작업도 수행 할 수 있습니다. 가장 강력하고 널리 지원되는 연산자는입니다 -exec. 그러나 다른 연산자 도 있습니다. 최근 GNU와 BSD에서 구현을 찾으면 예를 들어 -deleteand -execdir연산자가 있습니다.
find(1) 실시간으로 실행되므로 출력이 항상 최신 상태입니다.
locate(1)과거 몇 시간 또는 며칠 동안 업데이트 된 데이터베이스에 의존 하기 때문에 출력이 오래 될 수 있습니다. (이것은 오래된 캐시 문제 입니다.)이 동전에는 양면이 있습니다 :
locate 더 이상 존재하지 않는 파일의 이름을 지정할 수 있습니다.
GNU locate및 mlocate이 -e각이 과거에 발견 된 파일의 이름을 인쇄하기 전에 파일의 존재를 확인하게하는 플래그를, 그러나 이것은 일부 멀리 먹는 locate속도를 이용하고, BSD에서 사용할 수 없습니다 locate게다가.
locate 마지막 데이터베이스 업데이트 이후 작성된 파일의 이름을 지정하지 못합니다.
locate출력 이 다소 불신 할 수 있다는 것을 알고, 출력이 잘못되었을 수도 있습니다.
이 문제를 해결할 수있는 방법이 있지만 널리 사용되는 구현 방법을 모릅니다. 예를 들어,이 rlocate있지만 최신 Linux 커널에서는 작동하지 않는 것 같습니다 .
find(1) 사용자를 실행하는 것보다 더 이상의 권한이 없습니다.
locate시스템의 모든 사용자에게 글로벌 서비스를 제공 하기 때문에 전체 파일 시스템을 볼 수 있도록 updatedb프로세스를 실행 하려고합니다 root. 이로 인해 보안 문제가 선택됩니다.
updatedb루트로 실행 하지만 출력 파일을 읽을 수있게 만들어 locate특별한 권한없이 실행할 수 있습니다. 이렇게하면 시스템의 모든 파일 이름이 모든 사용자에게 효과적으로 노출됩니다. 이는 실제 문제를 야기하기에 충분한 보안 위반 일 수 있습니다.
BSD locate는 Mac OS X 및 FreeBSD에서 이러한 방식으로 구성됩니다.
로만 읽을 수있는 데이터베이스를 작성하고 데이터베이스를 읽을 수 root있도록 locate setuid루트를 만드 십시오. 즉 locate, OS의 권한 시스템을 효과적으로 다시 구현해야 일반적으로 볼 수없는 파일이 표시되지 않습니다. 또한 시스템 의 공격 영역 을 증가시켜 특히 루트 에스컬레이션 공격의 위험이 있습니다.
locate데이터베이스 파일을 소유 할 특별한 " "사용자 또는 그룹을 작성 하고 데이터베이스 를 읽을 수 있도록 해당 사용자 / 그룹에 대해 locate바이너리를 표시하십시오 setuid/setgid. 이것은 권한 상승 공격 자체를 막지는 않지만, 발생할 수있는 피해를 크게 완화시킵니다.
mlocate이 방법은 Red Hat Enterprise Linux 에서 구성 됩니다.
디버거를 사용 locate하거나 코어 를 덤프 하면 데이터베이스의 권한있는 부분을 얻을 수 있기 때문에 여전히 문제 가 있습니다.
locate시스템의 각 사용자에 대해 별도의 명령을 실행 하지 않고 진정한 "안전한" 명령 을 생성하는 방법을 찾지 못했습니다 find(1).
결론은 둘 다 매우 유용합니다. locate(1)이름으로 특정 파일을 찾으려고 할 때 더 좋습니다. 존재하는 파일이지만 정확히 어디에 있는지 기억하지 못합니다. find(1)검사 할 영역이 집중되어 있거나 많은 장점이 필요할 때 더 좋습니다.
find -- "$dir" (강력하지 $dir, 술어에 대해 수행 할 수있다) 나를 위해 ... 심볼릭 링크, 경쟁 조건 문제의 속성을 테스트 할 수있는 방법 find과 locate서로 다른 두 가지 문제를 해결합니다. find를 사용하는 것이 현실적이지 않은 곳이 많이 있습니다 (예 : 수백만 개의 파일을 포함하는 디렉토리). locate는 파일 이름으로 제한된 색인 시스템입니다.
locate은 대략 다음과 같았습니다 find / -type f | gzip > locate.gz.zgrep "$1" <locate.gz
locate은 다음과 같습니다. GNU 는 findutils패키지에 포함되어 있으며 그 updatedb프로그램은의 측면에서 구현됩니다 find(1). 그런 의미에서 locate(1)실제로 는을 요구합니다 find(1) . :)
find에는 locate, 등 이 없기 때문에 다른 섹션에서 사용되는 동일한 이름을 명확히 할 필요는 없습니다. 컨벤션에 사용 된 매뉴얼 (예 : unlink(1)vs unlink(2))은 매뉴얼 페이지 참조로 사용됩니다.
find매뉴얼 페이지를주의 깊게 읽지 않고 초보자 또는 가끔 유닉스 사용자가 성공적으로 사용할 수 없습니다. 역사적으로 일부 버전은 옵션을 find기본 설정하지 않았기 때문에 -print사용자의 적대감을 더했습니다.
locate 유연성은 떨어지지 만 일반적인 경우에는 훨씬 직관적입니다.
find . -name 'nametosearch'또는 -iname대소 문자를 구분하지 않습니다. 교체 .현재 디렉토리 이외의 검색 디렉토리 경로. 거기에서 파일 글 로빙을하지 않고도 초보 사용자 요구 사항의 90 %가 적용됩니다. (나는 일반적으로 사용하는 것이 find . -iname '*partialfilename*'내가에서 찾고 있어요 경우 /, 내가 사용하는 find / -maxdepth 5 -iname '*partialname*'I가, 중급 사용자 요구 사항의 75 % 시간의 90 %에 관심이있는 모든 찾는 동안 검색 시간을 절감한다..) :
찾기의 약간의 단점은 관심있는 파일 시스템의 영역을 색인화하지 않을 수 있다는 것입니다. Linux Mint 17.2와 같은 데비안 데스크탑 시스템에서 /etc/updatedb.conf 파일은 특정 영역을 고려에서 제외하도록 구성됩니다. / tmp, / var / spool 및 /home/.ecryptfs를 포함하여
/home/.ecryptfs를 무시하면 암호화 된 디렉토리의 파일 이름이 권한이없는 사용자에게 노출되지 않습니다. 그러나 홈 디렉토리가 ecryptfs로 암호화 된 경우 홈 디렉토리가 색인화되지 않았으므로 찾기는 홈 디렉토리에서 아무것도 찾지 않습니다. 이것은 당신에게 크게 쓸모 없게 만들 수 있습니다 (나에게 도움이됩니다). 업데이트 된 프로세스는 결과를 찾을 수 없을뿐만 아니라 정기적으로 디스크를로드하여 아무런 이점이 없으며 시스템의 주 사용자이거나 유일한 사용자 인 경우 비활성화 될 수 있습니다.