Home » 파일 탐색 유틸리티 fd 사용법

파일 탐색 유틸리티 fd 사용법

이 블로그에서 GNU find의 사용법에 대한 글을 올린 적이 있는데, 오늘은 이 GNU find를 대체할 수 있는 fd 라는 툴의 사용법에 대해서 간단히 정리해보고자 한다. fd는 이름부터 ‘find’를 50%줄여서 더 빠르게 쓴다는 취지로 개발되었으나, GNU find를 ‘완전히’ 대체하는 것을 목표로 하지는 않는다. 대신에 옵션명을 보다 직관적으로 현대화(?)하고 더 빠르게 동작할 수 있는데 중점을 두고 개발되었다. 개발자에 따르면 find 유틸이 제공하는 전체 기능의 80% 정도를 커버할 수 있으며, 성능은 대략 9배이상 빠른 것으로 본다고 한다. 무엇보다 윈도환경에서 사용이 가능하다. (msys 같은 환경을 설치하면 gnu-find도 윈도용을 사용할 수 있다.)

참고로 find나 grep은 모두 쉘에서 가장 많이 쓰이는 명령 중 하나인데, grep은 이를 완전히 대체하거나(ripgrep) 약간의 사용법 변경을 두고 성능과 편의성을 확장하려는 시도들(silver searcher, platinum seacher, sift 등)이 있었음에 비해 find를 대체하려는 프로젝트는 찾기가 쉽지 않았다. (게다가 ‘find’ 자체가 너무 일반적인 단어라 구글링해도 딱 원하는 결과를 찾기가 어려움…)

fd는 scoop을 사용해서 설치할 수 있다.

> scoop install fd

fd의 특징

그럼 일단 fd의 장점은 어떤 것들이 있는지 간략히 소개해보면…

  1. 기본적으로 파일명 부분에 대해서만 패턴을 매치하며, 패턴은 정규식으로 해석된다.
  2. 숨은 파일을 무시한다. 그외에 .gitignore 파일에 정의된 패턴들도 모두 무시한다.
  3. 대소문자를 구분하지 않지만, 패턴에 대문자가 포함되면 대소문자를 구분한다. (스마트 케이스)
  4. 기본적으로 출력 결과에 색을 적용해준다.
  5. 멀티스레드/멀티코어를 활용해서 탐색 속도를 높이며, 배치 명령을 더 빠르게 수행한다.
  6. 사이즈, 기간 등의 조건을 좀 더 사용자 친화적인 단위로 지정할 수 있다.

일단 gnu find가 워낙 오래된 툴이라 정규식 처리가 좀 느린 편이고, 일반적으로 무시해도 좋을 디렉토리를 알아보지 못하는 등 사용성이 좀 떨어지는데, fd에서는 이런 부분들을 많이 개선했다. 다만 연산자 옵션이 없기 때문에, find로 할 수 있는 모든 일을 할 수는 없다. 이 부분을 개발자는 20%라고 보는 것 같은데, 사실 연산자를 사용해서 액션을 조합하여 할 수 있는 일의 범위는 매우 커질 수 있기 때문에(find 글에서의 몇몇 예제는 fd로 할 수 없다) 실질적으로는 80% 커버리지를 갖는 것은 아닐 듯 하다.

fd는 플래그/옵션과 패턴 그리고 시작 경로를 주어서 검색한다. 아무런 필터가 주어지지 않으면 현재 위치에서 모든 하위 파일을 검색하여 출력한다.

fd [FLAGS/OPTIONS] [PATTERN] [PATH]

모든 플래그/옵션은 선택적이며, 패턴은 생략하는 경우 모든 파일을 검색한다. 패스는 생략되는 경우에 현재 위치를 기준으로 삼는다. 따라서 그냥 fd 라고 실행하면 현재 디렉토리 아래에 있는 모든 파일을 검색하여 출력한다. 단, 기본적으로는 숨겨진 파일이나 디렉토리는 검색하지 않으며, VCS에서 사용하는 .gitignore, .ignore 등의 파일을 읽어서 해당 패턴에 대한 파일 역시 검색하지 않으며, .git 과 같은 디렉토리도 검색하지 않는다.

기본 플래그

  • -H, --hidden : 숨겨진 파일들을 검색한다.
  • -I, --no-ignore : .gitignore, .ignore 파일이 기재된 패턴을 무시하지 않고 표시한다.
  • -u, --unrestricted : --no-ignore와 동일하다. 단, -uu로 쓰면 --hidden까지 포함하게 된다.
  • -s, --case-sensitive : 스마트 케이스를 적용하지 않고 대소문자를 구분한다.
  • -i, --ignore-case : 대소문자를 무시한다.
  • -g, --glob : 입력된 패턴을 정규식이 아닌 glob 기반 패턴으로 처리
  • -F, --fixed-string : 입력된 패턴을 확장하지 않고 그대로 처리
  • -a, --absolute-path : 결과 출력 시 절대 경로로 출력
  • -l, --list-details : 상세 정보를 포함하는 정보를 리스팅한다.
  • -L, --follow : 디렉토리에 대한 symlink를 따라간다.
  • -p, --full-path : 파일의 전체 경로에 대해 패턴을 매치한다.
  • -0, --print0 : 각 라인을 개행이 아닌 널 문자로 구분한다. xargs에 인자로 넘기는 경우에 유용하다.
  • --prune : 디렉토리를 만나는 경우 하위로 진입하지 않는다.
  • -1 : 첫 결과를 찾으면 출력하고 중단한다. --max-results=1과 같다.
  • --show-errors : 에러를 출력한다.
  • --one-file-system : 시작위치와 다른 파일시스템으로 된 위치를 따라가지 않는다.
  • -h, --help : 도움말을 출력한다.
  • -V, --version : 버전 정보를 출력한다.

옵션

  • -d, --max-depth <depth> : 탐색하는 최대 깊이를 한정한다.
  • --min-depth <depth> : 탐색하는 최소 깊이를 정한다. 최소 깊이 이내에서 발견된 결과는 무시한다.
  • --exact-depth <depth> : 지정한 깊이에서만 찾는다.
  • -t, --type <filetype> : 특정 파일 타입만 찾는다.
    • f, file
    • d, directory
    • l, symlink
    • x, executable
    • e, empty
    • s, socket
    • p, pipe
  • -e, --extension <ext> : 특정 확장자에 대한 파일만 필터링한다.
  • -x, --exec : 각 결과에 대해서 다음 명령을 실행한다. 명령 내에서 {}부분을 해당 파일 경로로 치환하며, 명령은 ;을 만나는 부분까지로 한정된다.
    • {} : 경로
    • {/} : 베이스 이름
    • {//} : 부모 경로
    • {.} : 파일 확장자를 제외한 이름
    • {/.} : 파일 확장자를 제외한 베이스 이름
  • -E, --exclude <pattern> : 특정 패턴에 매치되는 결과는 제외한다. 이 때 패턴은 glob 패턴이다.
  • --ignore-file <path> : 특정 파일 내에 지정한 파일들을 제외한다. 이 파일의 형식은 .gitignore와 동일
  • -c, --color <when> : 컬러 사용 여부
  • -j, --threads <n> : 스레드 사용 개수
  • -S, --size : 특정 크기의 파일로 제한한다. +, – 로 이상/이하를 표현할 수 있으며, 숫자와 단위를 사용한다. (b, k, m, g, t, ki, mi, gi, ti 가능)
  • --changed-within <date|dur> : 특정 기간 이내에 편집된 파일을 찾는다. (YYYY-MM-DD HH:MM:SS) 형식이나 (10h, 1h, 35min) 등을 쓸 수 있다.
    • –changed-within 2wees
    • –change-newer-than ‘2018-10-27 10:00:00’
  • --changed-before : 특정 시점, 기간보다 이전에 편집된 파일을 찾는다.
  • --max-results <count> : 최대 결과수를 제한한다.

맺음

사실 gnu-find가 워낙 강력한 도구라서 100% 커버리지를 갖는 툴이 나올까는 의문이지만, Rust 쪽에서는 fd외에도 여러 유용하고 (대부분 엄청 빠른!) 명령줄 도구들이 많이 나오고 있는 것 같다. find 자체가 느리다고는 해도 정규식 패턴 매칭 부분에서 성능이 좋지 못할 뿐, 고급 사용자용(?)으로는 아직 이 강력한 툴이 제공하는 기능들을 온전히 대체할 수 있는 대안은 없는 듯 하다. 그러나 엄청나게 많은 파일 중에서 특정한 파일을 찾아야 한다거나, 조금 더 간단히 (대부분의 명령 및 옵션이 더 짧다) 사용하고 싶은 사람에게 fd는 충분히 만족스러운 도구가 될 수 있을 것이다.

0 Comments

No Comment.