Re: RFE: allowing "" as a path specification for 'current dir' w/o prepending './' ?

[Dale R. Worley]

L A Walsh <address@hidden> 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