GNU bug report logs -
#33787
Policy Change: Use of /etc/gnu.conf files to configure default system behavior
Previous Next
Reported by: L A Walsh <coreutils <at> tlinx.org>
Date: Tue, 18 Dec 2018 07:14:02 UTC
Severity: wishlist
Tags: wontfix
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33787 in the body.
You can then email your comments to 33787 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Tue, 18 Dec 2018 07:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
L A Walsh <coreutils <at> tlinx.org>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Tue, 18 Dec 2018 07:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Over the past few years I have has for the ability to set
defaults for my system regarding various behaviors in
coreutil programs. Some of the these behaviors have been
regulated via ENV vars in the past, but I was told that this
was not desirable as gnu was trying to get away from using
ENV vars to regulate a person's util behavior in their
environment. I suggested using a config file in /etc
as an alternative and was told "no way".
However, now I find that /etc/xattr.conf is being used to
regulate behavior in gnu tools.
Given the acceptance of such config files I would like
see a single file /etc/gnu.conf hold configs for any gnu
tool.
In it should be options for configuration by function
and tool, with tool-specific options overriding
function-specific options. An additional selector
should be if the behavior is configured for "interactive"
use vs. "script" use.
Now I suspect that people will want these options to be
configurable by user and not just at a system level -- so
ideally, there would be a '~/.gnurc' file for user overrides.
Examples of configurable items:
Default quoting and sorting
Default TAB expansion (both tab column and expansion to space)
Default aliases for existing long options.
Default algorithm usage (if using depth-first processing,
no pre-processing of names in non-depth-first order).
Default addition of optional path elements ("find" processing)
Default per-unit prefixes and their values.
The above should not be taken as a comprehensive list, but
as possible examples of included items.
Maybe I can go back and resubmit several bugs that would benefit
from this new policy?
L Walsh
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Thu, 20 Dec 2018 22:00:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 33787 <at> debbugs.gnu.org (full text, mbox):
On 12/17/18 11:12 PM, L A Walsh wrote:
> I find that /etc/xattr.conf is being used to
> regulate behavior in gnu tools.
Sure, just as lots of other system configuration files do, e.g.,
/etc/passwd. But these files are intended to act globally throughout the
operating system; they're not an exception to the rule that coreutils
itself is supposed to portable.
Coreutils should not behave differently on different hosts merely
because the coreutils installer on one platform prefers behavior A
whereas the installer on another platform prefers behavior B.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Thu, 20 Dec 2018 22:42:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
But coreutils already does act differenty based on what
local libraries it pulls in at runtime. If you want to
ensure they have the same behavior then they'd be statically
linked.
Second, coreutils behaves differently depending on the contents
of xattr.conf -- any util that deals with files will need to have
a look at that.
Third, coreutils behaves differently based on what is installed
with alternate versions of various programs, including coreutils
being configured for use on a system-by-system basis.
On more than one coreutils-including system, I see coreutil
programs replaced with alternate versions like from BSD
because the bsd version was more user friendly.
Coreutils should service the owner of the system.
They should not be like a virus or malware that can change
behavior at the behest of the util-maintainer against what
users want. This has been what is happening.
I'm suggesting a way for coreutils to better serve the users
of these programs. Note -- there is facility for separating
behaviors desired for scripts vs. those desired for interactive
use. It has been my intent that behaviors for scripts could
advise users to accept defaults to provide for script
portability between systems.
But for interactive use, I can make the statement that coreutils
should not go against what users want and have
non-optional/non-configurable changes made to defaults against
their will. That's the behavior of malware.
Foremost, software should be user friendly -- something
many if not most software developers have forgotten. It's
there to service the users. Not to control them and force them
to do things in a way they are not comfortable with or that
causes them unnecessary grief.
Those things said, coreutils apparently is already using xattr.conf
and my proposal is to fold that into a gnu.conf where other
utils can store config ops, or go ahead and provide gnu.conf
even if xattr.conf doesn't want to fold in to allow more
flexibiltiy
At this point, all I'm trying to do is to gather xattr.conf into
one place, 'gnu.conf', so that users can know to pay attention to
it. Notice I'm naming it 'gnu.conf' and not coreutils.conf -- I'm
not intending this to be limited to coreutils.
On 12/20/2018 1:59 PM, Paul Eggert wrote:
> On 12/17/18 11:12 PM, L A Walsh wrote:
>> I find that /etc/xattr.conf is being used to
>> regulate behavior in gnu tools.
>
> Sure, just as lots of other system configuration files do, e.g.,
> /etc/passwd. But these files are intended to act globally throughout the
> operating system; they're not an exception to the rule that coreutils
> itself is supposed to portable.
>
> Coreutils should not behave differently on different hosts merely
> because the coreutils installer on one platform prefers behavior A
> whereas the installer on another platform prefers behavior B.
>
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Thu, 20 Dec 2018 22:59:02 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
On 12/20/18 2:40 PM, L A Walsh wrote:
> But coreutils already does act differenty based on what
> local libraries it pulls in at runtime.
Of course, and that doesn't affect the point. From coreutils viewpoint
those libraries are part of the system configuration, just as
/etc/passwd is, and just as /etc/xattr.conf is.
>
> Coreutils should service the owner of the system.
Of course, and there's already a way to configure them the way you
prefer: put wrapper shell scripts in your PATH. And you can simply
modify the source code to behave the way you like. So you're asking for
yet another way to configure them. We have to balance the advantages of
this feature request against the disadvantages. The disadvantages of
adding a new way to configure coreutils are that it'll slow the programs
down a bit and that it can cause existing usage to go awry. It's not
unreasonable to say that these disadvantages outweigh the minor
advantage of having yet another way to configure them.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Thu, 20 Dec 2018 23:15:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 33787 <at> debbugs.gnu.org (full text, mbox):
tags 33787 wontfix
close 33787
stop
Hello,
On 12/17/18 11:12 PM, L A Walsh wrote:
> I find that /etc/xattr.conf is being used to regulate behavior in gnu
> tools.
It's worth noting that "/etc/xattr.conf" comes from a shared-library
(libattr.so) that is optionally used by cp(1).
It is not part of GNU coreutils per-se, and coreutils developers have
no influence over it.
Similarly, if other shared-libraries decide to introduce their own
global configuration files, it will be picked-up by coreutils' cp
(e.g. libacl, libcap or libsmack).
On 2018-12-20 3:40 p.m., L A Walsh wrote:
> On more than one coreutils-including system, I see coreutil programs
> replaced with alternate versions like from BSD
> because the bsd version was more user friendly.
There are several cases where GNU coreutils' programs are
not the default, and instead other implementation are used
(e.g. "busybox" in Alpine Linux).
I'm less familiar with cases where the BSD implementation is used
to replace coreutils in GNU/Linux systems, but that's certainly
possible.
However, I doubt that is because these other implementation are
more "user friendly". Typically other implementation are used
due to less restrictive license (e.g. BSD vs GPLv3),
or due to perceived "bloat" (i.e. desiring *less* features and
smaller binaries than what GNU coreutils offer).
> Coreutils should service the owner of the system.
> They should not be like a virus or malware that can change
> behavior at the behest of the util-maintainer against what users want.
> This has been what is happening.
I humbly think calling it a "virus or malware" is an exaggeration.
All GNU coreutils program do exactly as you tell them by supplying
command-line arguments. Your request is to add a global configuration
file that would save some typing.
Even without such a config file, it's hardly going "against what users
want".
> Those things said, coreutils apparently is already using xattr.conf
> and my proposal is to fold that into a gnu.conf where other
> utils can store config ops, or go ahead and provide gnu.conf even if
> xattr.conf doesn't want to fold in to allow more flexibiltiy
As mentioned above, "xattr.conf" is not managed or created or
used by coreutils programs per-se (i.e. there is no where in GNU
coreutils' source code a place where xattr.conf is read).
It will not be merged or folded into a hypothetical "gnu.conf"
because these files are targeting different projects (coreutils vs
libattr).
This is just like "/etc/passwd" won't be merged with "/etc/pam.conf"
despite both of them being related to user management - they are from
different projects.
---
The common and recommended way to add default command-line arguments
is to use aliases (e.g. "alias rm='rm -i'").
If used in $HOME/.profile - it will affect your interactive use.
If used in /etc/profile (or similar) - it will affect all users in your
system.
That method already works in almost every Unix system - without adding
additional code and complexities of a global configuration file.
---
> On 12/20/2018 1:59 PM, Paul Eggert wrote:
>>
>> Coreutils should not behave differently on different hosts merely
>> because the coreutils installer on one platform prefers behavior A
>> whereas the installer on another platform prefers behavior B.
>>
Given the above, I'm closing this as "wontfix".
Discussion can continue by replying to this thread.
regards,
- assaf
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Fri, 21 Dec 2018 00:37:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 33787 <at> debbugs.gnu.org (full text, mbox):
The below methods cannot alter or fix the problems that require
a configuration file.
Example: have 'rm -fr .' do a depth first removal and not
pre-inspect any argument before its children.
Whether or not to expand tabs in output so that output to
a terminal that doesn't have tabstops every 8 characters will
line up.
I could go on, but those cannot be handled with a simple alias.
> The common and recommended way to add default command-line arguments
> is to use aliases (e.g. "alias rm='rm -i'").
>
> If used in $HOME/.profile - it will affect your interactive use.
> If used in /etc/profile (or similar) - it will affect all users in your
> system.
>
> That method already works in almost every Unix system - without adding
> additional code and complexities of a global configuration file.
> Given the above, I'm closing this as "wontfix".
> Discussion can continue by replying to this thread.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Fri, 21 Dec 2018 00:49:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 33787 <at> debbugs.gnu.org (full text, mbox):
If the behaviors you want cannot be done now via command-line options,
that's not an argument against configuring via PATH; it's merely an
argument that you would like some random features that the programs
don't provide now.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Fri, 21 Dec 2018 01:22:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 33787 <at> debbugs.gnu.org (full text, mbox):
Hello,
On 2018-12-20 5:36 p.m., L A Walsh wrote:
> The below methods cannot alter or fix the problems that require
> a configuration file.
>
> Example: have 'rm -fr .' do a depth first removal and not pre-inspect
> any argument before its children.
>
> Whether or not to expand tabs in output so that output to
> a terminal that doesn't have tabstops every 8 characters will line up.
>
> I could go on, but those cannot be handled with a simple alias.
Just to make sure we are talking about the same thing (and avoid "x/y
problem"):
Are you asking about adding *new* features (e.g, "rm --depth-first"
or "cat --expand-tabs"), and then about controlling them throught
a global configuration file?
That is, asking for two different things (new features, and new control
options) ?
For example,
If there was an "rm --depth-first" feature,
you could enable it easily with "alias" - right?
If this is the case, I think it is best to explicitly separate it into
some very different requests:
1. The ability to control existing command-line features
through a global configuration file.
2. Adding "rm --depth-first" option
3. Adding "--expand-tabs" option to multiple programs.
As for #1 - this idea is the topic of the current thread,
and was previously decided to not be accepted.
As for #2 - not sure if this was discussed before,
but I have a hunch that once more sophisticated control
over file-traversal is needed, find(1) is likely better
solution (e.g. "find -depth").
As for #3 - The "expand" program already does tab-expansion.
It can be easily combined with existing programs using
a simple shell function.
e.g.:
sorttab(){ sort "$@" | expand -t20 ; }
---
If you are requesting such features (or others)
It's best to start a new thread for each topic.
regards,
- assaf
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Fri, 21 Dec 2018 01:44:01 GMT)
Full text and
rfc822 format available.
Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):
Features where their non inclusion was unable to be met due to
pre-existing usage and where using or allowing behavior change based
on ENV vars was disallowed due to new gnu policies to minimize usage
of ENV vars. At the time config files were mentioned as a possible
solution but at the time I was told there would be no more config files.
Now I'm seeing references to /etc/xattr.conf regarding which attributes
should be copied and which not when utils like 'cp' or 'tar' preserve
or restore xattrs. If you don't allow a config, how will you skip
attributes that shouldn't be copied on a given system vs. those that
should?
As for random features being added, paul, who was it that added a random
range feature incompatible with what was original suggested and going off
in a different direction. You created an incompatible feature to the
one that was originally proposed... so this is to allow a workaround for
for malicious features rushed to build to disallow alternate sets. It's
not about a new random one, but one that you specifically found an
alternate and incompatible algorithm for. It certainly is no more of
a random feature than the collection of new features that has gone
into random coreutils programs in the past year or two -- many of which,
like with 'ls' were strongly complained about -- and ignored.
Those people who don't like the new, unwelcomed 'features' forced
upon them would have a choice.
Similarly with 'find' -- supposing to use the user provided prefix
prepended on targets, when this doesn't:
"find -type f" doesn't emit plain filenames, but "./" appended to each.
But if you want "./" appended, you already have
"find . -type f". There are several little nitnats that came down to
the dev's choice overriding things users suggested or wanted.
This would allow users to have a choice -- so of course the dictator
devs wouldn't like or want this. Users are to be trodden upon and forced
to conform to what devs think they should do. So much for user-friendly
and programs being to help users vs. oppressed by them.
On 12/20/2018 4:48 PM, Paul Eggert wrote:
> If the behaviors you want cannot be done now via command-line options,
> that's not an argument against configuring via PATH; it's merely an
> argument that you would like some random features that the programs
> don't provide now.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Fri, 21 Dec 2018 01:47:02 GMT)
Full text and
rfc822 format available.
Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):
On 12/20/2018 5:21 PM, Assaf Gordon wrote:
> If you are requesting such features (or others)
> It's best to start a new thread for each topic.
----
They've already been discussed and ignored because there was no
way to add the feature for a default behavior other than
ENV vars or a config, both of which have been rallied against
to maintain the behavior monopoly with the existing devs.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Fri, 21 Dec 2018 02:22:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 33787 <at> debbugs.gnu.org (full text, mbox):
Hello,
On 2018-12-20 6:46 p.m., L A Walsh wrote:
>
>
> On 12/20/2018 5:21 PM, Assaf Gordon wrote:
>
>> If you are requesting such features (or others)
>> It's best to start a new thread for each topic.
> ----
>
> They've already been discussed and ignored because there was no
> way to add the feature for a default behavior other than
> ENV vars or a config, both of which have been rallied against
> to maintain the behavior monopoly with the existing devs.
>
There are few separate issues above:
1. If any messages have been ignored (that is: not replied to at all) -
that's not OK. It happens, as the maintainers volunteer their time
and sometimes messages fall between the cracks, but we try to minimize
these occurrences.
If you (or any one else) have sent a message that have not been replied
to - please do send a gentle reminder to the list
(perhaps with a link to the original message from the mailing list
archives).
2. If a topic has been discussed, and the suggestion or request wasn't
accepted - as frustrating as it is, it is the prerogative of coreutils'
maintainers to decide what goes in and what's not.
Several of my own suggestions were rejected, I certainly understand it
is frustrating. Topics can always be revisited if there are new
reasons to suggest a feature. Supplying a working patch is also
a way to make a stronger case.
3. Every feature in the coreutils' programs, whether existing or
future-suggested, can and must have a command-line parameter option.
Saying "there was no way to add the feature [...] other than ENV vars or
a config" is technically incorrect. If a feature is accepted, it will
have a command-line parameter. There are no features that can only be
set by ENV-vars or a config file.
4. The corollary of #3 is - once a feature has a command-line option,
you can change the default (interactive) behavior with "alias"
or shell functions, and can change the (non-interactive) behavior
with a simple shell-script.
5. New ENV vars are frowned-upon for reasons that have been discussed
several times before (see:
https://www.gnu.org/software/coreutils/rejected_requests.html).
6. Support of a global gnu-wide configuration file is a feature request
that was not accepted (previously in this thread).
----
Please understand that requests for configuration files and ENV vars
are orthogonal to requests for new features.
regards,
-assaf
Severity set to 'wishlist' from 'normal'
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 21 Dec 2018 02:33:02 GMT)
Full text and
rfc822 format available.
Added tag(s) wontfix.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 21 Dec 2018 02:33:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
33787 <at> debbugs.gnu.org and L A Walsh <coreutils <at> tlinx.org>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Fri, 21 Dec 2018 02:33:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Mon, 24 Dec 2018 01:48:01 GMT)
Full text and
rfc822 format available.
Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):
L A Walsh wrote:
> Features where their non inclusion was unable to be met due to
> pre-existing usage and where using or allowing behavior change based
> on ENV vars was disallowed due to new gnu policies to minimize usage
> of ENV vars. At the time config files were mentioned as a possible
> solution but at the time I was told there would be no more config files.
>
> Now I'm seeing references to /etc/xattr.conf regarding which attributes
> should be copied and which not when utils like 'cp' or 'tar' preserve
> or restore xattrs. If you don't allow a config, how will you skip
> attributes that shouldn't be copied on a given system vs. those that should?
>
> As for random features being added, paul, who was it that added a random
> range feature incompatible with what was original suggested and going off
> in a different direction. You created an incompatible feature to the one that
> was originally proposed... so this is to allow a workaround for
> for malicious features rushed to build to disallow alternate sets. It's
> not about a new random one, but one that you specifically found an
> alternate and incompatible algorithm for. It certainly is no more of
> a random feature than the collection of new features that has gone
> into random coreutils programs in the past year or two -- many of which,
> like with 'ls' were strongly complained about -- and ignored.
>
> Those people who don't like the new, unwelcomed 'features' forced upon them
> would have a choice.
I'm afraid I don't know specifically what the above is talking about. All I'm
getting from it is that you think coreutils should have configuration files
(system-wide? user-specific? directory-specific? it's not clear) because some
kernel features have configuration files. But applications and kernels are
different animals, and the existence of a configuration method for the kernel
does not necessarily imply that the same configuration method is a good idea for
applications.
> Similarly with 'find'
"find" is not part of coreutils, and discussion of it should be moved to
a separate bug report, which you can create by emailing bug-findutils <at> gnu.org.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Mon, 24 Dec 2018 07:21:01 GMT)
Full text and
rfc822 format available.
Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):
On 12/23/2018 5:46 PM, Paul Eggert wrote:
>> Similarly with 'find'
>
> "find" is not part of coreutils, and discussion of it should be moved to
> a separate bug report, which you can create by emailing bug-findutils <at> gnu.org.
----
If you were discussing whether or not each each county or province in
the state should have a place where the laws and regulations of that state
and county were on display for reference or consultation, AND you had a
case where whether or not Santa Clara County in California should include
in its display, Bay Area regulations as well, should such discussion
or cases be opened and entertained in Santa Clara County at the same
time one is discussing the statewide or national cases?
Wouldn't it be proper to discuss the Bay Area's inclusion after the wider
jurisdiction cases have been discussed? It might be wiser to discuss
other areas for inclusion after until sometime _after_ the larger case
is settled.
> ... configuration files
> (system-wide? user-specific? directory-specific? it's not clear).
---
As far as the proposal went, I think it was:
"Now I suspect that people will want these options to be
configurable by user and not just at a system level -- so
ideally, there would be a '~/.gnurc' file for user overrides."
> applications and kernels are
> different animals, and the existence of a configuration method for the kernel
> does not necessarily imply that the same configuration method is a good idea for
> applications.
---
Different animals, yes, but similar eco systems (arch, hw, source
lang(s), users, etc...). Also, a need to configure both for their
environments. Both need different methods for building on x86 than on
MIPS, likely different building for a US-based distro vs.
a China-based distro. Like different need for home environment vs
that of a National-Security-Agency, or a bank. Even a vastly
different needs based on filesystem type (How many times did we see
a message from the tail program about an unknown file system?).
Of course in some ways, the kernel stores part of the user's choices
in the hardware config. If they wanted a graphics pen, they probably
bought one, and windows will turn on pen-input, though on linux it's
probably "each app for themself", however the variability in how the
kernel can be configured not only varies by hardware but by your
desired software behavior. Turning on FLASK or SMAC security will
result in the utilities behaving differently.
In all of the above, we see lots of configuration for different
items, but almost non of those items touch on "*user-requirements".
Huh? user requirements? Nearly every bit of new work has
a requirements or prereq. list; why not users?
In new features or improvements in the past year or two -- how many
of them came with some study or poll of users who asked for it? How
many voted for the feature vs. against? How many were discussed on
coreutils before they were introduced? How much weight is given to
user requests?
At one point in time there were vendor versions of many of these
tools, but people often sought the gnu version because it had some
extra behavior or feature. Additionally, I would bet that
many gnu features and utils wooed users by being responsive to
new feature and enhancement requests. Unfortunately, these days
there usually isn't an alternative. Gnu has gone from responsive
to the place of "holding the line" against user wanted changes.
Out of a list of new features or in the past few years, how many
came from user requests? I wonder if number of requests has dropped
off as fewer people are drawn-to or have the ability to do software
development (hard to think about doing much in the way of development
on an iPad or Android device).
I encountered a first, recently: a third-party company that was hired
to support end-users adapting their computers to the program -- but
that did no actual support of the program. If you wanted a new
feature or bug -- you were directed to a community discussion
list that you are told "is often a place where developers (in
a different country speaking a different language) get new
ideas. Right....
The disconnect seems to almost be complete. No longer are programs
created to attract users or solve their problems, but users and their
HW are now being adapted to run the programs.
Maybe this is the first step in computers & hardware laying down
requirements for users.
So I can see why providing a /etc/gnu.conf file to allow programs
to support diffent user behaviors would seem like a a step backward.
But is it really?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Mon, 31 Dec 2018 11:37:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 33787 <at> debbugs.gnu.org (full text, mbox):
On 12/20/2018 5:21 PM, Assaf Gordon wrote:
> For example,
> If there was an "rm --depth-first" feature,
> you could enable it easily with "alias" - right?
---
If you would ensure that this is possible, you would have
my gratitude. However, it is not the case. The algorithm USED to
be depth first, as described in old unix books describing the utility.
However, someone added processing before descending depth first --
specifically, if current name = '.', then abort any processing of that
tree. Dunno if it was a local distro patch or use of some different
version of 'rm' (thinking this might have been the case, as I seem to remember
it support an 'x' option to not cross into other file systems), but
but it used to be the case in some past version that rm would
delete the files under / in that directory without deleting the
directory. It was more concise and safer than anything than
any workaround that has been suggested since.
So if there was an alias to restore that simple behavior, please
share it.
> 3. Adding "--expand-tabs" option to multiple programs.
----
This was asked for and denied.
type. Compare:
df output vs. ls output
8.0K /usr/adm 0 adm
0 /usr/arpwatch 0 arpwatch
76K /usr/bandwidthd 0 bandwidthd
1.5G /usr/bin 288K bin
1.6G /usr/bin1 300K bin1
0 /usr/com 0 com
0 /usr/db 0 db
304K /usr/etc 4.0K etc
0 /usr/games 0 games
294M /usr/include 60K include
0 /usr/java 0 java
2.5G /usr/lib 32K lib
4.8G /usr/lib64 264K lib64
780K /usr/libexec 4.0K libexec
284K /usr/libreadline.so.6 284K libreadline.so.6
467M /usr/local 284K libreadline.so.6.2
0 /usr/lock 0 local
0 /usr/man 0 lock
0 /usr/opt 0 man
16K /usr/run 0 opt
1.8M /usr/samba 0 run
128M /usr/sbin 4.0K samba
16G /usr/share 60K sbin
0 /usr/src 44K share
6.7M /usr/swat 0 src
0 /usr/tmp 0 swat
0 /usr/var 0 tmp
20K /usr/virtualbox 0 var
0 /usr/x86_64-suse-linux 8.0K virtualbox
total 1.6M 0 x86_64-suse-linux
by default ls has options to expand to screen tabs and line things up.
'du' does not.
>
> As for #1 - this idea is the topic of the current thread,
> and was previously decided to not be accepted.
>
> As for #2 - not sure if this was discussed before,
> but I have a hunch that once more sophisticated control
> over file-traversal is needed, find(1) is likely better
> solution (e.g. "find -depth").
>
> As for #3 - The "expand" program already does tab-expansion.
> It can be easily combined with existing programs using
> a simple shell function.
----
So can calling a library where the output is expanded
automatically according to user choice in a config file.
I shouldn't have to figure out the syntax of a separate program to get
a 1-time usage of lined up output.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Mon, 31 Dec 2018 11:38:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Mon, 31 Dec 2018 12:25:02 GMT)
Full text and
rfc822 format available.
Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):
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
suited for these things.
I have no intention of implementing this functionality.
[...]
>> As for #2 - not sure if this was discussed before,
>> but I have a hunch that once more sophisticated control
>> over file-traversal is needed, find(1) is likely better
>> solution (e.g. "find -depth").
>>
>> As for #3 - The "expand" program already does tab-expansion.
>> It can be easily combined with existing programs using
>> a simple shell function.
> ----
[...]
> I shouldn't have to figure out the syntax of a separate program to get
> a 1-time usage of lined up output.
Or, consider a different approach:
With the unix philosophy of "each program should do one thing, and do it
well", 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.
---
However,
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.
To continue discussing other topics or feature requests (e.g.
tab-expansion) - please start a new dedicated thread.
regards,
- assaf
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Mon, 31 Dec 2018 12:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Mon, 31 Dec 2018 13:25:02 GMT)
Full text and
rfc822 format available.
Message #62 received at submit <at> debbugs.gnu.org (full text, mbox):
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."
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Mon, 31 Dec 2018 13:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Mon, 31 Dec 2018 14:17:02 GMT)
Full text and
rfc822 format available.
Message #68 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
On 2018-12-31 6:24 a.m., L A Walsh wrote:
> On 12/31/2018 4:23 AM, Assaf Gordon wrote:
>> 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.
I'm not familiar with any feature request that was rejected because
there was "no easy way of providing default configuration".
Feature requests/suggestions might be rejected because coreutils
maintainers were not convinced they were warranted or useful
or did not pass muster in the trade-off between bloat and functionality.
Again - this is not about a generally rejected feature, but about a
feature that was deemed useful but was rejected because there was no
easy way to configure it (or, control it from the command line?).
If there are specific cases of requests that were denied because there
was no easy way to configure the feature - please provide a link
to such discussion - that will help more the discussion forward.
>> To continue discussing other topics or feature requests (e.g.
>> tab-expansion) - please start a new dedicated thread.
> ----
> Dedicated to what?
Dedicated to one topic.
"Adding global configuration file to all coreutils programs" is one
such topic. Implementing 'rm --depth-first' is a completely different
topic and should be discussed in a separate thread. Adding tab-expansion
to program X is yet another distinct topic.
> 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.
Interrelated does not mean they are the same topic.
To help clarify, in the context of "coreutils" think of a "topic" as
a task or feature that a programmer develops.
Adding "rm --depth-first" feature is a task that a programmer can
develop regardless of whether program X supports tab-expansion.
Adding support for global configuration file is a task that can
be completed regardless of whether rm supports "--depth-first" or not.
etc. etc.
As such, it helps us (coreutils maintainers) and others (anyone else
who is subscribed to the mailing list) to keep each thread to one topic.
That way, a discussion thread has a start, middle, and (hopefully) end.
If a thread goes on and on and covers multiple topics, it makes it
hard to keep track of what is going on and what is discussed.
This is especially true for mailing lists which use the bug tracker
(like bug-coreutils <at> gnu.org).
Every new topic email creates a new bug report page.
In this thread it is here: https://bugs.gnu.org/33787 .
If the thread is long and covers many topics, it makes it very hard
to manage bugs (e.g. classify them and address them).
> I seem to remember this statement by you:
>
> "Discussion can continue by replying to this thread."
Always true.
But it helps if the discussion is focused on one topic (the original
topic from the first message in the thread).
regards,
- assaf
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Mon, 31 Dec 2018 14:17:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Thu, 03 Jan 2019 02:08:01 GMT)
Full text and
rfc822 format available.
Message #74 received at submit <at> debbugs.gnu.org (full text, mbox):
L A Walsh wrote:
> 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.
Uh, no. For example, you can see examples of using two or more commands in
Kernighan and Mashey's 1981 paper "The Unix Programming Environment", which
contains this example:
ls | pr -4 | lpr
which lists files with one command, and then uses another to line them up,
exactly the sort of thing you're saying these people didn't have. The paper goes
on to give statistics of how often people in the early Unix years used the
technique recommended if you don't like the default behavior: have a small shell
script that establishes the behavior you want. Kernighan and Mashey write, "it
has become common for each user to have a collection of personal commands, a
result of the fact that the shell permits users to alter the default search path
for finding commands. These personal commands are almost invariably shell
programs.... people make significant use of shell procedures to customize the
general environment to their personal needs".
So it's not like we're suggesting anything new here.
Kernighan BW, Mashey JR. The Unix programming environment. Computer. 1981
Apr;14(4):12-24. https://www.computer.org/csdl/mags/co/1981/04/01667315.pdf
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#33787; Package
coreutils.
(Thu, 03 Jan 2019 02:08:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 31 Jan 2019 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 87 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.