problem in ./bootstrap

Tried doing a re-bootstrap, but am getting several odd messages: yesno yesno-tests yield Notice from module error: If you are using GNU gettext version 0.16.1 or older, add the following options to XGETTEXT_OPTIONS in your po/Makevars: --flag=error:3:c-format --flag=error_at_line:5:

Re: problem in ./bootstrap

Eric Blake wrote: Because the run of gnulib-tool is trying to patch a file, but the file doesn't patch cleanly - which is usually an indication that the version of the file being patched (from gnulib) and the patch itself (from coreutils) are out of sync. Wasn't aware the 'make' would pul

Re: problem in ./bootstrap

retab is a test program / driver for another source file. The other source file seems to work (for some value of work), and wanted to add 'retab.c' to the build so I could start trying to build/debug it. As for what I intend to do with it... not sure. retab does tend to overlap, a bit, expand/u

Re: problem in ./bootstrap

Eric Blake wrote: In particular, coreutils computes a list of bin_progs at configure time via the auxiliary script build-aux/gen-lists-of-programs.sh, --- That did it... that an another 'configure'... At least I can build it w/a make... But wasn't sure what I wanted to do with some of thi

coreutils & building w/C++

I was wondering if there has ever been any consideration given to migrating the coreutils to C++, or at least making it such that it would build cleanly under either? It would seem, theoretically, that the resulting binaries should be ~roughly~ equivalent (though that may be a naive impression),

Re: coreutils & building w/C++

Eric Blake wrote: On 02/03/2017 07:31 PM, L A Walsh wrote: I was wondering if there has ever been any consideration given to migrating the coreutils to C++, or at least making it such that it would build cleanly under either? No, and there probably is no interest in it either. Finding a

Re: "full" man pages, please?

Bernhard Voelker wrote: First of all, the Texinfo manual is the primary way for documentation in GNU projects: Broken by design doesn't excuse conforming to existing standards. https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals Second, maintaining the same as

Re: FEATURE REQUEST: Re: 'ls' human-readable sizes

Pádraig Brady wrote: On 18/06/17 03:51, Boruch Baum wrote: When I visually scan 'ls -lh' output, I find it difficult to notice every instance of the convenience presentation of 'k' and 'm'. Could you consider making them more visible, either through colorization of the letter, bold face of t

Re: FEATURE REQUEST: Re: 'ls' human-readable sizes

Eduardo A. Bustamante López wrote: On Sun, Jun 18, 2017 at 03:07:41PM -0700, L A Walsh wrote: [..] Maybe an ENV option, like LS_OPTIONS could be provided to allow specifying interactive options like the filename quoting that wouldn't be active when scripts are run? ls isn't m

ENVVars Removal and functional replacements (was Re: coreutils feature requests?)

Kaz Kylheku (Coreutils) wrote: On 19.07.2017 10:03, Lance E Sloan wrote: With regard to your objection to a special environment variable: .. My own objection to such influencing env-vars is rooted in "global variables are bad"; i.e. the inherited wisdom from decades of computer science and soft

Re: Backspace is not working in a chroot environment

RAJESH DASARI wrote: Hi , I did chroot on my environment and after i switched to the chrooted directory ,backspace key is not working properly , when i enter backspace it is taken as a "space". --- This is not likely a coreutils issue, but likely a behavior of the how your chroot enviro

Re: [PATCH] dd: support iflag=direct with arbitrary sized files

Pádraig Brady wrote: +** Improvements + + dd now supports iflag=direct with arbitrary sized files. + ** Build-related - What was the use-case for this? It seems it is a problematic feature: if someone uses 'direct', they aren't getting the most recent version of the file and ma

Re: base85 would it be accepted

Pádraig Brady wrote: On 13/10/17 03:28, Eric Curtin wrote: Hi Guys, I find base32 and base64 very useful in coreutils. If I wrote a base85 implementation in the same style would it be accepted? Just wondering, don't want to waste my time submitting just in case. Well as the bit width

Re: factor -- print factorization in exponential form

Eduardo � wrote: On Sat, Nov 11, 2017 at 12:49:36AM +0100, Emanuel Landeholm wrote: List, I'm working with large composite numbers and would like to have the option of printing the factorization in exponential form. I have attached a patch for printing factorizations in this form: $ src

Re: base85 would it be accepted

Eric Curtin wrote: On 20 November 2017 at 20:02, L A Walsh wrote: I know this is a bit of an old topic, but nevertheless, might be useful... If the utility was a "baseN" utility to allow arbitrary N, up to, maybe, N=96 (0x20-0x7f -- printable characters or *maybe*, N=95 if

Re: base85 would it be accepted

It's a good thing humans are in charge and both computers and standards, created by humans are there to serve humans. Fortunately, use an algorithm where only the last symlink, in a directory ending with 'baseN' would be used. So the user can specify any name they want for ar

Re: is there a real escape "quoting" style for ls?

Harald Dunkel wrote: touch A\ Knight's\ Tale:\ Part\ 2 doesn't work for bash, which means that the current implementation of the "escape" quoting style is not really helpful. Have you tried doing an "ls --help" ? If you look under --quoting-style, you'll see: --quoting-style=WORD

Re: performance bug of `wc -m`

Pádraig Brady wrote: Now the gnulib replacement is only table lookup and some bit manipulation. Ah it also calls locale_charset()! That must be slow on OSX. Indeed :( --- It may be a red herring, but I seem to remember Mac choosing to go with what is now a non-standard normalization form (NFD

Re: Enhancements request – Accuracy, Documentation, Conventions, Basic units of measure

Ricky Tigg wrote: –Issue reported first at bugzilla.red hat 1582165 – OS :Fedora Version-Release number of component: coreutils.x86_64 8.29-6.fc28 @updates 1. Accuracy Actual results: In terminal, outputs resulting from the execution of comm

Re: RFC: rm --preserve-root=all to protect mount points

Pádraig Brady wrote: Rather than add a new option, I thought it cleaner to extend the existing --preserve-root option to support --preserve-root=all, as that can be interpreted to preserve the root of all specified file systems. --- My first comment was about hoping it wasn't going to beco

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

Original Message Subject: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise? Resent-Date:Thu, 12 Jul 2018 07:17:02 +0000 Resent-From:L A Walsh Resent-CC: bug-coreut...@gnu.org Date: Thu, 12 Jul 2018 00:16:50 -0700 F

Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

Paul Eggert wrote: On 07/12/2018 02:16 AM, L A Walsh wrote: I'm asking why does 'ln' bother to tell the user that they are wrong and do nothing useful? Why not just go ahead and create a symlink The user didn't ask for a symlink, and it sounds unwise for ln to be

Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

Paul Eggert wrote: On 07/12/2018 02:16 AM, L A Walsh wrote: I'm asking why does 'ln' bother to tell the user that they are wrong and do nothing useful? Why not just go ahead and create a symlink The user didn't ask for a symlink, User didn't ask for a physica

Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

Bernhard Voelker wrote: I disagree here: some people are not that familiar with the differences between symlinks and hardlinks, okay, but the consequences for using either type may be quite dramatic later on. I am not suggesting handing out alternates when you have a choice. I

Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

Michael Stone wrote: On Tue, Jul 17, 2018 at 01:25:59AM -0700, L A Walsh wrote: I am not suggesting handing out alternates when you have a choice. I'm suggesting doing something useful in a case where there are no alternates and no downsides. If you can come up with a case wh

Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

Michael Stone wrote: On Tue, Jul 17, 2018 at 02:15:14PM -0700, L A Walsh wrote: I can't think of a similar failure mode that I'd want a hard link created Yes, you've made that clear --- I think you are making it clear that you didn't understand what I said an

Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

Mike Hodson wrote: I wager that some people *aren't* aware that you cannot hardlink a directory If they don't know why, they probably don't know the difference between hard and soft links to files -- and will *then* be annoyed that linking doesn't work. *THEN*, they will your "

Re: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

Michael Stone wrote: Or, they expect the traditional behavior, which is that requesting a link which can't be created will result in failure. You seem to completely disregard the possibility that any script written in 40 years might use that behavior in its logic, while I find it extremely

Fwd: rfe? cp from symlink -> to symlink? cp symlink meta-info(target) with "-a"? (vs. no diagnostic)

st seeing messages from "assaf gordon"... Original Message Subject: rfe? cp from symlink -> to symlink? cp symlink meta-info(target) with "-a"? (vs. no diagnostic) Date: Thu, 25 Oct 2018 12:58:20 -0700 From: L A Walsh <> To: Coreutils Create

Re: Feature request about "Tail -f": Gentle exit (not using CTRL+C)

On 10/21/2018 10:14 AM, Ingo Krabbe wrote: Hi Brian, you actually have many more options to leave a tail -f. --- What other key can you press to exit tail that is not likely to also be a control-signal. I.e. I think what may be wanted here is pressing 'q' or something similar? This w

Re: What tricks used in readlink to make it faster than realpath bash loadable?

On 12/13/2018 2:02 PM, Eric Blake wrote: On 12/13/18 3:37 PM, Peng Yu wrote: Hi, `readlink` is faster than `realpath` for a large number of input arguments. Note that the former starts slower than the latter. What tricks is used in readlink to make it faster? Thanks. Why don't you use

Re: coreutils v. 8.30 – Auto-scaling regarding block sizes

On 2/12/2019 3:05 AM, Ricky Tigg wrote: > Hi. Suggestion: would auto-scaling regarding block sizes be a welcome > feature to DD? Illustration by script (paths are valid for a *Linux Fedora* > system): > auto-scaling to do what?

Re: df wishlist

On 3/16/2019 9:07 AM, Bruce Dubbs wrote: > It would be helpful to add a --terse option to df such that a user could > do something like: > > DF=$(df -k --terse --output=used $PWD) > > Right now I see no method of omitting the header or to collapse the > spaces between values to a single space. T

Re: [PATCH] df: Adding a --no-headers option, by request of Bruce Dubbs

On 3/21/2019 3:13 AM, Erik Auerswald wrote: > More general, table headers are useful for interactive use, but often need > to be ignored when the tool output is used programmatically. I've noticed this as well -- maybe it would be smartest in addition to any other tool changes to have the

Re: RFC: Safely using xargs -P$NUM children's output? Need a new tool?

On 5/2/2019 11:49 PM, Denys Vlasenko wrote: Gnu has a utility called parallel that _says_ it will ensure the output is consistent with what you would get running the command sequentially. Perhaps it would work for you? I haven't used it extensively, so don't know or not, but thought I'd mention

Re: question about parallelism in cp command

On 2019/06/06 09:25, Marc Roos wrote: > > Hmmm without being a maintainer. I would say cp -r is most used on > single disk, so one thread is using the maximum disk iops taking y time > to copy. --- not exactly true, if the 1 disk as a 20 disk raid10. You can target 10 areas at a time and g

Re: question about parallelism in cp command

needs to be there for underlying fs-drivers to r/w multiple full tracks at a time while performing only 1 iop to write multiple tracks. > > > -Original Message- > From: L A Walsh [mailto:coreut...@tlinx.org] > Sent: vrijdag 28 juni 2019 13:15 > To: Marc Roos > Cc:

Re: question about SI/IEC in df

On 2019/11/28 04:39, Krzysztof Labus wrote: > In the manual I see: > The SIZE argument is an integer and optional unit (example: 10K is > 10*1024). Units are K,M,G,T,P,E,Z,Y (powers of 1024) or KB,MB,... > (powers of 1000). > > 1. Why df not using Ki, Mi, Gi etc. in powers od 1024 ?? > ---

Re: Is it safe to replace dd?

On 2020/01/20 04:14, microsoft gaofei wrote: Many people suggest using dd to create bootable USB, https://www.archlinux.org/download/ . But cp and mv also writes to USB, e.g., cp archlinux-2020.01.01-x86_64.iso /dev/sdb, cat archlinux-2020.01.01-x86_64.iso > /dev/sdb. Is it safe to use these c

Re: Show directory time as the latest time of the file in the directory (including subdirs)

On 2020/01/29 01:58, Peng Yu wrote: Hi, For directories, ls shows in the time of the directory itself. Sometimes, it is more important to show the latest time of files in the directory in addition to the directory time. Is there an easy way to show such information? Thanks. You might check

Re: [PATCH] dircolors: add *direct* to TERM matching

xterm-TrueColor and xterm-24bit I've heard of, but direct? Isn't that a direct serial line connection? But suffice it to say, I haven't seen any _concensus_ on a name or terminal-name for that feature. Certainly TrueColor or 24-bit (or maybe 32) would be more descriptive that something used for

Re: Patchset pertaining to --si option of df, du, ls

On 9/8/2020 9:27 AM, Glenn Golden wrote: The attached patchset addresses a minor issue with program behavior vs. documentation of the df, du, and ls tools from coreutils-8.32, when using the --si option. It resurrects an issue that was brought up in 2014 [3] and eventually closed in 2018 [4] wit

Re: Short option for rm --interactive=never

On 2020/10/29 05:59, David Hesselbom wrote: Dear coreutils maintainers, Quoting rm.c itself: enum interactive_type { interactive_never, /* 0: no option or --interactive=never */ interactive_once, /* 1: -I or --interactive=once */ interactive_always /* 2: default, -i or --interac

Re: how to sell network nodes

On 2020/11/12 00:48, Michael J. Baars wrote: Hi, I needed to zero out my hard drive because one of my nodes has become unstable. To this purpose I used coreutils dd with the following command line arguments dd if=/dev/zero of=/dev/mmc... status=progress and I noticed how slow this program is

Re: how to sell network nodes

On 2020/11/14 02:13, Michael J. Baars wrote: On Fri, 2020-11-13 at 14:36 -0800, L A Walsh wrote: On 2020/11/12 00:48, Michael J. Baars wrote: Hi, I needed to zero out my hard drive because one of my nodes has become unstable. To this purpose I used coreutils dd with the following

Re: date should become tolerant to superfluous and contradicting options

On 2021/01/21 07:15, Adalbert Hanßen wrote: e.g. to/etc/bash.bashrc. However once this is done, calling date -Iminutes yields an error because the date format is stated twice. It would be possible to unalias the alias by calling \date -Iminutes if one wants to let date deliver a shorter and

Use tq instead of tee: Add -q, --quiet option to not write to stdout

On 2021/01/21 05:17, Alejandro Colomar wrote: This is useful for using tee to just write to a file, at the end of a pipeline, without having to redirect to /dev/null Example: echo 'foo' | sudo tee -q /etc/foo; --- Isn't this what you want and shorter?: echo 'foo' | sudo tq /etc/foo ls -

(resend) - simple fix to eliminate the need for a new feature in 'tee'. (was Re: [PATCH v3 (resend)] tee: ...)

On 2021/01/26 17:40, Alex Henrie wrote: Personally, I like the idea of only having to type `echo foo | tee -q` instead of `echo foo > /dev/null`, so I think the patch indeed does the right thing in that case. Perhaps you didn't see it, but why would you want to write tee -q, when 'tq' is sho

Re: [PATCH v3 (resend)] tee: Add -q, --quiet, --silent option to not write to stdout

On 2021/01/26 05:57, Rodney W. Grimes wrote: > So, I would remove '-i, --input-stream'. (And if you think it's > missing, maybe write a program to read from any FD and write to stdout.) Its name is cat(1) cat /dev/fd/# >outputfile Except the problem, which I've run into before, i

Re: [PATCH v3 (resend)] tee: Add -q, --quiet, --silent option to not write to stdout

On 2021/01/27 00:15, Christian Groessler wrote: What is so difficult with $ echo "3" | sudo sh -c "cat > proc/sys/vm/dropcache" I don't get it... regards, chris well, if you have 'sh' it might work, but it also might run some "rc" script. In some cases I've seen some people have the

Re: Add dry-run option to mv

On 2021/03/07 03:20, Emilio Garcia wrote: Hi all, I checked out the coreutils repo on Github and I would like to ask you to add a dry-run option in the mv command. When I've needed such functionality, I insert an 'echo' before the 'mv' command, so in a script: cmd=eval if (

Re: Add dry-run option to mv

On 2021/03/10 19:15, Kaz Kylheku (Coreutils) wrote: Me too; but that doesn't validate the arguments like Emilio wants. E.g. mv --dry-run existing-file nonexistent-dir/ # error mv --dry-run nonexistent-object somewhere # error mv --dry-run object /another/filesystem # diagnostic --

Re: make ls -l dir1 dir2 in the same order as dir1,2 are specified

On 2021/03/26 14:03, Peng Yu wrote: Hi, When I try `ls -l dir1 dir2`, the order of dir1 and dir2 in the output is not necessarily the same as the input. How to make it the same as the input order? Thanks. Use separate invocations of 'ls' to guarantee the order of output of the arguments. Wh

Re: make ls -l dir1 dir2 in the same order as dir1,2 are specified

On 2021/03/27 12:34, Glenn Golden wrote: $ ls -fl dir1 dir2 will produce what the OP asked for. -- Interesting. How can ls return the files in the order they are on disk?

Gnu design flaw fixes hindered by Gnu (sexism?) biases

On 2021/04/21 19:11, Paul Eggert wrote: On 4/18/21 10:46 AM, Peter van Dijk wrote: While the manual (but not the manpage) mentions the data loss, I think it would be great if sort did not have this problem at all, and I think the OpenGroup text also says it should not have this problem. I loo

Re: Inconsistent behavior of core utilities

On 2022/08/23 00:30, Mike Jonkmans wrote: que find is the path to go. Because find isn't part of coreutils? find isn't consistent either: find . -name \*.foo gives you output from dir ".", but you have to edit the output or add other args to get just the filenames, since there is n

Re: Inconsistent behavior of core utilities

On 2022/08/24 10:31, Michael Stone wrote: On Wed, Aug 24, 2022 at 10:17:49AM -0700, L A Walsh wrote: On 2022/08/23 00:30, Mike Jonkmans wrote: que find is the path to go. Because find isn't part of coreutils? there's more to life than coreutils - But the OP was pos