This problem with this method is that it can create a security vulnerability to be searching paths which do not exist on machines. It's dangerous on production systems in high risk environments (like financial services systems).

So, if anyone in his company (which in the case of this poster, is a major investment bank) purposely or accidentally injects a faux grep in the path, it could easily be exploited and cause problems.

So creating solutions passing a PATH which we know is going to traverse non-existant commands "is a kludge" which is not necessary (because there are better solutions) and adds a security vulnerability for the sake of sticking with a poor implementation. It is better to build simple, secure solutions, not kludges when working on "high risk" systems.

The solution is for the poster to stop using sshpass (as we have told him many times), and user password-less SSH (with shared encryption keys) and to build a secure solution and to STOP kludging things together because......

I think the poster is just lazy to set up the keys on 300 servers, and so because of this "laziness" (for a lack of better word or visibility into his workplace) he is making the company he works for more vulnerable to attackers.

The same is true for trying to come up with a one-liner that works for all systems which traverses the filesystem. It just creates vulnerabilities, unnecessarily.

We cannot condone or support creating vulnerabilities here when we know the poster is creating solutions for his employer, a major financial institution.