mattn / files Goto Github PK

Fast file find

Go 81.53% Makefile 18.47%

files's Introduction

files

Find files

Usage

$ files

Requirements

golang

Installation

go get github.com/mattn/files

Tips

ctrlp.vim

let g:ctrlp_user_command = 'files -a %s'

License

MIT

Author

Yasuhiro Matsumoto (a.k.a mattn)

files's People

Contributors

Stargazers

Watchers

Forkers

kamichidu hoffoo takumakei cho45 aramhakobyan dear iggysly pocari songmu hokorobi alxerg zhixingchou ichizok ur4ltz

files's Issues

How can I ignore some files or folders?

eg: out/, libs/, GPATH...

不必要な関数っぽい

files.goで
これらがmain()で使われてないので、消したほうがいいのでは......

var printLine = fmt.Println

var printPath = func(path string) {
    p, err := filepath.Abs(path)
    if err == nil {
        path = p
    }
    printLine(path)
}

取得するファイル数の最大値を指定するオプションが欲しい

filesを使用するように設定したctrlpで、windowsのユーザディレクトリにて起動すると、ファイル数が膨大なため処理が終わりません。
そのため、取得するファイル数を制限するオプションが欲しいです。

ディレクトリのみの抽出

files という名前だけにあえて入れていないのかもしれませんが、ディレクトリのみ抽出するオプションを追加することはできますか？？

手元では、
https://github.com/mattn/files/compare/master...pocari:add-directory-only-option?expand=1
としてとりあえず使っています。

大量のファイルがあるディレクトリで Asynchronized find すると結果がおかしい？

大量のファイルがあるディレクトリで Asynchronized find オプションをつけて実行したところ、結果を wc -l した数値が実行するたびに違いました。

$ files -a ./ | wc -l
  301490

$ files -a ./ | wc -l
  301490

$ files -a ./ | wc -l
  301490

$ files -a -A ./ | wc -l
  266893

$ files -a -A ./ | wc -l
  264223

$ files -a -A ./ | wc -l
  255086

まだこれだけの情報しかないですが報告します。
数万ファイル程度では何度 -A 付きで実行しても上記のようなズレが発生することはなかったです。

macOS 10.12.1

$ file `which files`
/Users/hirofumiwakasugi/.go/bin/files: Mach-O 64-bit executable x86_64

$  go version
go version go1.7.3 darwin/amd64

CtrlPで使用した時にountが大量発生

適当にstderrをnulにリダイレクトするbatをでっち上げて、それを経由すると以下は発生しなかったので
間違いなくfilesではなくCtrlPかVim側だと思うのですがどちらか分からなかったので

" ファイル数が1000を超える適当なフォルダで
:let g:ctrlp_user_command = 'files -a -A -M 1000 %s'
:CtrlPClearCache
:CtrlP

ountって行がcacheの末尾付近にいっぱい
(stderrに出力されてるOverflow max count？)

Windows10(x64)
Vim 7.4.1944+kaoriya(x64)
go 1.6.2 windows/amd64

The default for `-i` seems to be wrong?

-i が，おそらく与えられた表現にマッチしたところでその下を掘るのをやめる，のではなく，ファイルのパス全体についてマッチすればスキップするような挙動になっているように見えます．その結果，-i に渡されるデフォルトのオプションが間違っているような気がします．普段は -H が効いているので無視できているように見えるが，実際には files -i "^\\.git"$ では ./.git/HEAD などは無視されません．環境は Linux (Manjaro 20.0.3) で，files は最新版です．

こういう状況で

~/tmp $ git init foo
Initialized empty Git repository in ~/tmp/foo/.git/

~/tmp $ cd foo/
~/tmp/foo $ touch .hg
~/tmp/foo $ mkdir .git_janai
~/tmp/foo $ touch .git_janai/something.txt
~/tmp/foo $ touch README

~/tmp/foo $ ls -al
total 16
drwxr-xr-x 4 user user 4096 Aug  2 19:30 .
drwxr-xr-x 3 user user 4096 Aug  2 19:29 ..
drwxr-xr-x 7 user user 4096 Aug  2 19:29 .git
drwxr-xr-x 2 user user 4096 Aug  2 19:30 .git_janai
-rw-r--r-- 1 user user    0 Aug  2 19:30 .hg
-rw-r--r-- 1 user user    0 Aug  2 19:30 README

このような挙動になります

~/tmp/foo $ files .
README

~/tmp/foo $ files -H=false # .git/ 下のファイルが入る．（あと .hg はファイルだが入らない：こちらは想定内）．
README
.git_janai/something.txt
.git/HEAD
.git/config
.git/description
.git/hooks/commit-msg.sample
[省略...]

試してみたところ，v0.0.4 以降でこのような挙動になっているようです．

~/tmp/foo $ ~/src/files_mattn/main -H=false -i  "^(\\.git|\\.hg|\\.svn|_darcs|\\.bzr)$" . # v0.0.3
.git_janai/something.txt
README

状況の把握に

現在のバージョンでも，手元では例えばこうするとそれらしい挙動になりはします

~/tmp/foo $ files -H=false  -i "^(\\.git|\\.hg)/" 
.hg
README
.git_janai/something.txt

状況の把握に自信がないのですがとりあえずご報告させてください．