L A Walsh <g...@tlinx.org> writes: > What do 'ls' and 'du' do, since in the absence of a path > they start from the current directory but don't seem to > prepend './'. However, I would not want to change how find > operates in the absence of a path -- compatibility problems.
I think these show that the current 'find' behavior is desirable. As you note in a later message, 'du' does take '.' as its default argument, and that shows up in its output. 'ls' also takes '.' as its default argument, and that does not show up in its output, but that's because if you give 'ls' a directory as an argument, it lists the entries in the directory, *without* prepending the directory name. You can see this easily by running 'ls /'. More subtly, it's a general principle that Un*x utilities are front-ends for the kernel calls, they (all, consistently) present the same usage rules that the kernel applies. One particular of this that is quite different from most other operating systems is that very few Un*x utilities apply "default extensions". E.g., if you want to compile foo.c, you have to say "cc foo.c", you can't abbreviate it to "cc foo", because 'cc' is going to take the argument you provide and hand it to open(), and so the argument you provide must be the name of the file as the kernel sees it. Adding this exception to 'find' would make it inconsistent relative to very other utility. 'ls ""' and 'du ""' both fail. Dale
