bug/feature: option to not index files with the "executable" bit set
Ben Longbons
extension the way they do on Windows. As a result, after the program
is built, that file shows up in the open dialog, possibly as the first
file.
A blanket exclusion of all executable files would cause problems for
executable scripts, as the user may wish to edit them. It would
probably be too intrusive to open the file and check for a shebang.
However, if the exclusion was applied only to files without
extensions, the user could have a policy to always use an extension on
scripts.
This should be opt-in, per-project, in case some workspaces are from a
filesystem that mounts with all files set executable (vfat by default
in Ubuntu, this can be disabled).
Elliott Hughes
does it really cause enough trouble to be worth an extra mechanism
(and the manual configuration needed to use it)?
Find in Files should already ignore matching binary files, though its
definition of binary might not agree with yours --- adding checks for
valid ELF, mach-o, and <whatever Windows uses> headers to the current
"are there any 0 bytes in the first n KiB?" might be a good idea,
assuming it's possible for those three important classes to fail the
existing check.
Open Quickly doesn't do anything clever, but we could easily make it
do so. (an "are you sure?" like less(1) might be a better idea than an
outright refusal. the dialog could even say what file(1) thinks you're
about to open.)
i've always really wanted to hand this decision over to whatever
version control system the user's using. yeah, it falls apart a bit if
you're checking in prebuilt binaries or specific .jar files or
whatever, but at least in terms of real not-to-be-checked-in "litter",
it would be nice if we automatically did the right thing.
the best we have at the moment is that you can put scripts on your
path that tell us directory names to "prune" at when indexing. my only
problem with that is the bizarre interface, not the style it
encourages: i think "keep all your generated stuff separate from your
source, preferably in a directory whose name is otherwise unique" is
an excellent idea for all projects.
--elliott
Martin Dorey
(If there were any further emails in this thread, they were off-list and so I haven't seen them.)
>> A blanket exclusion of all executable files would cause problems for
>> executable scripts, as the user may wish to edit them.
Yes, very much so.
>> filesystem that mounts with all files set executable (vfat by default
>> in Ubuntu, this can be disabled).
Good, non-obvious, point. Between this and the first point, you've pretty much convinced me that your idea won't fly, but top marks for being upfront about the downsides.
>> probably be too intrusive to open the file and check for a shebang.
(Not necessarily. Oddly, perhaps, we already have code to do this. That's currently only used on Cygwin but I hope it'd work wherever.)
> Find in Files should already ignore matching binary files
The poor performance of searching big files was one of the reasons that we added the mechanisms for excluding files from the index (and reorganized small parts of the BlueArc source tree to take best advantage).
> the best we have at the moment is that you can put scripts on your
> path that tell us directory names to "prune" at when indexing.
There's also echo-local-extensions-evergreen-should-not-index. "Extension" here includes the ".", so you could use the whole file name-within-its-directory for troublesome executables with no "." in the name. I don't think it would hurt for us to compare that list with the complete path, rather than just the last component of it, if, say, you have a situation where "make" is sometimes a binary and sometimes source. I doubt we'd need to do that because that example doesn't seem realistic and, while I can imagine a directory called "make" that should be indexed, I see that we ignore that list for directories. If that's not flexible enough, though, I'd be happy to rework and rename BlueArc's local version of that to produce patterns which, when they match more of the filename (say the path from the workspace root), exclude a file from indexing.
> keep all your generated stuff separate from your source
Yeah, and it's not just us that think that way. The autotools stuff lets you do eg ../source/configure.