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

[L A Walsh]

Dale R. Worley wrote:
> 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 /'.
>   
---
   I find this the most compelling reason for the current behavior.
To be clear, though, I wasn't suggesting a change in the current
working-case behavior, but repurposing a user specifically starting
from a zero-len path ("" or '') as allowing output without the
prepended "./" since there is no other way to get that behavior,
*easily*, in the minimal, interactive case.



James Youngman wrote:
> I believe you're saying that the shortest form, "find" by itself, is 
> the one used most often and the form intended for use by humans.   
>
> I agree.   Perhaps you've assumed that I was saying that "find 
> -printf" is the only form intended to produce output for humans, but 
> that's not what I was saying.
---
   Thank you for clarifying, since the most common form I use for
interactive use is without using printf.  FWIW, I most often use
printf output to feed into another program or script, as it
will allow specifying exactly what the next prog/script will
find optimal.


> "./" is part of the output, though, not the input from the user.
---
   Right.  To me, I find the addition of "./" -- for interactive
use, to be *Visual Clutter*.  I was hoping for a simple 'short-cut'
for interactive use to get rid of the visual clutter that I
find distracting enough to usually remove before propagating
such paths.

I really hate seeing paths like "/usr/bin/.//prog" -- UG!
So much so, that I have a perl module that tries to tidy up
a path as it concatenates elements for a path:

>  PathCat.pm foo
foo
>  PathCat.pm ./ foo
foo
>  PathCat.pm . foo
./foo
>  PathCat.pm ./. foo
./foo
>  PathCat.pm /// foo bar
/foo/bar
>  PathCat.pm // foo // bar
//foo/bar
>  PathCat.pm /usr /bin/ ./ /prog
/usr/bin/prog

---
Note that occurrences of "./" end up being consistently
removed, but a lone "." is taken as a non-redundant
path component.  Some of us are more disturbed by
extraneous visual clutter than others -- and myself,
not always so.  But when I am, it stands out like a
highlighted string.  *sigh*