The finder cannot be a service. Finders are not stateless. You cannot use the same instance to search several times

Fair enough. I added the word factory to my original post.

I had a similar problem, because I'm using GNU find on a Mac (which I have to admit is a bit of a weird edge case). When running composer with symfony I get a lot of errors saying:

find: unknown predicate `-E'

Annoyingly, the error isn't detected in php because the output of find is piped into another command (the return status from exec is taken from the last executable in the pipe).

It'd be good enough just to have a way to force it to use the pure php implementation.

Is there a hook somewhere in S2.2 to allow setting the PhpAdapter?

This is actually quite puzzling. The finder component does not work on many operating systems out of the box. You would think it would be better to default to the safe implementation and then allow the user the option to use a faster one if available.

Imagine a new S2 developer bringing down S2 and getting this strange error. I suspect they would look elsewhere for their framework. And if they did investigate then they would realize they need to hack a core component just to get started. Not an ideal introduction to Symfony.

@ahundiak Please read my comment just above to see how to force using the PhpAdapter

The problem is that the Finder is created and used in code that we don't have control over (i.e. Symfony itself). So we can't run the code you use. We need to force it to use PhpAdapter everywhere, not just in our own code.

One means might be a configuration mechanism. Now I suppose this is tricky for anything that's run from the composer install, since that happens before there is a chance to make configuration changes (unless there's a global config?) so it might be best if the Symfony installation code always does that. And then the configuration checker could perhaps try calling find to see if it works (without any piped output).

It would be better if such things worked without configuration, but I appreciate that can be tricky. As the original poster said, the best thing to do is to test the find itself. But annoyingly, find doesn't offer an easy way to do that (there's nothing along the lines of 'find --version'). So such a solution is liable to be either fragile or expensive.

Anyway, I'm new to Symfony, so I don't know exactly what is feasible.

@ahundiak your idea of a finder factory as service sounds good for me.

It could permit to:

• store adapters cache in application cache
• have only PhpAdapter by default and add a better one by configuration

The second point seems required because of the many problems encountered on specific plateforms and the difficulty to guess which shell commands/options are available.

What do you guys think of this?
@fabpot do you think this could cause issues?

@ahundiak the PR #7212 will set the php as default adapter.
Would you like to work on a sun_solaris adapter?

While I am not opposed to the idea I'm not sure it's worth the investment. My Solaris workstations run fine with the default php adapter. Actual production servers might benefit but how many solaris servers are really out there? Now that 2.2 is released if anyone else has problems with solaris then I'll step in.

One thing to keep in mind is that you can load gnu find on solaris and end up with a gfind command which will not interfere with he existing solaris find command. So there should also be a way to configure the name of the find command in which case the existing gnu find based adapter works great.

Closing as a workaround has been found now.