[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: L A Walsh
Subject: Re: RFE: allowing "" as a path specification for 'current dir' w/o prepending './' ?
Date: Tue, 28 Feb 2017 11:57:20 -0800
User-agent: Thunderbird

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
 PathCat.pm ./ foo
 PathCat.pm . foo
 PathCat.pm ./. foo
 PathCat.pm /// foo bar
 PathCat.pm // foo // bar
 PathCat.pm /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*

reply via email to

[Prev in Thread] Current Thread [Next in Thread]