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

[Eric Blake]

On 03/02/2017 04:24 PM, L A Walsh wrote:

>> Please, do NOT make the behavior depend on an environment variable.

>    Please do not make blanket statements: A foolish consistency is
> the Hobgoblin of small minds.", and please don't come into the
> middle of a discussion without reading the previous conversation:

Please don't assume that I haven't been following the conversation.

> 
>> >   ... 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 ...

And I find the exact opposite - lack of ./ is visual clutter, because
with a leading ./, I am guaranteed that it resolves to a filename, but
without a leading ./, a file name that starts with '-' (for example) is
indistinguishable from what would normally be a command-line option.  In
other words, I think that always outputting ./ by default is a GOOD
thing, and that if you want to strip it, you should put in extra effort
(whether that be post-processing, or a new option that strips it by
default, is irrelevant, as long as it is something that you can request
to change what is otherwise the default).  And since I've now stated
clearly that I'm okay with a way to change the default, I'm also
reiterating that such a change SHOULD be done via a command-line option,
and NOT via an environment variable.

> 
>    This is not about a POSIX specified feature (it's undefined), and
> is not about something that would normally be used with scripts, so
> your argument doesn't seem applicable.

On the contrary, my argument IS applicable - the mere fact that it is
NOT specified by POSIX what 'find' should do is all the more reason that
the default behavior should be as unambiguous as possible, and therefore
should include leading './' the same way that 'find .' does (it also
helps that we've consistently documented that 'find' behaves the same as
'find .', and I don't want to break that consistency - and it is for the
same reason that 'ls' and 'ls .' have the same output that 'find' and
'find .' should have the same output).  If a mere environment variable
is enough to change things, then that does risk breaking scripts, even
if such scripts are already relying non-POSIX extensions.  So GNU
programs in general should NOT use new environment variables to change
default behavior.

> 
>    This topic is about a default, interactive behavior.  Not only
> does that not apply to scripts, but, by definition, precludes use
> of command-line options.

Ah, but that's where you're missing the point.  Changing interactive
behavior does NOT require that you are forced to always type the new
command-line option, because you are free to set up a wrapper function,
alias, or script on $PATH, which will supply that option on your behalf
for all your interactive use, without penalizing the default for
everyone else.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature