On Tue, Oct 19, 2010 at 10:28:07AM +0200, Peter Reineke wrote:
>> I have doubts that everyone has /sbin, /lib[64], /usr/lib[64] or
>> /opt/*/bin in $PATH.
>>
>> Please, use the current bindir[] as a template and modify the array
>> according to the $PATH.
>>
>
> What is the rationale here to include that hard-coded binary-paths that
> are not in PATH? Backwards compatibility towards the bug?
Bug? It's feature that whereis(1) does not follow $PATH only. If you
care only about binaries in $PATH then you want use which(1) command.
> I just tried to fix an obvious flaw, but now I am not sure anymore what
> the intended behaviour is.
I think that use directories from $PATH that are missing in the default
whereis(1) list of directories is a good idea. It means:
$ export PATH=/path/foo
$ whereis bar
has to return "bar" from all default (hard-coded) paths as well as
from /path/foo.
>>> + char **dirp = dirs;
>>> + *(dirp++) = buf;
>>> + for(cp=buf;*cp;cp++)
>>> + if (*cp == ':') {
>>> + *cp = 0;
>>> + *(dirp++) = cp + 1;
>>> + }
>>> + dirp = 0;
>>> + return dirs;
>>> +}
>
>>
>> Please, read http://www.kernel.org/doc/Documentation/CodingStyle
>> or follow the current coding style in whereis.c
>
> I am new to kernel coding style, is this about missing braces after the
> for-header.
> I was going with "Do not unnecessarily use braces where a single
> statement will do." there, but you can argue whether a for loop is a
> single statement.
read "3.1 Spaces"
- for(cp=buf;*cp;cp++)
+ for (cp = buf; *cp; cp++)
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
