bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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@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
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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."
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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/games0 games 294M /usr/include60K include 0 /usr/java 0 java 2.5G /usr/lib32K 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/run0 opt 1.8M /usr/samba0 run 128M /usr/sbin 4.0K samba 16G /usr/share60K sbin 0 /usr/src44K 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.
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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-findut...@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?
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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-findut...@gnu.org.
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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.
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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.
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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.
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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.
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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.
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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.
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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.
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
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