pss
pss copied to clipboard
Search from `.robot` and `.resource` files by default
I've been using pss for years mostly when developing Robot Framework. It would be convenient if our custom extensions .robot
and .resource
were recognized by pss automatically. If you consider this ok, I'm happy to provide a PR.
To be honest, I'm not sure about this. In the limit, there are probably thousands of extensions a tool could support built-in, but adding more also adds cognitive burden to all users, in a way.
Working around such limitations is typically pretty simple with shell aliases e.g. with the --include-pattern
option. I have several shell aliases for pss myself that do various things I like by default, and I see this as a perfectly acceptable usage scenario.
Oh I was just digging in issues history and found https://github.com/eliben/pss/issues/23 :-)
I agree there are lot of other file file types that could be supported and it's hard to draw a line somewhere.
Personally I'd say it would be best if pss would search all text files by default. IIRC, this wasn't done initially because detecting is a file text if binary can be a bit slow. Is that a valid concern nowadays? If it is, could there be a list of files that aren't searched by default (.jpg, .out, .exe, ...) instead of a list of files that are?
Alternatively, simply searching from all files by default could be fine as well. It's unlikely that's so slow or that there would be too many false positives.
Fat fingers accidentally pressed close in this small screen...
I had forgotten about #23. Easier way to limit searching to one extension still sounds good to me. I often use --py
which basically works that way.
This would actually be a pretty convenient default workflow:
# 1. Search from all (text) files by default:
pss xyz
# 2. Limit searching if there are too many matches:
pss xyz some/dir # Limit by path. Works already now.
pss xyz -Eext # Limit by extension `ext`.
pss
is old and very stable by now; it's not likely that I'm going to change the way it works fundamentally, changing defaults etc.
I still think that the "custom add extension" functionality discussed in #23 is the way to go, and happy to accept PRs that implement that.
Searching from all (text) files could cause would require an easy opt-out and a major version change. I understand if you consider that too much work. It's easy to alias pss
for pss -a
as well.
I fail to see how adding custom extensions would be better than using -E ext
when needed. I pretty often use pss --py
to limit searching and similar functionality with all file types would be convenient.
Ultimately -E
doesn't cover all uses cases, because pss
doesn't only search by extension. In many cases, it searches by filename pattern like in --docker
, --cmake
, --gomod
and several others. Singling out just extensions for -E
doesn't feel right to me, so I think a regex would be unavoidable.
Let's say we extend the -E
idea to take a full regexp/pattern; ignoring the fact that it's a bit more verbose for a moment - is it worth it instead of pss -aG
? That could be, because it composes better; say you want to search "Python and Robot" files -- doing this with -aG
may be somewhat cumbersome (unless I'm missing something obvious).
As for -E
(with a full regexp/pattern) vs. config options, I'm willing to accept that by this time maybe config options are an overkill for pss since no one really needs them and -E
can be sufficient.
I have many times to need to limit search in to certain file type, because it will limit the found results. Example repository might have mixed code from different languages, but not all those file extension are supported by pss
(like with pss --py
). So if I do pss xyz
there is just too many results found and it is not useful. But I know that data is in files having .abc
extension, so currently typing pss -iaG ".*\.abc" xyz
is actually quite lot of typing to do. Therefore having simple pss -E abc xyz
would be really handy for my use case.
What ever you decide to do, I am an happy user for the pss
tool and it is certainly better than using find/xargs/grep combo.