Bug #105601 for IPC-Cmd: current directory always searched, even if not in $PATH

Wed Jul 01 17:18:18 2015 ether [...] cpan.org - Ticket created

CC:	PLICEASE [...] cpan.org
Subject:	current directory always searched, even if not in $PATH

I found this in the documentation for File::Which. It doesn't seem to have been reported, so I report it here: =head1 SEE ALSO =over 4 =item L<IPC::Cmd> Comes with a C<can_run> function with slightly different semantics that the traditional UNIX where. It will find executables in the current directory, even though the current directory is not searched for by default on Unix.

Sat Jul 04 15:12:53 2015 PLICEASE [...] cpan.org - Correspondence added

On Wed Jul 01 17:18:18 2015, ETHER wrote: Show quoted text

> I found this in the documentation for File::Which. It doesn't seem to > have been reported, so I report it here: > > =head1 SEE ALSO > > =over 4 > > =item L<IPC::Cmd> > > Comes with a C<can_run> function with slightly different semantics > that > the traditional UNIX where. It will find executables in the current > directory, even though the current directory is not searched for by > default on Unix.

Just to clarify I am not sure this is a bug (which is why I didn't report it), but simply the result of a different goals. Consider: twin% ls -l a.out -rwxr-xr-x 1 ollisg ollisg 7052 Mar 19 06:58 a.out* twin% which a.out a.out: Command not found. twin% perl -MIPC::Cmd -E 'say IPC::Cmd::can_run("a.out")' ./a.out "./a.out" is a valid way to execute the a.out in the current directory, even if . isn't in the path. It may even be useful depending on the application and the expectation. Either way, I will monitor this ticket and if it is deemed a bug and corrected I will update the doco on File::Which.

Sat Jul 04 15:12:54 2015 The RT System itself - Status changed from 'new' to 'open'

Sat Jul 04 15:21:56 2015 ether [...] cpan.org - Correspondence added

RT-Send-CC:

PLICEASE [...] cpan.org

On 2015-07-04 12:12:53, PLICEASE wrote: Show quoted text

> twin% perl -MIPC::Cmd -E 'say IPC::Cmd::can_run("a.out")' > ./a.out > > "./a.out" is a valid way to execute the a.out in the current > directory, even if . isn't in the path. It may even be useful > depending on the application and the expectation.

I wonder if it would be reasonable for can_run("a.out") to return false, but can_run("./a.out") to return true? That is, only check the exact semantics that were passed to the function, rather than going "I think you mean ./out, so I will prepend that to the path".

Fri May 12 12:09:36 2017 BINGOS [...] cpan.org - Correspondence added 40 min

I have made can_run() only add curdir to the search if it is on Win32, which is in keeping with how Windows itself finds 'executables'. Many thanks.

Fri May 12 12:09:37 2017 BINGOS [...] cpan.org - Status changed from 'open' to 'resolved'

Fri May 12 12:09:37 2017 BINGOS [...] cpan.org - Taken