bug#24244: bug: dd deletes file
retitle 24244 dd: protect against same file in input,output severity 24244 wishlist tags 24244 wontfix close 24244 stop (triaging old bugs) On 2016-08-16 10:03 a.m., Pádraig Brady wrote: On 16/08/16 16:44, puggy wrote: by mistakes i used the same input and output file. dd said it wrote 0 bytes, but what it actually did is overwrite the file and setting it back to zero. doing so, dd deleted a 4.3G file in a fraction of a blink. [] please find some solution for it. if it is intentional, make an option for it. this way you can also shorten the command. otherwise if input and output are the same, warn the user! Well dd is a low level tool so we have to be careful to not preclude operations which may be valid in some cases. For example one might definitely want to read/write the same device. With no further comments in 2 years, I'm closing this bug. Discussion can continue by replying to this thread. -assaf
bug#23110: seq apparent bug
tags 23110 fixed close 23110 stop (triaging old bugs) On 2016-04-14 11:19 a.m., Bernhard Voelker wrote: On 04/14/2016 06:47 PM, Pádraig Brady wrote: The 2 patches look good. thanks for the review, pushed. closing as "fixed". -assaf
bug#23120: cp with --dereference (-L) and --link (-l) or --symbolic-link (-s)
unarchive 15173 merge 23120 15173 tags 23120 fixed close 23120 stop (triaging old bugs) On 2016-03-26 11:26 a.m., Pádraig Brady wrote: On 26/03/16 10:36, Petr Skočík wrote: I'm on a system with cp 8.21, and when I do `cp -Ll` or `cp -Ls` on a symlink, it hardlinks (-Ll) or symlinks (-Ls) the symlink instead of the target of the symlink. The -Ll hardlink case was fixed in 8.22 with a bit of an epic discussion in http://bugs.gnu.org/15173 The -Ls symlink case currently just symlinks the source symlink. With no further comments in 2 years, I'm closing this bug. -assaf
bug#23268: sort ant uniq bug report
tags 23268 notabug close 23268 (triaging old bugs) On 2016-04-11 11:56 a.m., Assaf Gordon wrote: On 04/11/2016 12:43 PM, 126 wrote: Every other input is working well,but when my input contain several lines of "src/table/checkpoint/checkPointInfo5000.lua". The result of (sort -u) contain two lines of "src/table/checkpoint/checkPointInfo5000.lua" Without seeing the exact input, it is hard to diagnose the issue. Please attach a *small* input file, with the exact command that reproduces your situation to help us understand what's going on. With no further follow-ups in 2 years, I'm closing this bug. -assaf
bug#23302: mention what are nonprinting characters
close 23302
stop
(triaging old bugs)
Le 16/04/2016 21:50, 積丹尼 Dan Jacobson a écrit :
In (info "(coreutils) Concept index") there are several items that talk
about nonprinting characters.
Well on each definition be sure to have a blue word link:: to a passage
about which characters are nonprinting, lest the user think e.g.,
SPC (' ') is nonprinting.
On 2016-04-17 2:16 a.m., f0rhum wrote:
As per https://en.wikipedia.org/wiki/ASCII#ASCII_control_characters
With no further comments in 2 years, I'm closing this bug.
-assaf
bug#23441: mention wc defaults more on man page
close 23441 stop (triaging old bugs) On 2016-05-03 9:14 p.m., 積丹尼 Dan Jacobson wrote: On the man page mention if the default if no arguments are given is wc --bytes --words --lines It seems your message was lost and not answered to in 2 years. Sorry about that. The first line of 'man wc' says: === wc - print newline, word, and byte counts for each file === And similar wording is used through-out (and in 'wc --help'). As such, I'm closing this bug. Discussion can continue by replying to this thread (and concrete patches are very welcomed to improve wording). -assaf
bug#23449: cp command error report
tags 23449 moreinfo close 23449 stop (triaging old bugs) On 2016-05-04 11:47 a.m., Paul Eggert wrote: On 05/04/2016 02:10 AM, Bruce.Zhang wrote: When I run the command like this "/bin/cp -rf /root/update/* /www" . I find some file's permissions is update but the file's content not update . I do not known what happened . Nor does anyone else. :-) I suggest running your command under strace, e.g.,: strace -o foo.log /bin/cp -rf /root/update/* /www and then looking at foo.log to see what happened. The idea is that you need to create a complete, self-contained test case that will let us reproduce the bug. With no further follow-ups in 2 years, I'm closing this bug. -assaf
bug#23556: sort(1): misleading description of option -n
close 23556 stop (triaging old bugs) On 2016-05-16 4:23 p.m., Carsten Hey wrote: * Assaf Gordon [2016-05-16 15:07 -0400]: IIUC, you are disputing the accuracy (or clarity) of the term "string numerical value" on the manual page, and not the actual behavior of "sort -n" … Exactly. It seems like many people have problems to understand mails that contain code, but are neither a patch nor complain about the behaviour of a program - maybe my wording was suboptimal too. I'll consider this in future when I write similar mails. [...] If you have a suggestion for improved wording, I'm sure they can be considered for inclusion. If I would not know that "string numeric value" is proper English, I wouldn't consider it to be correct, hence I'm likely the wrong person to suggest a concrete wording, … With no further follow-ups in 2 years, I'm closing this bug. Discussion can continue by replying to this thread, and patches are always welcomed. -assaf
bug#18168: Bug in "sort -V" ?
tags 18168 notabug
close 18168
stop
(triaging old bugs)
Hello,
It seems your message was lost and not replied to in 4 years.
Sorry about that.
On 2014-08-01 3:38 a.m., Schleusener, Jens wrote:
I am not sure if it's a bug or not but for my application cases the
"sort" command with use of the very helpful option "-V" (natural sort of
(version) numbers within text) not always delivers the by me expected
output.
Note that "-V/--version" is specifically sorting by Debian's *version*
sorting rules. It might seem like it's the same as "natural sort", but
it is not.
The exact rules are here:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
https://readme.phys.ethz.ch/documentation/debian_version_numbers/
Example input file (with four test cases):
1.0.5_src.tar.gz
1.0_src.tar.gz
2.0.5src.tar.gz
2.0src.tar.gz
3.0.5/
3.0/
4.0.5beta/
4.0beta/
Sorted ("sort -V") output file (with errors?):
1.0.5_src.tar.gz
1.0_src.tar.gz
2.0src.tar.gz
2.0.5src.tar.gz
3.0.5/
3.0/
4.0beta/
4.0.5beta/
By me expected output file:
1.0_src.tar.gz
1.0.5_src.tar.gz
2.0src.tar.gz
2.0.5src.tar.gz
3.0/
3.0.5/
4.0beta/
4.0.5beta/
The disagreement is about "1.0_src.tar.gz" vs "1.0.5_src.tar.gz"
and "3.0/" vs "3.0.5/" .
Note that these characters are not strictly valid characters in debian
version strings.
Let's try to compare them using Debian's own tools:
First, define a tiny shell function to help compare strings:
compver() {
dpkg --compare-versions "$1" lt "$2" \
&& printf "%s\n" "$1" "$2" \
|| printf "%s\n" "$2" "$1"
}
Then, compare the values:
$ compver 1.0.5_src.tar.gz 1.0_src.tar.gz
dpkg: warning: version '1.0.5_src.tar.gz' has bad syntax: invalid
character in version number
dpkg: warning: version '1.0_src.tar.gz' has bad syntax: invalid
character in version number
1.0.5_src.tar.gz
1.0_src.tar.gz
$ compver 3.0/ 3.0.5/
dpkg: warning: version '3.0/' has bad syntax: invalid character in
version number
dpkg: warning: version '3.0.5/' has bad syntax: invalid character in
version number
3.0.5/
3.0/
So sort's order agrees with Debian's ordering rules.
It might not be what a "natural sort" algorithm would do, but version-sort
is not exactly natural-sort.
Another detailed example of a version-sort is here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22275
As such, I'm closing this bug.
Discussion can continue by replying to this thread.
-assaf
bug#33289: tail -f error within docker container
tags 33289 notabug close 33289 stop Hello, On 2018-11-06 2:05 a.m., Jörgen Christiansson wrote: I get this message when doing tail -f on a regular file within a docker container. tail: unrecognized file system type 0x794c7630 for ‘/var/opt/system/log/snmpexport.trc0’. please report this to bug-coreutils@gnu.org. reverting to polling Thanks for the report. This filesystem has been supported since version 8.25. You are likely using an older version. For details, see: https://www.gnu.org/software/coreutils/filesystems.html regards, - assaf
bug#12741: any cross-compile fails due to new make-prime-list
tags 12741 fixed close 12741 stop (triaging old bugs) On 2012-10-26 11:27 a.m., Jim Meyering wrote: That would be fine with me. We were precomputing the "wheel.h" table of primes before, too. If we go the route of distributing the generated file, then we might as well resort to using Perl and say, -Mbigint, to do generate all variants. Starting with version 8.21, "prime.h" is pre-built and distributed. Committed here: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=f16e251dae43117c2cd19359c26ce7b5e05165b6 As such, closing this bug. -assaf
bug#23645: GNU coreutils 8.25 make check report
close 23645 stop On 2018-10-28 12:00 a.m., Assaf Gordon wrote: (triaging old bugs) Hello, On 2016-05-29 12:22 a.m., Donald A. MacDonald wrote: Just build coreutils on a MacBook Pro running OS X 10.11.5 (El Capitan) Are you still experiencing these failures (perhaps with more recent coreutils version, or more recent Mac OS X version) ? For now I'm closing this bug. If this issue still occurs, we'll reopen it. Discussion can continue by replying to this thread. -assaf
bug#33288: Bug report - tail: unrecognized file system type
tags 33288 notabug close 33288 stop Hello, On 2018-11-06 6:26 a.m., Adam Solymos wrote: I have encountered an issue in tail command when running it in a Debian based Linux distro (Linux f596ea7f8fe0 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:55:56 UTC 2018 x86_64 GNU/Linux) in a Docker container on a Windows 10 host OS. Error message: tail: unrecognized file system type 0xfe534d42 for 'errors.log'. please report this to bug-coreutils@gnu.org. reverting to polling Thanks for the report. This filesystem has been supported since version 8.26. You are likely using an older version. For details, see: https://www.gnu.org/software/coreutils/filesystems.html regards, - assaf
bug#12453: failed test suite on 64-bit debian squeeze
tags 12453 moreinfo close 12453 stop On 2012-09-16 2:38 p.m., Jim Meyering wrote: Thank you for reporting that. At first glance, that failing assertion seems due to a bug in your system's version of valgrind. I don't immediately see a clean way to work around it. Sure, the dirty way would be to search for this line: With no further comments in 6 years, I'm closing this bug. -assaf
bug#15023: Coreutils on IRIX
tags 15023 moreinfo close 15023 stop (triaging old bugs) On 2013-08-09 2:26 p.m., Paul Eggert wrote: One other thing. Under what conditions do include ? [...] and so I'd like to know which symbols protect the inclusion of (here it includes _SYS_TIME_H and the others). With no replies or further follow-ups in 5 years, I'm closing this bug. Discussion can continue by replying to this thread. -assaf
bug#19375: (no subject)
tags 19375 fixed close 19375 stop pushed at https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=178f8e79dcd1e0b8bbb3b04da664d05eaae56186 closing.
bug#6906: [PATCH] cp: copy entirely-sparse files oodles faster
(triaging old bugs) Hello, On 17/04/11 10:28 AM, Paul Eggert wrote: On 04/17/11 01:55, Jim Meyering wrote: Now that we have FIEMAP support, (by the looks of things we will soon have SEEK_HOLE support in cp and in the linux kernel) do you think adding support for this special case is worthwhile? I could go either way. If so, would you care to rebase it for 8.13? Yes, I expect it's worthwhile, as the FIEMAP stuff isn't universal. I'll add it to my list of thing to do. It's not high priority, to be sure. In the 8 years since the original thread, cp(1) can now copy sparse files very fast (though I suspect it's still with FIEMAP and not SEEK_DATA/HOLE). https://bugs.gnu.org/6906 Can this be closed as out-dated? regards, - assaf
bug#19154: (no subject)
tags 19154 fixed close 19154 stop Pushed in https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=16e2347bd545057b04a97115563e606ad822ec33 closing.
bug#6048: bug#11443: linux "cp" and ocfs2 reflink/clone/fastcopy/copy on write
(triaging old bugs) On 14/05/12 07:19 AM, Pádraig Brady wrote: On 05/09/2012 03:28 PM, Kai Petzke wrote: there has been work by others about adding support for the OCFS2 "reflink" ioctl() call, which is similiar to the btrfs "clone" call, and creates a copy-on-write copy of the original, thus allowing to "copy" even gigabyte sized files within a tiny fraction of a second, and without using much additional file system space. See: [...] even though the interface to use to different system calls to achieve the same thing is awkward. But, as laid out in the comments in the source, btrfs clone and ocfs2 reflink are semantically quite different, so that unifying them into one on the kernel side is not likely to happen, soon, if it happens at all. That would be unfortunate. Hopefully a generic reflink() call can be sorted out. In 2014 we had this commit: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b47231be6813e6cb5305266e391b4bb745f27f13 commit b47231be6813e6cb5305266e391b4bb745f27f13 Author: David Sterba Date: Wed Sep 24 11:15:05 2014 +0100 mv: use reflink=auto mode by default On some filesystems (BTRFS), moving a file within the filesystem may cross subvolume boundaries and we can use a lightweight reflink copy, similar to what cp(1) can do, which is faster than a full file copy. Does this 'reflink=auto' mode addresses OCFS2 as well? I believe so, but want to double-check. If there are no objections, I'll mark this as "fixed/done" in couple of days. regards, - assaf
bug#5918: [dd] conv=sparse option
tags 5918 fixed close 5918 stop Hello, Coreutils version 8.16 (released 2012) gained "dd conv=sparse" option, see https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=4e776faa8482ae630d2ea9bc767298e664f07ba9 closing this bug. regards, - assaf
bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
close 15926 stop (triaging old bugs) The original topic of using remove(2) call in rm(1) was decided to be undesirable. Starting at around the 33rd message [1] the thread diverges into bugs in "rm -rf ." and similar problems (which are resolved by the 221st message [2]. [1] https://bugs.gnu.org/15926#33 [2] https://bugs.gnu.org/15926#221 I'm therefore closing this item (it is already marked as "not a bug", relating to the original request). We typically write "discussion can continue by replying to this thread", but in this case I think it should not be encouraged. If there are further issues with "rm", please do start a new thread (if it's a bug - to bug-coreutils@gnu.org ; if a feature request - to coreut...@gnu.org ). regards, - assaf
bug#19681: (no subject)
close 19681 stop Pushed at https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=8b2bf5295f353016d4f5e6a2317d55b6a8e7fd00 closing.
bug#6667: dd ?bug? while making image of hdd with bad sectors
tags 6667 notabug close 6667 stop Hello, On 19/07/10 08:44 AM, Pádraig Brady wrote: On 19/07/10 10:05, Jakub Muszynski wrote: I have been trying to make a dd copy : dd if=/dev/sdb conv=noerror,sync bs=4096k|pv| dd of=usb320.dd conv=noerror,sync bs=4096k > dd320.LOG but image took all my free diskspace (406GB), and terminated, eventhough my hdd is 320GB dd doesn't read full blocks by default, so one has to be careful when reading from pipes. [...] Does adding "iflag=fullblock" to the second dd fix things? Since you're not specifying a count, just removing the "sync" option from the second dd is equivalent. With no further comments in 8 years, I'm closing this item. regards, - assaf
bug#6816: df bug on 64-bit Solaris (need to use getextmntent)
(triaging old bugs) Hello, On 15/09/10 04:18 PM, Eric Blake wrote: On 08/06/2010 01:56 PM, Wood, David wrote: From mnttab(4) on Solaris 10: [...] At this point, me->me_dev contains a wrongly packed (32-bit) device number, which forces the find_mount_point() code path (causing other unpleasantries). The following patch against coreutils v8.5 fixes the problem: Thanks for the report. Yes, this needs to be folded into gnulib, but it also needs an m4 check for getextmntent, and it would be nice to get by with less in-function #ifdefs. In 2014 gnulib gained the following commit: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=502809019bd2ca3ce3d041d18c35ce9420eedb72 === commit 502809019bd2ca3ce3d041d18c35ce9420eedb72 Author: Ben Walton Date: Tue Jun 3 23:01:14 2014 +0100 mountlist: avoid hasmntopt const type warning on solaris === Which seems to address a similar issue as this bug ( https://bugs.gnu.org/6816 ). I think recent coreutils build well on 64bit solaris. If there are no objections I will close this bug in couple of days. regards, - assaf
bug#7313: sha1sum etc, output in base64
close 7313 stop (triaging old bugs) Hello, On 02/11/10 11:15 AM, Pádraig Brady wrote: On 02/11/10 16:20, Pádraig Brady wrote: env printf $(sha1sum file | sed 's/ .*//; s/\(..\)/\\x\1/g') | base64 openssl dgst -sha1 -binary $file | openssl enc -base64 And also: sha1sum FILE | xxd -r -p | base64 With no further comments in the last 7 years, I'm closing this bug. regards, - assaf
bug#6366: comm: use numeric sort (optionally)
severity 6366 wishlist stop (triaging old bugs) Hello, On 22/08/12 04:00 PM, Pádraig Brady wrote: On 08/22/2012 09:17 PM, Sam Steingold wrote: I have a file of numbers (integers IDs) which are sorted numerically, but comm complains that they are not. I suggest that comm accept "-n" option (like sort) to use numeric sort. Thanks. Yes. comm, join, uniq really should support the same field selection and comparision flags as sort. There are already bugs for that: http://bugs.gnu.org/5832 http://bugs.gnu.org/6366 There is an on-going (though somewhat dormant) effort to consolidate the key comparison of uniq/join/sort into one common module: https://lists.gnu.org/r/coreutils/2013-02/msg00087.html https://lists.gnu.org/r/coreutils/2016-04/msg00063.html As such, I'm marking this as a wishlist item, and hopefully we'll get to it sooner or later... regards, - assaf
bug#7176: [PATCH] human: add unambiguous block_size_args
tags 7176 wontfix close 7176 stop (Triaging old bugs) Hello, On 16/04/13 11:12 AM, Mihai Capotă wrote: On Sun, Apr 14, 2013 at 1:52 AM, Pádraig Brady wrote: So I was 50:50 on making this change, and in the meantime numfmt(1) was released, which gives full control over number formatting, albeit in a more verbose/explicit form. Let me see if I can convince you with a use case. If you set "BLOCK_SIZE=binary" in your shell configuration file, you get the output you want from all programs that use gnulib. That's not only about verbosity, it's something that cannot be easily done with numfmt. Given that: 1. numfmt does some of the requested functionality 2. environment variables are frowned upon and not likely to be expanded 3. there has been no further comments in 5 and a half years I'm opting to close this bug, and we can always re-open the bug if needed. Discussion can continue by replying to this thread, regards, - assaf
bug#7257: [PATCH] Correct typos in date
tags 7257 fixed close 7257 stop (Triaging old bugs) Hello, On 17/04/11 03:04 AM, Jim Meyering wrote: Tobias Quathamer wrote: I think I've found three typos in the date program. I've attached a patch correcting those. There was some discussion at http://debbugs.gnu.org/7257 and one change was pushed. I'm marking this moreinfo in case someone wants to pursue the others. All the suggestions in Tobias's original submission have been fixed now, and there's also a syntax-check rule to always use "time zone" instead of "timezone". As such I'm making this as done. regards, - assaf
bug#6056: base32 output for md5sum sha1sum etc.
(triaging old bugs) Hello, A new "base32" program was added coreutils version 8.25 (released 2016). Now it is easy to run something like: sha1sum ... | cut -f1 -d' ' | xxd -r -p | base32 As such (after 8 and a half years), I'm marking this as "closed". Discussion can continue by replying to this thread. regards, - assaf
bug#9430: [PATCH] Add new option --in-place
tags 9430 wontfix close 9430 stop (Triaging old bugs) Hello, On 03/09/11 10:50 AM, Jim Meyering wrote: Jim Meyering wrote: Picking up on an 18-month-old thread, Egan McComb found the tool I'd seen: sponge: Egan McComb wrote: > > The program that works similarly is called sponge, from the moreutils > project at http://kitenet.net/~joey/code/moreutils/. It is used as a > filter in a pipe: > > for FILE in *.c; do cppi ...options $FILE | sponge; done > It's a fine argument for not adding an --in-place option. It could use a --backup option, though. With 'sponge' existing, Pádraig's post about file replacement[1], and no further activity of this bug in 7 years, I'm opting to mark it as "wontfix" and close it. We can always re-open it if needed. Discussion can continue by replying to this thread. [1] https://www.pixelbeat.org/docs/unix_file_replacement.html regards, - assaf
bug#10013: man ls
tags 10013 wontfix close 10013 stop (Triaging old bugs) Hello, With no further comments in 6 years, the last consensus seems to be this addition is undesired. I'm marking this as 'wontfix' and closing. Discussion can continue by replying to this thread. regards, - assaf
bug#11540: [PATCH] tee: add a flag to ignore SIGPIPE
tags 11540 fixed
close 11540
stop
(Triaging old bugs)
Hello,
On 23/05/12 07:25 AM, Igor Ippolitov wrote:
The default would be to diagnose write errors,
and that could be changed with:
--write-error={[cont],ignore,exit}
In coreutils version 8.24 (released 2015) 'tee' gained
the '--output-error=MODE' option.
I'm marking this as "fixed" and closing.
regards,
- assaf
bug#12964: [PATCH] printenv: -n option added -- show names of variables.
(Triaging old bugs) Hello, On 22/11/12 03:42 PM, Van de Bugger wrote: Subject: [PATCH] printenv: -n option added -- show names of variables. * src/printenv.c: -n option added -- show names of variables. --- src/printenv.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) Thank you for the patch. It seem it have slipped between the cracks long ago - sorry about that. So summarize: With your patch, using "printenv -n VARNAME" adds the variable name to the output. e.g.: $ printenv HOME /home/gordon $ printenv -n HOME HOME=/home/gordon From a cursory look this seems like a non-standard extension that is not available in any other 'printenv' implementations. Do you have any specific use-cases for this functionality (that can't be easily done with existing methods) ? I'm inclined to close it as "wontfix" - but will wait few days in case others want to chime in with other opinions. regards, - assaf
bug#32577: Bug with Docker image run
Hello, On 29/08/18 10:45 AM, Pierre wrote: tail: unrecognized file system type 0x794c7630 for ‘/var/log/syslog’. please report this to bug-coreutils@gnu.org. reverting to polling Thank you for the report. This has been fixed in later versions (since version 8.25, released in January 2016). For more details, see https://www.gnu.org/software/coreutils/filesystems.html regards, - assaf
bug#32807: file system type 0x794c7630
Hello, On 22/09/18 10:41 AM, Thorbjörn 'Puggan' Sundragon wrote: "tail: unrecognized file system type 0x794c7630 for 'ekonomic-access_log'. please report this to bug-coreutils@gnu.org. reverting to polling" Thank you for the report. This has been fixed in version 8.25 and later. for more details, see: https://www.gnu.org/software/coreutils/filesystems.html regards, - assaf
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
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#9614: date ignoring wrong TZ values
Hello, On 2018-10-15 8:11 a.m., Assaf Gordon wrote: tags 9614 wontfix severity 9614 wishlist Changed my mind (and noticed that Paul removed the "wontfix" tag), so here goes... On 27/09/11 11:48 PM, Paul Eggert wrote: On 09/27/11 22:44, Sandro Santilli wrote: A warning/error message with hint on how to correctly form the string would be very friendly for users Unfortunately, there's no portable way to determine which TZ values are supported on the current platform. One cannot even reliably determine whether the current TZ value is supported. So it's not clear how that warning would be generated. Attached is a crude attempt at detecting and warning about invalid timezone strings. First and foremost, the code only runs when the user specify "--debug", so hopefully it won't have any ill effects. Second, the goal is to detect the most common usage errors (e.g. "America/NewYorx" or "Jamaika"), not to re-implement a fool-proof parser for timezones. Third, The code runs "mostly well" on "most common" operating systems. There sure to be cases where it doesn't work (but the "doesn't work" part simply means that with "--debug" it might warn about invalid timezone when it is a valid timezone that resolves to GMT). OpenBSD is such a case. --- With this patch, "date --debug" is able to warn about: TZ=America/NewYorx date --debug TZ=Europe/Lomdom date --debug TZ=FOOBAR date --debug date --debug -d 'TZ="Asia/Japan" 2019-01-01' while it knows not to warn about: TZ=Africa/Dakar date --debug # Valid GMT timezone TZ=GB date --debug # Valid GMT timezone on most systems TZ=FOO+0 date --debug # Valid UTC+0 timezone The warning looks like so: $ TZ=America/Kalgary ./src/date --debug date: possibly invalid timezone in TZ envvar: date:‘America/Kalgary’ date: timezone UTC0 will be used. Mon Dec 31 16:41:08 America 2018 The detection works well on Debian 9, Centos 7, FreeBSD 11, NetBSD 7.1, AIX 7.2 . OpenBSD is an example of where it doesn't work - there's no way to differentiate between an invalid timezone and a valid GMT timezone. But on such system, the code self-diagnoses this issue and prints additional warnings: $ TZ=Africa/Dakar ./src/date --debug date: possibly invalid timezone in TZ envvar: date:'Africa/Dakar' date: timezone UTC0 will be used. date: this system has limited capabilities in detecting date: invalid timezones. It is possible this is a valid timezone date: in the GMT zone. Mon Dec 31 16:43:35 GMT 2018 --- This patch includes a unit-test, but because the names of available timezones vary so much between systems, it doesn't pass everywhere. It is therefore marked as "very expensive". To run it, use: make check SUBDIRS=. TESTS=tests/misc/date-debug-TZ.pl \ RUN_VERY_EXPENSIVE_TESTS=yes --- The heuristic code to determine if a timezone is valid or not is quite hairy. There's likely room for improvements. Comments and feedback and improvement suggestions are welcomed, - assaf 0001-date-detect-and-warn-about-invalid-TZ-values-with-de.patch.gz Description: application/gzip
bug#33942: ls directly uses filename as option parameter
tags 33942 notabug
close 33942
stop
Hello,
On 2018-12-31 7:52 p.m., westlake wrote:
I have known long time about certain commands that use "--" as a
specially reserved parameter. However, I find the behaviour of it with
ls showing a little confusing results and believe this surmounts to a bug,
What you describe below is not a bug, but the indented behavior.
[...] and found out that
having a file called "./--" creates unpredictable behaviour [...]
First,
It's important to understand the filename is not "./--" (4 characters),
but "--" (2 characters) in the current directory ("./").
This is similar to typing "/home/user/--".
You wouldn't say the filename is "/home/user/--" - the filename is "--"
and it is in the directory "/home/user/".
While it might sound like splitting hairs, this is critical to
understand what's going on here. The filename starts with (and contains
only) two minus characters.
$ touch 0 ./--a ./-a ./-_a ./--
$ ls -lad -* [^-]*
Second,
It is important to understand that it is the shell which does
the filename completion (e.g. "*" and "-*" etc.).
The filename expiation happens before "ls" is even executed.
With this in mind, it'll be easier to understand what's
going on if you add "echo" to every command, and look
at what's printed:
$ echo ls -lad -* [^-]*
ls -lad -- -a -_a --a 0
$ echo ls -lad -- -* [^-]*
ls -lad -- -- -a -_a --a 0
$ echo ls -lad -- *
ls -lad -- -- 0 -a -_a --a
Notice that example 2, "-*" is being parsed with "--a" , is "./--" not
showing up due to "design" or is this a "bug" ? If "--a" is getting
listed, then so should the file called "./--",
Not a bug.
Using "echo", you can see what are the exact parameters that are passed
to "ls".
And then follow these simple steps:
1. The first "--" tells ls to stop processing options.
2. anything that starts with a dash BEFORE the first "--" marker
is taken to be an option.
3. anything AFTER the first "--" marker is taken to be a file name
(strings starting with a single dash, and including additional "--"
strings).
That's it - and it works consistently for most GNU programs, not just ls.
Okay I understand ls complaining:
"
ls -lad *
ls: invalid option -- '_'
Try 'ls --help' for more information.
using "echo" will show what's happening:
$ rm ./--
$ echo ls -lad *
ls -lad 0 -a -_a --a
With the file "--" gone (which was seen be "ls" as the "--" marker),
ls now sees "-a" as an option (a valid option),
then it sees "-_a" (and "_" is not a valid option) - hence the error
message.
^ but it is counter-intuitive because having a file called "./--", and
this command passes.
If you follow the simple steps above (and use "echo" to see how the
shell performs filename expansion), I hope all the other issues you've
listed in your email will become clear.
If not - please do write with specific cases.
I'm closing this as "not a bug", but discussion can continue
by replying to this thread.
-assaf
bug#9614: date ignoring wrong TZ values
Hello Paul,
On 2019-01-02 12:08 a.m., Paul Eggert wrote:
I think this implementation is heading in the wrong direction. To
determine whether a time zone string FOO is valid, a program should call
tzalloc (FOO) and sees whether that yields NULL. And if tzalloc doesn't
work that way now, we should fix tzalloc so it does. Once that happens,
'date' can simply call tzalloc (getenv ("TZ")) to see whether the time
zone setting is OK.
Thanks for the feedback.
Asking for a bit more details, clarifications...
If I understand correctly, the current gnulib implementation
of "tzalloc" is very minimal and without any checks.
Basically the only way for it to return NULL is if the malloc failed.
https://git.sv.gnu.org/cgit/gnulib.git/tree/lib/time_rz.c#n92
And previously you wrote:
> Unfortunately, there's no portable way to determine
> which TZ values are supported on the current platform.
So do you mean that:
This sort of heuristics (or another/better heuristic implementation)
should be moved into gnulib, and 'hidden' with tzalloc's very simple
interface?
(date already calls tzalloc(getenv("TZ")) but doesn't check the returned
value.)
or
gnulib's tzalloc implementation should be greatly expanded to be able
to decode the operating system's local timezome?
(or perhaps the timezone management code copied from glibc?)
or
something completely different?
thanks!
- assaf
bug#34110: feature request: dual-column du output, showing "real" and "on-disk" sizes (and about that "apparent-size" concept)
Hello, I'll address only the "apparent-size" issue (not the two-columns, or compressed file-systems): On 2019-01-16 1:13 p.m., René J.V. Bertin wrote: According to `du --help`, the apparent-size option reports a size that is not the actual disk usage. The numbers above seem to show the opposite. If anything, I find the concept of "apparent size" more appropriate to the size a file occupies on the storage medium because ultimately that storage device will not give you more than "struct stat : st_size" bytes for uncompressed filesystems. Another way to say it: with "--apparent-size", du returns the actual file size; without, it returns how large the file appears to be (judging from its disk footprint). "apparent-size" shows how much content/data the file has. without "apparent-size" du shows the amount of storage consumed (or "wasted"?) on the storage medium (accounting sparse file holes, though I'm not sure about compression). To illustrate, create three files with specific sizes: $ head --bytes=1700 /dev/zero > a $ head --bytes=4097 /dev/zero > b $ truncate --size=105 c# will be a sparse file These are their sizes, as in the amount of bytes they contain: $ ls -log total 12 -rw-r--r-- 11700 Jan 16 15:36 a -rw-r--r-- 14097 Jan 16 15:36 b -rw-r--r-- 1 105 Jan 16 15:37 c These are their "apparent-sizes", rounded up to the nearest 1K block: $ du --apparent-size a b c 2 a 5 b 1026 c e.g. file "a" is 1700 bytes, rounded-up to 2K, and "du --apparent-size" shows "2". Using "--apparent-size --block-size=1" (and its equivalent, "--bytes") will show the exact sizes: $ du --apparent-size --block-size=1 a b c 1700 a 4097 b 105 c Without "--apparent-size", du shows how much storage space is actually used/wasted/consumed on the storage medium by the files: $ du a b c 4a 8b 0c How are these numbers calculated? The simplest case is file "c" - it is completely sparse - so despite logically containing 1,050,000 zeros, on the actual storage medium it consumes zero data blocks (ignoring inodes blocks and somesuch). File "a" has 1,700 bytes of data. On my filesystem the basic block size is 4096, as shown by "stat -f": $ stat -f / File: "/" ID: 5a2cade519bada6a Namelen: 255 Type: ext2/ext3 ->Block size: 4096 Fundamental block size: 4096<- Blocks: Total: 27559017 Free: 18845977 Available: 17435289 Inodes: Total: 7036928Free: 6496730 Therefore, any file from size 1 to size 4096 will consume exactly one disk block. On most common filesystems, disk blocks can not be shared between files. Meaning that this block is fully consumed. That's why for file "a" du shows "4" - meaning 4K bytes (exactly one block) is consumed on the storage medium by this file. Similarly for file "b" - its size is 4097, which is 1 byte more than one filesystem block. Hence, file "b" consumes 2 blocks, coming up to 8K. du then shows "8" for file "b". Now to your examples: %> du -hcs /Volumes/nif64/tmp/.npm/ ; du -hcs --apparent-size /Volumes/nif64/tmp/.npm/ 340M/Volumes/nif64/tmp/.npm/ > 180M/Volumes/nif64/tmp/.npm/ Same folder on btrfs (mounted with compress=lzo): > %> du -hcs /mnt/.npm/ ; du -hcs --apparent-size /mnt/.npm> 198M /mnt/.npm/> 181M/mnt/.npm In both cases, "du --apparent-size" shows about 180MB of actual data (181MB in the second example). That is the amount of actual content (number of total bytes in these files). In the first case, these files consume 340MB of space on your disk. In the second case, these files consume 198MB of space on your disk. The reason they consume MORE than their actual data is explained above with the file-system blocks. This suggest to me that compression is not accounted for in these values. If it was, then the consumed size (without "--apparent-size") should've been less than the actual size (with "--apparent-size"). A quick on-line search shows that btrsf's default block size is 16K, while ZFS's default record-size is 128KB. That might explain why similar amount of data (and I assume, similar number of files and sizes) consume more disk space on ZFS (Could be wrong, though, comments are welcomed). I hope this helps to clarify "apparent-size". I'll leave it to others to comment on how compressed file systems come into play with du. regards, - assaf
bug#8960: stdbuf on bi-arch systems
severity 8960 wishlist stop (triaging old bugs) Hello, On 2011-07-04 10:15 a.m., Pádraig Brady wrote: On 29/06/11 21:47, Bruno Haible wrote: The program 'stdbuf' on bi-arch x86 / x86_64 systems cannot work on all kinds of programs. [...] I would like to have a single binary that works on both x86 and x86_64 programs. [...] if stdbuf sets both LD_PRELOAD_32 and LD_PRELOAD_64 to the appropriate libstdbuf.so, it should just work. It's been more than 7 years since last comments/progress on this issue. Is it still relevant / needed ? If no one replies, I'll close it as "wontfix" in a few days. regards, - assaf
bug#32455: cp gets confused by symlinks to parent directory
tags 32455 notabug
close 32455
stop
Hello,
It seems your message has not been replied to in a long while.
Sorry about that.
On 2018-08-16 8:47 a.m., Mike Crowe wrote:
If cp is passed the -d option and told to copy a symlink to the directory
containing the symlink then it ends up removing the target directory so it
is unable to create the symlink.
If my understanding is correct, the "-d" flag is not relevant to the
issue. The problem is that "self" is a symlink to a directory:
Reproduction script:
--8<--
#!/bin/sh
set -x
rm -rf temp
mkdir -p temp/src temp/dest
ln -s . temp/src/self
# This one works
cp -vd temp/src/self temp/dest/self
This works because "temp/dest/self" does not exist.
In this case, "temp/dest" is taken as the destination directory,
and "self" is taken as the name of the file/dir/symlink to create.
That is, you could run "cp -vd temp/src/self temp/dest/foobar"
to create "foobar" as a copy of "self".
# This one fails
cp -vd temp/src/self temp/dest/self
Here, "temp/dest/self" already exists, and it is a symlink to
a directory.
Meaning, the request is: copy "temp/src/self" into the directory
"temp/dest/self/" (and create "temp/dest/self/self").
This would have gone well, except that because "self" is a symlink
to ".", it can be resolved indefinitely:
$ file temp/dest/self
temp/dest/self: symbolic link to .
$ file temp/dest/self/self/self/self/self/self
temp/dest/self/self/self/self/self/self: symbolic link to .
$ file temp/dest/self/self/self/self/self/self/self
temp/dest/self/self/self/self/self/self/self: symbolic link to .
"cp" first removes "temp/dest/self/self" (which is valid),
but then, "temp/dest/self" is gone (since it is the same file path after
resolving it).
Hence, "cp" fails by saying "no such directory" on "temp/dest/self/self".
When this step is done, "temp/dest/self" does not exist,
and so:
# This one works again
cp -vd temp/src/self temp/dest/self
This works as before.
You can observe what happens on the kernel level
by adding "strace -e trace=file" before the "cp" commands,
this might help in deeper understanding.
To illustrate this differently:
When creating regular directories and files,
then deleting the innermost files, it is naively expected
that the parent directories still exist:
mkdir -p a/b/c/d
touch a/b/c/d/e
rm a/b/c/d/e
That is, a normal program can call "dirname("a/b/c/d/e")"
to get the parent directory of "e", and expect it to still
exist even after "e" is deleted.
But with your case:
$ mkdir a
$ ln -s . a/self
$ rm a/self/self/self/self/self/self
All the "apparent" parent directories ("self/self/self/self/self")
are gone!
Expected behaviour:
There should be no error message emitted by the second invocation of cp,
and the target directory should be in the same state as it is after the
first or third attempts to copy the symlink.
Not exactly.
What you want is for the DEST parameter of "cp" to always be a file,
never to be considered a directory, i.e. "temp/dest/self"
should always be interpreted as file "self" in directory "temp/dest",
never as directory "temp/dest/self".
Luckily, there is already an option for that:
-T, --no-target-directory
treat DEST as a normal file
With "-T", repeated commands work as you expected:
$ mkdir -p temp/src temp/dest
$ ln -s . temp/src/self
$ cp -vdT temp/src/self temp/dest/self
'temp/src/self' -> 'temp/dest/self'
$ cp -vdT temp/src/self temp/dest/self
removed 'temp/dest/self'
'temp/src/self' -> 'temp/dest/self'
$ cp -vdT temp/src/self temp/dest/self
removed 'temp/dest/self'
'temp/src/self' -> 'temp/dest/self'
$ cp -vdT temp/src/self temp/dest/self
removed 'temp/dest/self'
'temp/src/self' -> 'temp/dest/self'
[... ad infinitum ...]
I hope this addresses the issue,
I'm closing this as "not a bug", but discussion can continue by replying
to this thread.
regards,
- assaf
bug#34110: feature request: dual-column du output, showing "real" and "on-disk" sizes (and about that "apparent-size" concept)
Hello, On 2019-01-18 2:56 a.m., René J.V. Bertin wrote: the code isn't the most welcoming to dive into I've ever seen ;) Two online resources that might help in exploring the code: http://www.maizure.org/projects/decoded-gnu-coreutils/ https://opengrok.housegordon.com/source/xref/coreutils/ regards, - assaf
bug#32198: tail -f -F unexpected behavior
tags 32198 notabug close 32198 stop Hello, It seems your message has not been replied to in a long while. Sorry about that. On 2018-07-18 8:24 a.m., Matthew Guidry wrote: I was doing some experimentation with nano v2.9.3 and tail, watching the output of tail after saving in nano and encountered some strange behavior. This is not a bug at all (not in tail nor in nano). It is the result of updating a file in-place (i.e. changing existing bytes) which 'tail' already consumed. I had two terminals open side by side; one with nano and one with tail. I opened a file called test.txt in nano and saved with ^w in the first terminal. I went to the second terminal and ran tail -f test.txt to watch the file. I went back to the nano terminal and returned twice and saved. The tail terminal reports this change properly. With the file still open in nano, I write any number of characters and save. The tail terminal reports this change But skips the first character. To better see what happens, open a third terminal, and run the following command (after initially saving the file): watch -n1 od -tc test.txt Which will show the content of the file, updated once a second. I will use a similar but slightly different flow: 1. When you first save (in nano) the file, it is empty. The "od" terminal will show: 000 2. Type "12345" (don't press ENTER), and save (ctrl-O). The "od" terminal will show: 000 1 2 3 4 5 \n 006 The "tail" terminal will show: 12345 AND the cursor in the "tail" terminal will go to the next line (as there is a newline in the file). 3. Still in nano, on the same line, type "67890" (don't press ENTER), and save (CTRL-O). The "od" terminal will show: 000 1 2 3 4 5 6 7 8 9 0 \n 011 The "tail" terminal will show: 12345 7890 Here, the "6" character was not displayed by "tail". The reason is that that character in offset 6 of the file used to be a newline, and "tail" already consumed it. When the line was changed, nano went back and changed existing data in the file (or re-wrote the file completely - not sure about the implementation). "tail" has no way to detect that or "go back" in the file. This is a carefully constructed example, where the data change is small enough so that that "tail" almost doesn't notice it. If you make larger changes, or delete some parts of the file, nano will rewrite the file completely and "tail" will issue a warning such as: tail: test.txt: file truncated and then re-read the file. As such I'm closing this as "not a bug", but discussion can continue by replying to this thread. regards, - assaf
bug#34143: [coreutils 8.28] du -x is reporting a lower disk usage for /mnt when partitions are mounted
tags 34143 notabug close 34143 stop Hello, On 2019-01-19 3:11 p.m., Joseph Paul wrote: It may not be a bug at all, but I was surprised to find out that 'du -x' is reporting a lower disk usage on /mnt when partitions are mounted. This is not a bug. Technically, as you wrote below, du simply skips (and does not count) any directory that is not on the same filesystem. [...] linux$ du -x /mnt 4/mnt/data 4/mnt/VL1800 4/mnt/nfs/nas 8/mnt/nfs 20/mnt /mnt is now bigger. Is this a normal result, because even when mounted, physically, the directories '/mnt/VL1800' and '/mnt/data' still exist on the '/' filesystem, or not ? Shouldn't they still occupy 4Kb of disk space each on the '/' filesystem when partitions are mounted ? They do occupy as much disk space as before, but du has no way to know how much they occupy, because the kernel reports that they are on a different device and you requested -x/--one-file-system. We can even take it a step further, and mount a new filesyetem on a non-empty directory - all the directory's content won't be counted: As root, create the directory structure: cd /tmp mkdir -p a a/b a/c a/d Now fill the "b" directory with a large file: dd if=/dev/zero of=a/b/bigfile bs=1M count=1 Before any mounts, "b" is counted: # du -x a 4 a/c 1028 a/b 4 a/d 1040 a Now create a temporary file system loop file, and mount it over "b": dd if=/dev/zero of=disk.img bs=1M count=10 mkfs.ext3 disk.img mount -o loop disk.img a/b Re-checking disk-usage, "b" is not even listed, and its content (1MB) is not counted: # du -x a 4 a/c 4 a/d 12 a --- To see why du skips it, you can check the Device-ID associated with each directory: # stat -c "%n Device-ID: %D Mount-Point: %m" a a/b a/c a/d a Device-ID: 812 Mount-Point: /tmp a/b Device-ID: 700 Mount-Point: /tmp/a/b a/c Device-ID: 812 Mount-Point: /tmp a/d Device-ID: 812 Mount-Point: /tmp Your device numbers will differ, but the number for "a/b" will not be the same as for the rest. When du sees a different device number, it simply skips the directory. Once unmounted, the device-id returns to the old value, and "a/b" will be counted with its content: # umount a/b # stat -c "%n Device-ID: %D Mount-Point: %m" a a/b a/c a/d a Device-ID: 812 Mount-Point: /tmp a/b Device-ID: 812 Mount-Point: /tmp a/c Device-ID: 812 Mount-Point: /tmp a/d Device-ID: 812 Mount-Point: /tmp As such, I'm closing this as "not a bug", but discussion can continue by replying to this thread. regards, - assaf
bug#33785: df: don't suppress remote mounts
tags 33785 notabug close 33785 stop Hello, On 2018-12-19 10:05 a.m., Pádraig Brady wrote: On 17/12/18 22:42, lzhong wrote: According to the following commit commit 2e81e62243409c5c574b899f52b08c000e4d99fd df: only suppress remote mounts of separate exports with --total [...] The remote mounts should not be suppressed after this change. However, it turns out it doesn't work as the message described. The remote mounts are still suppressed. And here is The intent of the patch was not to suppress _separate_ exports on the server. I.E. nas.example.com:/Photos and nas.example.com:/Download would not be suppressed (even if they have the same device id). If you want all nfs mounts you could `df -a -t nfs` With no further comments, I'm closing this as "notabug". Discussion can continue by replying to this thread. -assaf
bug#16282: revisit; reasoning for not using ENV vars to provide workarounds for POSIX limitations?
severity 16282 wishlist tags 16282 wontfix close 16282 stop (triaging old bugs) Hello, On 2013-12-28 1:03 p.m., Paul Eggert wrote: [...] if it makes a standard utility behave in odd ways, it'll break scripts that don't expect the odd behavior. That's the essential objection here. Yes, we've used env vars in the past for this, but we've come to regret it, and we don't want to make matters worse in this respect without a compelling justification. Given the above, and with no further comments in 5 years, I'm closing this bug. More details about the reasoning for rejecting new environment variables are summarized here: https://www.gnu.org/software/coreutils/rejected_requests.html#envvar regards, - assaf
bug#34110: feature request: dual-column du output, showing "real" and "on-disk" sizes (and about that "apparent-size" concept)
severity 34110 wishlist retitle 34110 du: add dual-column showing apparent-size and disk-size stop Hello, On 2019-01-17 3:13 a.m., René J.V. Bertin wrote: On Wednesday January 16 2019 16:06:50 Assaf Gordon wrote: I hope this helps to clarify "apparent-size". Yes and no :) I understand what "apparent-size" does [] My whole point is that there might be a better name. The parameter name "--apparent-size" is not likely to be changed. It has been named so for about 16 years (since 'fileutils 4.5.8' which is even before 'coreutils' was created as a unified package). Changing it would break existing scripts and user expectations. I realise that you cannot really call the content size observable "real size" when reporting from a disk-usage viewpoint, but "content size" (--content-size, -C) should be clear enough? Creating a second alias to "--apparent-size" is possible, but I'm not sure it's warranted. --- I think the discussion about "--apparent-size" is mostly concluded, but the idea to have two-columns is an interesting feature request. I'm marking this as a "wish list" item. Concrete patches are welcomed. regards, - assaf
bug#34115: coreutils v. 8.30– Document's content gets deleted using cat(1)
tags 34115 notabug close 34115 merge 34115 33823 stop Hello, On 2019-01-17 5:53 a.m., Ricky Tigg wrote: [...] $ cat > .inputrc set enable-bracketed-paste on Press *Return*, then *Ctrl D*. [...] Content of *.inputrc*, which is expected to be still present, has been This sounds very similar to the previous email you sent ( https://bugs.gnu.org/33823 ). As before, it is not a problem in "cat", but perhaps a problem in your GUI, X11, xterminal, or perhaps a problem in copy to the clipboard. regards, - assaf
bug#12820: FWIW, this is still happening as of gnulib 4a82904
close 12820 stop (triaging old bugs) Hello, On 2013-02-28 10:08 a.m., Paul Eggert wrote: Perhaps there's a bug in nap () but if so the bug should be fixed there. Given the above, and with no further comments in almost 6 years, I'm closing this bug. Discussion can continue by replying to this thread. - assaf
bug#13738: Add --all option to 'users' command
tags 13738 wontfix
close 13738
stop
(triaging old bugs)
Hello,
On 2013-02-18 2:01 p.m., Bob Proulx wrote:
anatoly techtonik wrote:
Bob Proulx wrote:
anatoly techtonik wrote:
The 'users' command shows users who are currently online. It will be nice
to have --all option to show all users.
Do you mean the equivelent to this?
$ getent passwd | awk -F: '{print$1}'
[]
Solving the problem in general gets messy very quickly. It is
therefore one of those that is better solved locally by providing the
tools needed to do what is needed on a case by case basis. So far
after forty years of Unix and GNU systems this hasn't been needed and
therefore the use cases must be unusual. The philosophy isn't to
solve all problems but just to make all problems solvable.
It would help if you could say a few words about the case in
which this would be helpful?
With no further comments in almost 6 years,
and this item already listed under our "rejected requests" page,
I'm closing this as "won't fix".
regards,
- assaf
bug#12339: Gnu rm, changed only recently (4-5 years), and didn't follow letter of posix...(statement follows)
close 12339 stop (triaging old bugs) Hello, This long and winding thread covers several topics relating to rm(1), historical unix and POSIX compatibility (and a bugfix or two in the mix). An enlightening read for those interested... ( https://bugs.gnu.org/12339 ) But the bottom line is: rm -rf . will not delete the content of the current directory (while keeping the directory itself) and that is not likely to change. Two suggested alternatives: find . -delete rm -rf * .[!.] .??* As such, and with no more comments in 6 years, I'm closing this bug. PLEASE do not reply to this thread. If there are other relevant issues (that have not been discussed elsewhere, and have not been previously rejected), please start a new thread by emailing coreut...@gnu.org . regards, - assaf
bug#9089: pipe failure with cat and head of coreutils 6.12
close 9089 stop (triaging old bugs) Hello, On 2011-07-15 5:30 a.m., Philipp Thomas wrote: I'm trying to track down a bug in cat of coreutils 6.12. Doing cat /var/log/Xorg.0.log | head -n70 under ksh consistently fails with 'cat: write error: Connection reset by peer'. It does not fail when run under bash and it does not fail in current coreutils . I'm still able to reproduce this problem (i.e. "cat: write error" with coreutils 6.12 under ksh on Linux 4.9.0). However, Given that it is has been seven and a half years ago since the last comment, and even then it was already acknowledged that the problem does not happen in later versions, and it happens because ksh uses socketpairs instead of pipes - I'm closing this bug. If the issue of cat(1) supporting socketpair/ECONNRESET instead of pipes/EPIPE is still relevant, we can re-open the bug. regards, - assaf
bug#33718: Syntaxe problem? I can't find the solution :-(
tags 33718 moreinfo stop Hello, On 2018-12-13 1:54 a.m., Rudy BROSTEAUX wrote: Environment: AIX 7.2 TL3 SP1 (on IBM Power Systems) Origin of the coreutils RPM used @release 8.30 is perzl.org Installed using a yum server. *** /root> /usr/bin/time timeout 2.3 sleep 5 timeout: warning: timer_create: Invalid argument From: Bernhard Voelker No idea. For an analysis, we need more information: timeout version, OS/kernel version, and finally of course a reproducer, i.e., the exact command line you were using. timeout works well here: $ /usr/bin/time -f '%e' timeout 2.3 sleep 4.5 Command exited with non-zero status 124 2.30 I tested coreutils-8.30 built from source on AIX 7.2, both 64 bit and 32 bit, and both work fine: $ file src/timeout src/timeout: 64-bit XCOFF executable or object module not stripped $ /usr/bin/time ./src/timeout 2.3 sleep 5 Real 2.31 User 0.00 System 0.00 $ file src/timeout src/timeout: executable (RISC System/6000) or object module not stripped $ /usr/bin/time ./src/timeout 2.3 sleep 5 Real 2.30 User 0.00 System 0.00 Perhaps it is a problem in the RPM package? Please try to build from source code and see if you see experience the issue. regards, - assaf
bug#12400: rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...
retitle 12400 rmdir: add --one-file-system option
severity 12400 wishlist
tags 12400 wontfix
stop
(triaging old bugs)
Hello,
On 2012-09-09 11:22 p.m., Bob Proulx wrote:
Linda Walsh wrote:
If you are going to only provide 1 mode of functionality, it should
be to only rmdir dirs on the same file system as the starting args.
[...]
But rmdir only removes the directories you tell it to remove.
[...]
If you want a recursive option why not use 'rm -rf'?
There is always 'find' with the -delete option. But regardless there
has been the find -exec option.
find /some/path -type d -delete
find /some/path -depth -type d -exec rmdir {} +
With no further comments in 6 years, I'm closing this
request.
regards,
- assaf
bug#33646: [PATCH] doc: improve wording of the --kibibytes option description
Hello,
On 2018-12-06 6:32 a.m., Kamil Dudka wrote:
Bug: https://bugzilla.redhat.com/1527391
---
doc/coreutils.texi | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index f8339d73f..e93fe71a0 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7975,9 +7975,11 @@ Append @samp{*} for executable regular files, otherwise
behave as for
@opindex --kibibytes
Set the default block size to its normal value of 1024 bytes,
overriding any contrary specification in environment variables
-(@pxref{Block size}). This option is in turn overridden by the
-@option{--block-size}, @option{-h} or @option{--human-readable}, and
-@option{--si} options.
+(@pxref{Block size}). If @option{--block-size}, @option{-h},
+@option{--human-readable}, or @option{--si} options are used,
+they take precedence over @option{-k} or @option{--kibibytes}
+even if @option{-k} or @option{--kibibytes} is placed after
+the other options.
The @option{-k} or @option{--kibibytes} option affects the
per-directory block count written by the @option{-l} and similar
I'm ok with this improvement - if there are no comments
I'll push in the next few days.
-assaf
bug#33211: coreutils.mo is in both LC_TIME and LC_MESSAGES folders
tags 33211 notabug close 33211 stop Hell0, On 2018-10-30 3:33 p.m., scootergrisen wrote: I wonder if its a mistake that in Fedora i can see coreutils.mo in both: /usr/share/locale/*/LC_TIME /usr/share/locale/*/LC_MESSAGES They seem to be identical. This is not a mistake (nor a bug). Not only they are identical, one is a symlink to the other: $ cd /usr/local/share/locale/ca $ ls -log LC_*/coreutils.mo -rw-r--r-- 1 379478 Dec 27 22:47 LC_MESSAGES/coreutils.mo lrwxrwxrwx 1 27 Dec 27 22:47 LC_TIME/coreutils.mo -> ../LC_MESSAGES/coreutils.mo coreutils.mo is the only file i see in the /usr/share/locale/*/LC_TIME folder. Most programs that use gettext (https://www.gnu.org/software/gettext/) are concerned with user visible messages, hence most of the translation only use LC_MESSAGES directory, and there's no need for other files. Few coreutils programs (e.g. date, sort) do care about translation of time-related strings (e.g. days / month names). That's why coreutils also uses LC_TIME. One can ask for the date/time to use one local, and messages to use another: $ export LC_TIME=ru_RU.UTF-8 $ export LANGUAGE=ja_JP.UTF-8 $ date Пт янв 18 01:06:10 MST 2019 $ date -d ABCD date: `ABCD' は無効な日付です Should the /usr/share/locale/*/LC_TIME/coreutils.mo files be removed so there is only the /usr/share/locale/*/LC_MESSAGES/coreutils.mo files? No, Both should exist, otherwise setting LC_TIME won't work. Technically, the translated strings for both messages and time are stored in the same file - that's why when coreutils is installed, one is a symlink to the other. Even more technically, when building from source, the file "bootstrap.conf" contains the following: # Other locale categories that need message catalogs. EXTRA_LOCALE_CATEGORIES=LC_TIME The directory "./po" is populated with available translation (e.g. "ru.po" and "ja.po"). During the build, the ".po" files are compiled into binary ".gmo" files. During installation, the files are copied/symlinked: $ make install [...] make[2]: Entering directory '/home/gordon/projects/coreutils/po' installing af.gmo as /usr/local/share/locale/af/LC_MESSAGES/coreutils.mo installing af.gmo link as /usr/local/share/locale/af/LC_TIME/coreutils.mo installing be.gmo as /usr/local/share/locale/be/LC_MESSAGES/coreutils.mo installing be.gmo link as /usr/local/share/locale/be/LC_TIME/coreutils.mo [...] Hope this addresses the issue. I'm closing this as "not a bug", but discussion can continue by replying to this thread. regards, - assaf
bug#33371: RFC: option for numeric sort: ignore-non-numeric characters
tags 33371 notabug close 33371 stop Hello, On 2018-11-18 6:08 p.m., L A Walsh wrote: On 11/14/2018 12:27 AM, Erik Auerswald wrote: Perhaps --version-sort could work for you? "-V" seems like it might be sufficient, Given the above, I'm closing this item. regards, - assaf
bug#23896: ls incorrectly shows quotes when listing file names with spaces
Hello, On 2016-07-05 3:20 a.m., Ruediger Meier wrote: On Monday 04 July 2016, Pádraig Brady wrote: On 04/07/16 19:11, Shamim Islam wrote: Description of problem: Terminal sessions display quotes for files with spaces in them. This is non-intuitive behavior. The file name does not have quotes unless quotes have been used in the filename. The coreutil ls has been updated to default to this new behavior. This behavior should not be foisted on users but users should be allowed to choose whether they want to OPT IN. Debian and Ubuntu distros have already reverted. We created a summary of common issues and FAQs regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#33433: Bug in directory listing display
Hello, On 2018-11-19 10:49 a.m., Brian Hartvigsen wrote: Items with spaces are incorrectly listed surrounded by single quotes. This is problematic for a number of reasons. One of which is that files or directories that contain a mix of quotes in their titles are now displayed incorrectly. This bug also breaks existing scripts all over the place. We created a summary of common issues and FAQs regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#33577: ls lacks null terminator option
tags 33577 notabug severity 33577 wishlist retitle 33577 doc: mention find/stat in ls documentation stop Hello, On 2018-12-05 4:39 a.m., 積丹尼 Dan Jacobson wrote: Fine. Put a message on top of (info "(coreutils) ls invocation") saying that your pipes are better. Given the suggested solution from Bob and Bernhard, I'm marking this as a wishlish (todo) item to improve ls's documentation. regards, - assaf
bug#26991: New quoting takes up unnecessary space
Hello, On 2017-05-19 6:37 p.m., L A Walsh wrote: Pádraig Brady wrote: On 19/05/17 07:48, L A Walsh wrote: The new format uses extra spacing on columns where it isn't needed -- but the extra space isn't enough to handle the 1 file that was quoted (needs 5 extra columns). Where does it get '3' (and why doesn't it use 2?)? We created a summary of common issues and FAQs regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#22580: shell-escape in tty in ls
Hello, On 2016-02-07 12:44 a.m., Pádraig Brady wrote: On 06/02/16 20:28, Paul Vint wrote: Maybe I'm the only one, but the new change in ls seems bad: set_quoting_style (NULL, shell_escape_quoting_style); This is set if the output is a TTY. Why would we want to quote if the output is a TTY? It makes the output appear strange to me. We created a summary of common issues and FAQ regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#24926: ls output has been made ugly
Hello, On 2016-11-12 5:27 a.m., Rüdiger Meier wrote: On Friday 11 November 2016 21:00:23 Eric Blake wrote: On 11/11/2016 12:26 PM, Paul Eggert wrote: Michael Schwager wrote: Don't you think I can see the spaces in my filenames? We created a summary of common issues and FAQs regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#22696: ls output changes considered unacceptable
Hello, On 2016-02-17 9:46 a.m., Mike Hodson wrote: On Tue, Feb 16, 2016 at 6:45 AM, Bernhard Voelker wrote: On 02/16/2016 11:50 AM, Jason A. Donenfeld wrote: [...] We don't want those single quotes. We created a summary of common issues and FAQ regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#25388: Bug in ls, kills existing scripts reading "ls" -1 as input
Hello, 'ls' did not recently add any more cases where tty output differs from non-tty output when all other things are equal in the default state. All that changed was that tty output is formatted differently than it has been in the past. We created a summary of common issues and FAQs regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#31353: ls unexpectedly quoting filenames
Hello, On 2018-05-02 8:38 p.m., billy noah wrote: In a clean installation of Ubuntu 18.04 suddenly ls has defaulted to quoting filenames with tilde ~, spaces and other characters which may require escaping. Some extended discussion can be found here: https://unix.stackexchange.com/questions/258679/why-is-ls-suddenly-wrapping-items-with-spaces-in-single-quotes We created a summary of common issues and FAQs regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#33048: ls wrapping items with spaces in single quotes
Hello, We created a summary of common issues and FAQs regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#33157: QUOTING_STYLE change of default
Hello, On 2018-10-25 3:45 p.m., Arvid Requate wrote: after updating to Debian buster I had the impression that my eyes are failing on me. This posting pretty much summarizes my opinion: http://lists.gnu.org/archive/html/coreutils/2016-02/msg1.html especially the first paragraph: We created a summary of common issues and FAQs regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#25078: ls 8.26: discrepancy between `ls' and `ls -1' in the alignment of quoted and nonquoted items
Hello, On 2018-12-13 5:18 p.m., Zhiming Wang wrote: On Dec 13, 2018, at 3:27 PM, Assaf Gordon wrote: https://www.gnu.org/software/coreutils/quotes.html - The page doesn't seem to be linked from anywhere; not the coreutils FAQ, not the manual. So discoverability seems rather poor? Initially we'll mention it in replies that directly address this issue. After a bit more feedback, we might link it in the main page (similar to the FAQ). - Under "The quotes break my scripts! This is a serious regression.", there's a link to https://bugs.gnu.org/25388#11, which is a rant with some misinformation and barely even touches breaking scripts Thanks, I changed it to a different message in the same thread. regards, - assaf
bug#33786: Bug: undocumented feature (algorithm) for version-sort (include on manpage)
tags 33786 notabug severity 33786 wishlist retitle 33786 doc: sort: document Debian's version-sort algorithm stop Hello, On 2018-12-18 12:11 a.m., L A Walsh wrote: meaning that if one is going to put a Debian sort into a general purpose tool like "sort", then the algorithm really needs to be documented. It is well documented in many places online, e.g.: https://www.debian.org/doc/debian-policy/ch-controlfields.html#version https://readme.phys.ethz.ch/documentation/debian_version_numbers/ With a shorter summary available in the coreutils manual here: https://www.gnu.org/software/coreutils/manual/html_node/Details-about-version-sort.html#Details-about-version-sort This means there is no way to verify consistent behavior from as the utility matures The sort-version.sh test ensure the behavior is consistent from one release to the next: https://opengrok.housegordon.com/source/xref/coreutils/tests/misc/sort-version.sh It also ensures the behavior is compatible with Debian's definition. and no way to write an independent, auditable test case to assure that the sort algorithm, operates with consistency from release to release as well as w/r/t other included sort algorithms. This message contains example of how to compare results between coreutils' sort and debian's utilities: https://lists.gnu.org/archive/html/bug-coreutils/2018-11/msg00017.html Here's a post about doing the same using python: https://stackoverflow.com/a/4957741 And in NodeJS: https://www.npmjs.com/package/deb-version-compare I'm sure there are many other implementations that allow easy comparison of one against the other to quickly find any discrepancies. As for auditable code, the actual code is here (part of gnulib): https://opengrok.housegordon.com/source/xref/gnulib/lib/filevercmp.c And gnulib also includes a unit-test: https://opengrok.housegordon.com/source/xref/gnulib/tests/test-filevercmp.c There's no better audit-ability than the source code itself. The request here is for the algorithm used by 'version-sort' be included in sort's manpage. This should document sort's features for reference and use by users who are using the utility in its native, cmd-line environment. If a coreutils' program implements a known standard, it's not necessarily beneficial to include implementation details of the standard, as this is available elsewhere. For example, the manual for the "base64" program does not include an explanation of what base64 is. Instead, it links to RFC4648: https://www.gnu.org/software/coreutils/manual/html_node/base64- invocation.html#base64-invocation As your request is for a change in documentation, I'm marking this as a wish-list item. As always, concrete patches are welcomed and they go a long way towards expediting any desired changes - if you have suggestions please do send a patch. Also of importance: that the documentation should be include with the source and installable with the program executable. When someone downloads coreutils' source, they automatically get the manual (in texinfo format, easily convertible to HTML/PDF). When they install coreutils (e.g. "make install"), the manual is also installed (as an "info" file). regards, - assaf
bug#33786: Bug: undocumented feature (algorithm) for version-sort (include on manpage)
Hello, On 2018-12-18 1:06 a.m., L A Walsh wrote: So undocumented features are considered wishlist items in Gnu? In your message you wrote: On 2018-12-18 12:11 a.m., L A Walsh wrote: The request here is for the algorithm used by 'version-sort' be included in sort's manpage. Thus it is a request for a future improvement - not a report about a bug in an existing program or a bug (=incorrect information) in the current manual. In the parlance of the DebBugs system, it is a "wishlist" item (as opposed to a bug), see here: https://debbugs.gnu.org/Developer.html#severities This item remains open ( https://bugs.gnu.org/33786 ). It is not closed as "notabug", and not rejected as "wontfix". Thus, it will stay active until someone takes the time to address the issue of documenting the algorithm, or until it is decided that there's no interest in such change. --- Regarding "undocumented feature", as I wrote in the previous message, the algorithm is well documented in other place online (and indeed, as you pointed, not documented in exact details in the coreutils manual). I think this is quite different from the typical definition of an "undocumented feature" (e.g. a hidden feature that is not intended to be used by most end-users). --- Then again, If you or anyone else have concrete suggestions to improve the manual, please do send a patch. regards, - assaf
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
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
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#33824: coreutils v.8.30 – An expression part of a cat command is interpreted as "ambiguous redirect" when applied to a target.
tags 33824 notabug close 33824 stop Hello, On 2018-12-21 8:32 a.m., Ricky Tigg wrote: Command executed: $ cat a* >> b* bash: b*: ambiguous redirect Thought the same syntax is used with success when applied only to source files: $ cat a* >> b $ Probably a bug. This is not a bug - it is the result of the shell (not cat) performing glob-expansion (i.e. the "b*" string expands multiple existing files whose name starts with "b"). Consider the following example: $ touch b1 b2 b3 $ echo > b* -bash: b*: ambiguous redirect As such, I'm closing this as "notabug". Discussion can continue by replying to this thread. -assaf
bug#33622: coreutils v. 8.30 – Tail prints the first row in 'tail -n '
tags 33622 notabug close 33622 stop Hello, On 2018-12-05 5:49 a.m., Kamil Dudka wrote: On Wednesday, December 5, 2018 11:51:09 AM CET Ricky Tigg wrote: OS: *Fedora*. Component: coreutils.x86_64 8.30-6.fc29 @System Tail prints the first row in 'tail -n ' Command executed: $ dnf repoquery --requires bash --recursive --resolve | grep -E '.x86_64$|.noarch$' | tail -n 1 Last metadata expiration check: 0:28:25 ago on Wed Dec 5 11:09:16 2018. tzdata-0:2018g-1.fc29.noarch Expected result: command to only print N rows, which means without printing the first row. The line "Last metadata expiration check: [...]" is not printed by tail at all. It is printed by dnf to standard _error_ output. You will see it even if you redirect dnf's standard output to /dev/null: $ dnf repoquery --requires bash --recursive --resolve >/dev/null Last metadata expiration check: [...] You can use `dnf --quiet ...` to suppress the message. Thank you Kamil for explaining the issue. I'm closing this as "notabug". -assaf
bug#33775: fold: counting multi-byte utf-8 sequences as separate columns
severity 33775 wishlist retitle 33775 multibyte: fold: multi-byte sequences as separate columns stop Hello, On 2018-12-16 6:32 p.m., Michael Siegel wrote: I've just discovered an odd behavior of `fold' while trying to wrap a piece of text containing phonetic characters. Take the following line, for example: Thank you for reporting this issue and providing clear, reproducible examples. Adding complete multibyte/utf8 support to all coreutils programs is an on-going effort. I'm marking this as a "wishlist" item, which will remain open until we complete the implementation. Related multibyte items are listed here (with "multibyte" prefix): https://debbugs.gnu.org/cgi/pkgreport.cgi?which=pkg=coreutils regards, - assaf
bug#33823: coreutils v.8.30 – Command, pasted from text editor to GUI terminal, not displayed though applied
tags 33823 notabug close 33823 stop Hello, On 2018-12-21 8:06 a.m., Ricky Tigg wrote: Paste it to a text editor keeping a *mono-space* font as font applied to text. From text editor copy that same pattern. Paste it into terminal as new command. Press *Enter*-key. End file (*Ctrl D*). [...] Pasted text content 'A' is not exhibited. Thought once queried it does exist. Probably a bug. This might be a bug in your terminal or a configuration issue in the clipboard of your X system - but it is not a bug in coreutils (the cat(1) program did what you asked it to do). As such I'm closing this as "notabug", but discussion can continue by replying to this thread. -assaf
bug#33281: head does not consume input after '-c' is satisfied
tags 33281 wontfix severity 33281 wishlist close 33281 stop Hello, On 2018-11-06 12:52 p.m., Paul Eggert wrote: On 11/5/18 1:17 PM, Philip Rowlands wrote: To achieve consistency in the other direction, head could ignore the optimization to reduce the number of bytes read, and always read 8192 bytes, knowing that some would be discarded. Let's not do that. It's less efficient and less useful than what GNU 'head -c4' is doing now. For widely differing values, the only way to produce the same residual output would be to consume all input data. Eeuuww. Let's *especially* not do that. Given the above, I'm closing this as "wontfix". Discussion can continue by replying to this thread. -assaf
bug#33727: File system unrecognized
Hello, On 2018-12-13 8:18 a.m., Jeroen De Vries wrote: tail: unrecognized file system type 0x794c7630 for '/opt/openhab2/userdata/logs/events.log'. please report this to bug-coreutils@gnu.org. reverting to polling Thank you for the report. This has been fixed in coreutils version 8.25 - meaning you are likely using an older version. For more details, see here: https://www.gnu.org/software/coreutils/filesystems.html regards, - assaf
bug#25078: ls 8.26: discrepancy between `ls' and `ls -1' in the alignment of quoted and nonquoted items
Hello, On 2016-11-30 7:12 p.m., Zhiming Wang wrote: On Nov 30, 2016, at 8:41 PM, Paul Vint wrote: The alignment change is helpful, but I do have an argument against doing the same in the -1 case: It breaks something many of us have done in scripts. It breaks nothing. Quoting and alignment by default only happens when stdout is a tty. Also, ls prints one entry per line when stdout is not a tty; you don't even need -1. We created a summary of common issues and FAQs regarding the quoting change in ls(1): https://www.gnu.org/software/coreutils/quotes.html If there is an issue that is not addressed there, please send an email to coreut...@gnu.org . regards, - assaf
bug#33408: tail: unrecognized file system type 0xfe534d42
Hello, On 2018-11-16 2:34 p.m., Chakra Srivatsa wrote: The filesystem in question is ZFS. tail: unrecognized file system type 0xfe534d42 for 'stdout.txt'. please report this to bug-coreutils@gnu.org. reverting to polling Thanks for the report. It seems the filesystem is actually smb2 (id 0xfe534d42). This has been fixed in version 8.26. For more details, see: https://www.gnu.org/software/coreutils/filesystems.html regards, -assaf
bug#31554: acknowledged by developer (Re: bug#31554: Fwd: Re: Potential bug in md5sum)
Hello Bill, On 2018-11-18 2:37 p.m., Riedy, Bill wrote: The wording is vague, could you please clarify which of the following are true: 1) That you recognize this as a bug and it is going to be fixed 2) That you recognize this as a bug but it will NOT be fixed 3) Some other scenario that I can't think of, but you may have. The original forwarded messaged said the following: "md5sum is a part of the GNU coreutils package, [...] It was ported by the gnuwin32 Project to Windows: [...] The cause of the error you've reported is probably the fact the gnuwin32 version of md5sum is from April 21, 2005." ( https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31554#5 ) Later, Paul replied: "Could be, but this doesn't look like it's relevant to the current codebase for GNU coreutils. 2005 was a looong time ago." ( https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31554#8 ) After which I've closed the bug report. The meaning is: The reported problem is happening on a very old version of the program (from 2005 - 13 years old), and using a port (GnuWin32) which GNU coreutils developers did not create and can't easily provide support. As such, there is no point in investigating further. It could be a bug in the (very old) version, or it could be another problem. If you can reproduce the bug in a recent version (the current is 8.30). then there would be more incentive to investigate (though once again, the GnuWin32 is provided by others, and we can not easily support it). regards, - assaf
bug#22022: ls - error making symbolic links with relative paths
retitle 22022 ln: error making symbolic links with relative paths tags 22022 notabug close 22022 stop Hello, On 2015-11-26 9:13 p.m., Eric Blake wrote: [...] You may be interested in trying 'ln --relative -sv b/* c/' instead, which creates 'c/a' as a symlink to '../b/a', and therefore resolves rather than creating a dangling symlink. With no further comments to Eric's suggestion, I'm assuming this is resolved. Discussion can continue by replying to this thread. regards, - assaf
bug#34009: warn that mkdir --mode doesn't affect parents created
severity 34009 wishlist retitle 34009 doc: mkdir: warn that --mode doesn't affect parents stop Hello, On 2019-01-07 8:36 a.m., 積丹尼 Dan Jacobson wrote: do warn that --mode doesn't affect any parents created. $ mkdir --mode 700 -p /tmp/g/h/i $ find /tmp/g -ls 55795 0 drwxr-xr-x 3 jidanni jidanni60 Jan 7 23:30 /tmp/g 55796 0 drwxr-xr-x 3 jidanni jidanni60 Jan 7 23:30 /tmp/g/h 55797 0 drwx-- 2 jidanni jidanni40 Jan 7 23:30 /tmp/g/h/i Also warn on (info "(coreutils) mkdir invocation") more directly. Thanks. The info manual does contain a short sentence about parents' modes: "To set the file permission bits of any newly-created parent directories to a value [...]" But this can be improved. Marking as wishlist. Patches are welcomed. regards, - assaf'
bug#33204: Failed to modify 'Access Time' for files without extension using the Touch tool ver 8.4
close 33204 stop Hello, On 2018-10-31 7:10 a.m., Eric Blake wrote: On 10/30/18 3:49 AM, ˮ��֮�� wrote: HI,Dear developer of GNU tools： I found a possible bug when using the Touch tool. Most likely, this is not a bug in coreutils, but a limitation between the operating system and file system you are using. If it is a GNU/Linux system, using strace would confirm that. But since you did not give us those details, it's hard to say if there's anything further we can do to help you. With no further replies, I'm closing this bug. regards, - assaf
bug#32291: Fwd: ls -ltcr and ls -lrt report different modification dates
tags 32291 notabug close 32291 stop Hello, Seems your message was not replied to in 6 months - sorry about that. On 2018-07-27 3:48 a.m., Ludovic Tolhurst-Cleaver wrote: `ls -ltcr` seems to be the one showing the correct date here. I like to use `ls -ltc` because it's my initials. My colleague was running `ls -lrt`. $ ls -ltcr ludo* -rw-rw-rw- 1 pax pax 237817 Jul 20 06:53 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz $ ls -lrt ludo* -rw-rw-rw- 1 pax pax 237817 Jul 18 12:30 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz The manual explains the "-c" option: === $ ls --help -c with -lt: sort by, and show, ctime (time of last modification of file status information); === What you are seeing is the file's status-change timestamp (with "-c") versus the file's content modification timestamp (without "-c"). You can view all timestamps at once with: stat ludo* As such, I'm closing this as "not a bug", but discussion can continue by replying to this thread. regards, - assaf
bug#20775: cp -a -u destroys files after they are copied
severity 20775 wishlist retitle 20775 cp: improve hardlink dups handling with "cp -a -u" stop With no further comments in more than 3 years, I'm marking this as a "wish list" item. -assaf
bug#15727: Bug: cp <-a|-archive> (w/<-f|--remove-destination>) breaks if one of files is a dir and other not
severity 15727 wishlist retitle 15727 doc: cp: expand dirs-vs-files with -f/--remove-dest stop Hello, On 2013-10-29 12:20 p.m., Linda Walsh wrote: [...] You need to make the docs much more clear about "cp"s limitations. update isn't eally update, and -T is certainly wrong at the very least. If you feel you'd rather document cp's limitations, that's fine... cp is a great tool, don't get me wrong! But when it added update and -T, --remove-destination, it started inferring or promising more than you were willing to deliver. That should be documented. Based on the above (as the result of the long discussion), I'm marking this as a documentation wish-list item: clarify that "-f" and "--remove-destination" won't replace a file with a directory (as explained by Pádraig and Bernhard in the thread). Similarly for related limitations of "-T". regards, - assaf
bug#25159: chown bug ? or sys glitch ?
close 25159 stop On 2018-10-28 1:35 a.m., Assaf Gordon wrote: On 2016-12-10 6:51 a.m., ahfc wrote: Maybe a system glitch or a chown bug so just fyi. [...] chown: changing ownership of ‘/run/media/rest_/of_/path_/filename ': Operation not permitted If this is still an issue for you, can you provide more details, in particular what is the file system on /run/media ? With no further replies, I'm closing this bug. regards, - assaf
bug#29285: Error building coreutils 8.28.32-a4eed under Archlinux from AUR
close 29285 stop On 2018-10-29 8:09 p.m., Assaf Gordon wrote: On 2017-11-13 7:43 a.m., timofonic timofonic wrote: As the coreutils build system reported, I'm sending the following building error from using the coreutils-git Arch User Repository package ( https://aur.archlinux.org/packages/coreutils-git/) Do you still get similar failure with more recent coreutils versions? With no further replies, I'm closing this bug. regards, - assaf
bug#34026: mention that long options aren't always as good as short options
severity 34026 wishlist retitle 34026 doc: explain long-vs-short options stop Hello, On 2019-01-09 9:23 p.m., 積丹尼 Dan Jacobson wrote: Yes do warn in the manual, as here root (so no $HOME) expected tilde expansion... Thanks. I'm marking this as a wish-list item. If we are to add a section dedicated to options parsing, it's worth noting related discussion about using two dashes to stop processing ( http://bugs.gnu.org/33942 ), and some similar section in the guile manual: https://www.gnu.org/software/guile/manual/html_node/Command-Line-Format.html regards, - assaf
bug#15328: Bug or dubious feature?
tags 15328 notabug close 15328 stop Hello, On 2013-09-10 3:01 p.m., Linda Walsh wrote: Whatever the problem is, it's not in 'mv'... Given the above, and no further comments in 5 years, I'm closing this item. regards, - assaf
bug#33468: A bug with yes and --help
Hello Berny and all, On 2018-11-29 1:48 a.m., Bernhard Voelker wrote: The attached are quite raw attempts to address this - yes, as a function instead of a macro. ;-) * [PATCH] long-options: add parse_gnu_standard_options_only gnulib patch! For the gnulib patch, I believe the following is needed: diff --git a/lib/long-options.c b/lib/long-options.c index 52ef1f2f8..9567d5135 100644 --- a/lib/long-options.c +++ b/lib/long-options.c @@ -139,7 +139,7 @@ parse_gnu_standard_options_only (int argc, /* Restore previous value. */ opterr = saved_opterr; - /* Reset this to zero so that getopt internals get initialized from + /* Reset this to one so that getopt internals get initialized from the probably-new parameters when/if getopt is called later. */ - optind = 0; + optind = 1; } Otherwise many things fail like so: $ ./src/dd ./src/dd: unrecognized operand ‘./src/dd’ Try './src/dd --help' for more information. The "1" value matches the instructions in the getopt_long(3) man page. * [PATCH] all: detect --help and --version more consistently [FIXME] FIXME: NEWS, syntax-check, tests. With the above 'optind=1' change, there are only two major differences: --- $ nohup-8.30 -/ ; echo $? nohup: invalid option -- '/' Try 'nohup --help' for more information. 125 $ ./src/nohup -/ ; echo $? src/nohup: invalid option -- '/' Try 'src/nohup --help' for more information. 1 $ dd-8.30 -- if=/dev/null 0+0 records in 0+0 records out 0 bytes copied, 3.9014e-05 s, 0.0 kB/s $ ./src/dd -- if=/dev/null ./src/dd: unrecognized operand ‘--’ Try './src/dd --help' for more information. --- Which in turn cause "tests/misc/invalid-opt", "tests/misc/usage_vs_getopt", and "tests/dd/misc" to fail. All other test pass as before (tested only on Debian Stretch). regards, - assaf P.S. https://bugs.gnu.org/29617 "seq: `seq 1 --help' doesn't give help" will also likely be fixed by your patch.
bug#33468: A bug with yes and --help
Hello Eric, On 2019-01-12 8:42 a.m., Eric Blake wrote: On 1/11/19 6:23 PM, Assaf Gordon wrote: - optind = 0; + optind = 1; Ouch. You're hitting the portability problem of the difference between BSD and glibc. Otherwise many things fail like so: $ ./src/dd ./src/dd: unrecognized operand ‘./src/dd’ Try './src/dd --help' for more information. That's the symptoms on BSD for optind = 0 (there, you HAVE to use optreset=optind=1 for a complete reset; or plain optind=1 for a soft reset where the man page is not clear if it will always work). But on glibc, optind=1 does a soft reset (works if the optstring does not start with '-' or '+' and if you did not change POSIXLY_CORRECT), but MUST use optind = 0 if you want a hard reset. I only tested on Debian Stretch (with Debian GLIBC 2.24-11+deb9u3), did not yet test on BSDs. With "optind=1", I see the following: === $ ./src/hostid ec68f06c $ ./src/sleep ./src/sleep: missing operand Try './src/sleep --help' for more information. $ ./src/uptime 11:14:05 up 23 days 21:23, 4 users, load average: 1.16, 1.05, 0.52 $ ./src/users gordon gordon gordon gordon $ ./src/nohup ./src/nohup: missing operand Try './src/nohup --help' for more information. $ ./src/dd ## waits for CTRL-C ^C 0+0 records in 0+0 records out 0 bytes copied, 1.10243 s, 0.0 kB/s $ ./src/yes | head -n1 y === With "optind=0" I see the following: === $ ./src/hostid ./src/hostid: extra operand ‘./src/hostid’ Try './src/hostid --help' for more information. $ ./src/sleep ./src/sleep: missing operand Try './src/sleep --help' for more information. $ ./src/users $ ./src/users | od -tx1 000 02 e2 03 0a 004 $ ./src/users /var/log/wtmp ./src/users: extra operand ‘/var/log/wtmp’ Try './src/users --help' for more information. $ ./src/nohup ./src/nohup: ignoring input and appending output to 'nohup.out' ^C $ ./src/dd ./src/dd: unrecognized operand ‘./src/dd’ Try './src/dd --help' for more information. $ ./src/yes | head -n1 ./src/yes === Perhaps "parse_gnu_standard_options_only" should use "_getopt_long_r" and avoid the need to reset anything? regards, - assaf
bug#32250: ls -explain better the different times
Hello,
On 2018-07-23 9:54 a.m., kalle wrote:
in the documentation of ls the concept of the different times is not
explained sufficiently well (mtime, atime, ctime).
The dedicated file-timestamp section (
https://www.gnu.org/software/coreutils/manual/html_node/File-timestamps.html
) is indeed perhaps a bit too dense (lots of text
with no quick examples).
Attached is an improvement suggestion, adding a summary table,
and details examples.
Comments and feedback welcomed,
- assaf
>From f5774f87df4af912fd826f3d4208c9cd766e7524 Mon Sep 17 00:00:00 2001
From: Assaf Gordon
Date: Sun, 30 Dec 2018 20:28:28 -0700
Subject: [PATCH] doc: expand file timestamp section (atime,ctime,mtime)
Requested by kalle in
https://bugs.gnu.org/32250 .
* doc/coreutils.texi (File timestamps): Add summary table and examples.
---
doc/coreutils.texi | 279 +
1 file changed, 279 insertions(+)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index fd6d578ac..56831e46a 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -18877,6 +18877,132 @@ copy of the file, including the new permissions value. Another
operation that modifies a file's ctime without affecting the others is
renaming.
+@multitable @columnfractions .25 .25 .25 .25
+
+@headitem
+@tab Access Time
+@tab Modify Time
+@tab Change Time
+
+@item abbreviation
+@tab @code{atime}
+@tab @code{mtime}
+@tab @code{ctime}
+
+@item Updated when
+@tab content read
+@tab content modified
+@tab meta-data modified @*(e.g., permissions, owner, file name)
+
+@headitem Files @c{second line in next headitem}
+@tab Access Time
+@tab Modify Time
+@tab Change Time
+
+@headitem Affected by:
+
+@item @command{touch}
+@tab yes
+@tab yes
+@tab yes
+
+@item @command{touch -a}
+@tab yes
+@tab no
+@tab yes
+
+@item @command{touch -m}
+@tab no
+@tab yes
+@tab yes
+
+@item @command{chmod}
+@tab no
+@tab no
+@tab yes
+
+@item @command{chown}
+@tab no
+@tab no
+@tab yes
+
+@item @command{mv}
+@tab no
+@tab no
+@tab yes
+
+@headitem Directories @*Affected by:
+
+@item Listing files
+@tab yes
+@tab no
+@tab no
+
+@item Creating a new file
+@tab no
+@tab yes
+@tab yes
+
+@item Renaming a file
+@tab no
+@tab yes
+@tab yes
+
+@item meta-data changes to a file inside the directory
+@tab no
+@tab no
+@tab no
+
+
+@headitem @c{add a space for cleaner visuals }
+
+@headitem Running @command{cp SRC DST}:
+@tab Access Time
+@tab Modify Time
+@tab Change Time
+
+@item Changes to @file{SRC}
+@tab yes
+@tab no
+@tab no
+
+@item Changes to @file{DST}
+@tab yes
+@tab yes
+@tab yes
+
+@headitem Running @*@command{cp -p SRC DST}:
+@item Changes to @file{SRC}
+@tab no
+@tab no
+@tab no
+
+@item Changes to @file{DST}
+@tab (same as @file{SRC})
+@tab (same as @file{SRC})
+@tab yes @* (set to current time)
+
+@headitem Displaying timestamps
+@item Show with @command{ls} option
+@tab @option{-l -u}
+@tab @option{-l}
+@tab @option{-l -c}
+
+@item @command{stat} @option{-c} format @*(human readable)
+@tab @option{%x}
+@tab @option{%y}
+@tab @option{%z}
+
+@item @command{stat} @option{-c} format @*(seconds since epoch)
+@tab @option{%X}
+@tab @option{%Y}
+@tab @option{%Z}
+
+@end multitable
+
+@*
+@*
+
Naively, a file's atime, mtime, and ctime are set to the current time
whenever you read, write, or change the attributes of the file
respectively, and searching a directory counts as reading it. A
@@ -18920,6 +19046,159 @@ and microsecond resolution for the primitive that @command{touch} uses
to set a file's timestamp to an arbitrary value.
+@unnumberedsec Timestamp examples
+
+These two shell functions (@code{lstime} and @code{stattime}) will be
+used in the following examples to show the three timestamps (access, modify,
+change times) of a file:
+
+@example
+lstime()
+@{
+ printf "Access (read): " ; ls -log -u "$1" ;
+ printf "Modify (data): " ; ls -log"$1" ;
+ printf "Change (meta): " ; ls -log -c "$1" ;
+@}
+
+stattime()
+@{
+ stat --printf "File name: %n\n" "$1" ;
+ stat --printf " Access (read): %x\n" "$1" ;
+ stat --printf " Modify (data): %y\n" "$1" ;
+ stat --printf " Change (meta): %z\n" "$1" ;
+@}
+@end example
+
+@iftex
+@exdent
+@end iftex
+Starting with an empty directory, create a new file (@file{myfile})
+then examine its time stamps (which will be all identical):
+
+@example
+$ touch myfile
+
+$ lstime myfile
+Access (read): -rw-r--r-- 1 0 Dec 30 00:01 myfile
+Modify (data): -rw-r--r-- 1 0 Dec 30 00:01 myfile
+Change (meta): -rw-r--r-- 1 0 Dec 30 00:01 myfile
+
+$ stattime myfile
+File name: myfile
+ Access (read): 2018-12-30 00:01:04.097305081 -0700
+ Modify (data): 2018-12-30 00:01:04.097305081 -0700
+ Change (meta): 2018-12-30 00:01:04.097305081 -0700
+@end example
+
+@iftex
+@exdent
+@end iftex
+Delay for 60 seconds, then change the file's permission mode.
+This is
bug#31055: Document ls -Ur -fr
Hello,
On 2018-04-03 6:03 p.m., 積丹尼 Dan Jacobson wrote:
(info "(coreutils) Sorting the output") says
‘-r’
‘--reverse’
Reverse whatever the sorting method is—e.g., list files in reverse
alphabetical order, youngest first, smallest first, or whatever.
OK but mention 'whatever' doesn't mean -U, -f, because they are sorted
in "unsorted" order. In fact perhaps trigger an error.
Attached a small patch to clarify this point in the manual.
regards,
-assaf
>From 0ffd6cdc5457fdedac997c9f66e3255278cabba5 Mon Sep 17 00:00:00 2001
From: Assaf Gordon
Date: Sun, 30 Dec 2018 12:37:11 -0700
Subject: [PATCH] doc: ls: mention --reverse/-r has no effecrt with -U/-f
Suggested by Dan Jacobson in
https://bugs.gnu.org/31055 .
* doc/coreutils.text (Sorting the output): Expand -r/--reverse item.
---
doc/coreutils.texi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index e05b34ab1..fd6d578ac 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7996,6 +7996,8 @@ were specified before the @option{-f}).
@cindex reverse sorting
Reverse whatever the sorting method is---e.g., list files in reverse
alphabetical order, youngest first, smallest first, or whatever.
+@option{-r/--reverse} has no effect when using @option{--sort=none/-U} or
+@option{-f}.
@item -S
@itemx --sort=size
--
2.11.0
bug#33025: Add examples of why one would want to "sort" something "randomly"
Hello,
On 2018-10-12 10:28 a.m., 積丹尼 Dan Jacobson wrote:
OK, but you need to mention some examples of why someone would want to
"sort" something "randomly".
>
Attached is a patch to add examples of shuf/sort -R
to the coreutils documentation.
(It doesn't deal with "why", that is left to the users to decide when
they need it, but it shows clear examples of how to use it).
regards,
- assaf
>From a8ae1f29a96b47b9a9c2b26875bd41bfa124e83b Mon Sep 17 00:00:00 2001
From: Assaf Gordon
Date: Sun, 30 Dec 2018 12:21:31 -0700
Subject: [PATCH] doc: add examples of shuf/sort -R
Requested by Dan Jacobson in
https://bugs.gnu.org/33025 .
* doc/coreutils.texi (randomizing files): New section.
---
doc/coreutils.texi | 148 +
1 file changed, 148 insertions(+)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 8d303cd56..e05b34ab1 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -276,6 +276,7 @@ Operating on sorted files
* comm invocation:: Compare two sorted files line by line
* ptx invocation:: Produce a permuted index of file contents
* tsort invocation:: Topological sort
+* randomizing files::Producing random output
@command{ptx}: Produce permuted indexes
@@ -4192,6 +4193,7 @@ These commands work with (or produce) sorted files.
* comm invocation:: Compare two sorted files line by line.
* ptx invocation:: Produce a permuted index of file contents.
* tsort invocation::Topological sort.
+* randomizing files::Producing random output
@end menu
@@ -6018,6 +6020,152 @@ Anyhow, that's where tsort came from. To solve an old problem with
the way the linker handled archive files, which has since been solved
in different ways.
+@node randomizing files
+@section Producing random output
+
+The @command{shuf} and @command{sort -R/--random-sort} commands read input
+(sorted or not) and output its lines in a randomized order.
+@command{shuf} shuffles all input lines equally, regardless of their content.
+@command{sort -R} shuffles the @emph{keys} of the input lines -
+lines with identical sort keys will be grouped together:
+
+@multitable @columnfractions .5 .5
+@item
+@example
+$ printf '%s\n' A A A B B C D D | shuf
+A
+C
+D
+D
+A
+B
+A
+B
+@end example
+@tab
+@example
+$ printf '%s\n' A A A B B C D D | sort -R
+C
+D
+D
+A
+A
+A
+B
+B
+@end example
+@end multitable
+
+@command{shuf -n @var{count}} outputs at most @var{count} number of lines (i.e.,
+a sub-sample). @command{sort --random-sort --uniq} outputs one line of each
+group in a random order:
+
+@multitable @columnfractions .5 .5
+@item
+@example
+$ printf '%s\n' A A A B B C D D | shuf -n5
+B
+D
+A
+D
+B
+@end example
+@tab
+@example
+$ printf '%s\n' A A A B B C D D | sort -R -u
+C
+A
+B
+D
+@end example
+@end multitable
+
+@command{sort} operates on keys. Random and non-random keys can be combined
+to achieve desired results. In the following examples, the input file @file{in}
+contains these lines:
+
+@example
+$ cat in
+A 5
+A 3
+A 7
+B 6
+B 4
+C 4
+D 9
+D 8
+@end example
+
+@command{sort -R} without explicit keys operates on entire lines,
+producing unexpected results (as @samp{A 5} and @samp{A 3} do not result
+in identical key value):
+
+@example
+$ sort -R in
+A 7
+C 4
+A 3
+D 8
+B 6
+B 4
+A 5
+D 9
+@end example
+
+Specifing explicit key to sort randomly results in the keyed
+colomn (letters) in random order (yet same keys groupped together),
+and the other column (digits) sorted alphabetically (the default
+last-resort sort):
+
+@example
+$ sort -k1,1R in
+C 4
+A 3
+A 5
+A 7
+B 4
+B 6
+D 8
+D 9
+@end example
+
+
+In the following example, the first columns (letters) are sorted in
+reverse alphabetical order, and the second column (digits) are sorted
+randomly:
+
+@example
+$ sort -k1,1r -k2,2R in
+D 8
+D 9
+C 4
+B 6
+B 4
+A 7
+A 3
+A 5
+@end example
+
+
+To randomize a single column and keep the input order of all other
+columns, use the @option{-s/--stable} option. In the following example
+the letters will be groupped in random order, while the digits will
+be in the same order as the input file (i.e., the digits in group @samp{A}
+will always be @samp{5},@samp{3},@samp{7} - exactly as in the input file):
+
+@example
+$ sort -k1,1R -s in
+D 9
+D 8
+B 6
+B 4
+A 5
+A 3
+A 7
+C 4
+@end example
+
+
@node Operating on fields
@chapter Operating on fields
--
2.11.0
