bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

[L A Walsh]

On 12/31/2018 4:23 AM, Assaf Gordon wrote:
> Hello,
>
> On 2018-12-31 4:36 a.m., L A Walsh wrote:
> > On 12/20/2018 5:21 PM, Assaf Gordon wrote:
> > > If there was an "rm --depth-first" feature,
> > ---
> >      If you would ensure that this is possible, you would have
> > my gratitude.
>
> There seem to be some confusion: this item was "#2" in my previous
> email, and as I wrote (quoted below), I think find(1) is better
----
You miss the point.  The point is not to increase the length of the command
lines.  The original users of the unix command line used short abbreviated
commands because they were efficient.    

They didn't have one command for listing files, and then require another one
to list properties (stat), and then another to line things up and then another 
to
put things out in a different format.

Basic formatting was included in the basic, most used commands. 

But most of all, short commands led to fewer errors.  Having to type
in 2 or more commands to do what could be done in 8 characters would be
an anathema to early unix designers.  The need to call some other utility
to do something that could be more easily done in 1 creates a whole
can of worms

The suggestions I've made involve making things simpler for users.
It's not about how well you can string different commands
together it's about making this short and concise.

More than one source on computer languages talk about brevity in
a language being inversely proportional to power in a language. 

pain.

It ignore that basic fact is insensitive and masochistic.  I certainly don't
need longer repetitive lines to do the same tying I could do in 3...

The point is how can I do what I mean as concisely as possible.


> suited for these things.
> I have no intention of implementing this functionality.
---
        You said it could be better done in an alias.
I say -- no, it cannot.  I'm not talking about righting extra
code for find nor something lone.  Inherently, aliases are
short.  You imply it it easy by claiming it can be done in an
alias.  If it was easy, it would be easier for you to through
out a one- liner than respond to the last note.

> > > As for #3 - The "expand" program already does tab-expansion.
> > > It can be easily combined with existing programs using
> > > a simple shell function.
----
        The need to call another program to generate
basic consistent output is a sign of dysfunction.



> With the unix philosophy of "each program should do one thing, and do it
> well",
----
        That's not the unix philosophy by itself.  If it was, ls would only
list filenames, and would call stat, expand and table commands to format things.


once one learns how to use "expand" (or fmt, numfmt, awk and
> similar text formatting programs) - they can use them to format output
> from any program - saving lots of time in re-implementing the same 
> functionality in different programs.
---
   You can also put those in libs with the main program calling those libs
based on args using dynamic run-time loading.


> these are all tangents.
> The topic of this thread is adding support for a global configuration
> file.   That request is not likely to be implemented.
----
	One of the main points here was that some of those other 
features were discarded because there was no easy way of providing
a default configuration for how users wanted these things.

        That argument clearly goes in circles.  The hazard of using
it as a reason for not supplying various features is that it becomes necessary
to provide that feature as it is a noted requirement for a score of 
other features.

> To continue discussing other topics or feature requests (e.g.
>   tab-expansion) - please start a new dedicated thread.
----
        Dedicated to what?
Each problem that need a configuration file?  Or a configuration 
facility to provide a ready backdrop to allow for tool extensibility?
It seems they are interrelated.

I seem to remember this statement by you:

"Discussion can continue by replying to this thread."