bug#61105: cp/mv: want a fatal --no-clobber

On 27 Jan 2023 23:59, Pádraig Brady wrote: > On 27/01/2023 20:52, Mike Frysinger wrote: > > basically i've been writing things like: > > if ! cp -n foo bar; then > >... error out because bar already exists, or otherwise failed ... > > fi > > > > when

bug#61105: cp/mv: want a fatal --no-clobber

i've been under the mistaken assumption that the -n/--no-clobber option exits non-zero when the target exists, but someone pointed out to me recently that it silently ignores existing files. can we get a setting to control this ? basically i've been writing things like: if ! cp -n foo bar; then

bug#61050: mv: add support for --one-file-system

On 25 Jan 2023 01:07, Paul Eggert wrote: > On 2023-01-24 17:20, Mike Frysinger wrote: > > i'd like to require that the mv be > > atomic when relocating a directory, and if it isn't, fallback to other > > logic > > Calling the new option "--one-file-system"

bug#61050: mv: add support for --one-file-system

mv will automatically use rename, but if that fails (e.g. with EXDEV), it falls back to copying files. i'd like to require that the mv be atomic when relocating a directory, and if it isn't, fallback to other logic. to that end, it'd be nice if mv supported --one-file-system and would return an

bug#54189: [PATCH] dircolors: add hterm

On 27 Feb 2022 22:14, Pádraig Brady wrote: > On 27/02/2022 21:08, Mike Frysinger wrote: > > * src/dircolors.hin: Add hterm*. > > --- > > src/dircolors.hin | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/src/dircolors.hin b/src/dircolors.h

bug#54189: [PATCH] dircolors: add hterm

* src/dircolors.hin: Add hterm*. --- src/dircolors.hin | 1 + 1 file changed, 1 insertion(+) diff --git a/src/dircolors.hin b/src/dircolors.hin index 673835201311..fa01192bf7e5 100644 --- a/src/dircolors.hin +++ b/src/dircolors.hin @@ -23,6 +23,7 @@ TERM cygwin TERM *direct* TERM dtterm TERM

Re: [PATCH 1/1] dircolors: highlight .avif as image

On 07 Feb 2022 10:34, Chris Elvidge wrote: > On 07/02/2022 09:16, Christian Hesse wrote: > > Christian Hesse on Tue, 2022/01/04 10:56: > >> This add highlighting for AV1 Image File Format (AVIF): > >> https://aomediacodec.github.io/av1-avif/ > > > > Did I send this the right way? > > Is there a

[rfc] nosig: new program to compliment nohup

i had need of a nohup-like program, but for a different signal. i ended up writing a util called "nosig" that allows full control over signal settings before execing another program: https://vapier.github.io/nosig/ https://vapier.github.io/nosig/man.html i figure expanding nohup won't work

Re: Why is `find -name '*.txt'` much slower than '*.txt' on glusterfs?

On 19 Jan 2018 22:26, Peng Yu wrote: > There are ~7000 .txt files in a directory on glusterfs. Here are the > run time of the following two commands. Does anybody know why the find > command is much slower than *.txt. Is there a way to change the api > that `find` uses to search files so that it

bug#25550: Apparent unicode bug in uniq 8.26

On 26 Jan 2017 16:45, David Loyall wrote: > Hello. I think I found a bug in uniq 8.26. while it is a bug, i'm pretty sure it's a bug in glibc. coreutils relies on data glibc provides in cases like this. -mike signature.asc Description: Digital signature

bug#25455: uniq considers all the full-width punctuation and Japanese kana as the same under zh_CN.UTF-8 locale

On 16 Jan 2017 04:01, Icenowy Zheng wrote: > When dealing lines with only a Chinese full-width punctuation or Japanese kana > and locale is zh_CN.UTF-8, uniq command will consider all the lines are the > same, and wrongly removed different punctuations. this is a problem with glibc, not

Re: strengthening ARRAY_CARDINALITY

On 19 Jan 2017 17:13, Jim Meyering wrote: > On Thu, Jan 19, 2017 at 5:06 PM, Mike Frysinger wrote: > > On 19 Jan 2017 22:20, Pádraig Brady wrote: > >> On 19/01/17 21:52, Eric Blake wrote: > >> > On the qemu list, it was pointed out that code that uses > >> &g

Re: strengthening ARRAY_CARDINALITY

On 19 Jan 2017 22:20, Pádraig Brady wrote: > On 19/01/17 21:52, Eric Blake wrote: > > On the qemu list, it was pointed out that code that uses > > ARRAY_CARDINALITY() might still compile even after it has been > > refactored to use a pointer (probably conversion of an array into > > dynamic

Re: feature request for coreutils: b2sum

On 29 Oct 2016 19:37, Pádraig Brady wrote: > On 09/10/16 21:28, Mike Hodson wrote: > > At the risk of going somewhat offtopic of this list, however, as this > > is the one point of continual reference I have to the Blake2 hash in > > common use (I am always interested in learning the new features

Re: Whats the reason to suppress short unicode characters in printf?

the code as written has existed since it was first committed in Mar 2000: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?h=29d3ba4a7b42ed1b40b963b6047f2412ea4843b1 although the Author says Jim, the ChangeLog file says Bruno Haible. that predates the merge of file/text/shell utils into

bug#22696: ls output changes considered unacceptable

On 17 Feb 2016 01:41, isabella parakiss wrote: > On 2/17/16, Ruediger Meier wrote: > > As already said in practice it is already configurable by different kind > > of distro-specific techniques or shell aliases. For example openSUSE > > has envvar LS_OPTIONS. Maybe we could

utilizing dircolors database as a proxy for color support

we've long used the dircolors database as a proxy to see whether the active terminal supports color. basically something like: eval "$(dircolors -b)" if [[ -n ${LS_COLORS} ]] ; then # env supports colors fi but having to go through the eval & LS_COLORS

Re: broken ls in coreutils 8.25

On 02 Feb 2016 07:17, Harald Dunkel wrote: > On 02/01/16 17:07, Pádraig Brady wrote: > > - Output can be pasted back in the shell for further processing > > This means that it useful only on a graphic terminal, for people > using a mouse, but it affects all users using "ls" that's incorrect.

ls quoting improvements

in cases where the filename has a single quote in it, and no other expandable chars (like $ or `), would it be better to use double quotes to quote the output ? for example, i have a file like: My Sister's stuff.xls the new ls quote behavior shows it like: 'My Sister'\''s

Re: Coreutils-gotchas

On 30 Nov 2015 10:37, Eric Blake wrote: > On 11/28/2015 11:34 PM, Assaf Gordon wrote: > > On 11/29/2015 12:16 AM, Pádraig Brady wrote: > > > >>> I must collate some gotchas like this. > >> > >> Initial list started at: > >> http://www.pixelbeat.org/docs/coreutils-gotchas.html > >> > > > >

Re: removal of kill?

On 09 Nov 2015 17:02, Bernhard Voelker wrote: > On 11/09/2015 04:27 PM, Pádraig Brady wrote: > > I see on most GNU/Linux distros that kill(1) is > > provided by the shell or util-linux. > > Should we just remove it from coreutils? > > What about non-Linux systems, i.e., where util-linux is not >

Re: removal of kill?

On 09 Nov 2015 15:34, Mike Hodson wrote: > On Mon, Nov 9, 2015 at 2:53 PM, Tomas Nordin wrote: > > For whatever it's worth: > > > > $ uname -a > > Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u1 i686 GNU/Linux > > It's not just Debian; Sabayon, and as such presumed

Re: feature request for coreutils: b2sum

On 28 May 2015 16:46, Bernhard Voelker wrote: On 05/27/2015 07:59 PM, Zooko Wilcox-OHearn wrote: In sum, by adding b2sum to coreutils, we can help users protect themselves from attackers, and also have a more efficient tool for file integrity. You can get the source code here:

Re: wc function proposal for an additional switch -? (choose letter ?

On 03 May 2015 23:30, Leslie S Satenstein wrote: While there is nothing wrong with wc as is, a suggestion after some use. With wc -l  it emits the line count  and the program name(s) as   nnn  program-name. With the additional switch option, it would be convenient to drop the program

Re: [PATCH] tests: fix non POSIX constructs causing failures with dash

On 19 May 2015 12:42, Pádraig Brady wrote: * tests/cp/no-ctx.sh: Scope of `var=val func` is inconsistent across shells, so avoid that construct with functions. i think POSIX requires the behavior dash exhibits, and bash will do the same when it's in POSIX compliant mode. -LD_PRELOAD=./k.so

bug#19969: problem: wc -c doesn't read actual # of bytes in file

On 02 Mar 2015 06:57, Eric Blake wrote: On 02/28/2015 01:59 AM, Linda Walsh wrote: (coreutils-8.21-7.7.7) wc -c(bytes) doesn't seem to reliably read the number of bytes in a file. I was wanting to find out what the largest data-source files in '/proc' and '/sys' (didn't get around

Re: Cross compiling coreutils and manpages

On 09 Nov 2014 21:44, Christer Solskogen wrote: Still the same :( I build by using a seperate build directory, but that shouldn't matter. Should it? ugh, sorry, i'm dumb and completely blanked. you'll want this patch too:

Re: Cross compiling coreutils and manpages

On 07 Nov 2014 13:07, Christer Solskogen wrote: On 07.11.2014 04:41, Mike Frysinger wrote: On 06 Nov 2014 22:36, Christer Solskogen wrote: Cross compiling coreutils *and* generate the manpages at the same time seems to be a hard thing to do. Is it possible to create them in any other way

Re: Cross compiling coreutils and manpages

On 06 Nov 2014 22:36, Christer Solskogen wrote: Cross compiling coreutils *and* generate the manpages at the same time seems to be a hard thing to do. Is it possible to create them in any other way? unfortunately, current wisdom is this is working as intended for Gentoo, i maintain a

Re: RFE: stat(1) flag for learning the d_type value of a given file

On 13 Oct 2014 14:34, Eric Blake wrote: On 10/13/2014 02:14 PM, Pádraig Brady wrote: Maybe, though coreutils' tests also check d_type is available. Would this suffice for cygwin? http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=tests/d_type-check;hb=HEAD That seems like a useful

Re: [PATCH v2] build: Option for building all tools in a single binary

--- a/Makefile.am +++ b/Makefile.am +# If we are building a single-binary, create symlinks for them when installing. +install-exec-hook: + $(AM_V_at)for i in $(single_binary_progs); do \ + rm -f $(DESTDIR)$(bindir)/$$i$(EXEEXT); \ +

Re: chroot's userspec option

On Sat 01 Mar 2014 09:21:33 Ken Werner wrote: On 02/28/2014 02:27 PM, Pádraig Brady wrote: On 02/28/2014 10:34 AM, Ken Werner wrote: On 02/27/2014 05:45 PM, Pádraig Brady wrote: On 02/27/2014 03:48 PM, Ken Werner wrote: I noticed when using chroot's --userspec option the Gnulib's

bug#16872: `date -d 'TZ=America/Los_Angeles 00:00 + 1 hour'` crashes

as reported by Bertrand Jacquin, this crashes: $ date -d 'TZ=America/Los_Angeles 00:00 + 1 hour' Segmentation fault (gdb) bt #0 0x77ab1014 in __GI___libc_free (mem=0x7fffc8b0) at malloc.c:2942 #1 0x00406730 in parse_datetime (result=result@entry=0x7fffcab0, p=optimized

bug#15624: [PATCH] dircolors: add putty-256color terminal type

* src/dircolors.hin: Add putty-256color Reported-by: Thomas D. whi...@whissi.de, via http://bugs.gnu.org/486786 --- src/dircolors.hin | 1 + 1 file changed, 1 insertion(+) diff --git a/src/dircolors.hin b/src/dircolors.hin index 18e1552..5877005 100644 --- a/src/dircolors.hin +++

Re: Adding a --preserve= option to install

On Friday 07 June 2013 19:53:14 Bob Proulx wrote: Anthony G. Basile wrote: Pádraig Brady wrote: I don't suppose you could use `cp` rather than `install` for this use case? Using cp instead of install would be a long shot here for our package manager people but I can talk to them.

bug#14229: invalid TZ and /bin/date

On Friday 19 April 2013 15:47:46 Donald Berry wrote: Yes, date/GNU accepts whatever TZ string you pass it without error, but this leads to very confusing results. Paul said the GNU system, not GNU/date. coreutils doesn't parse the TZ env var, the C library does. similarly, the date program

Re: That '[' file in /usr/bin

On Saturday 23 February 2013 15:56:20 Eric Blake wrote: On 02/23/2013 10:25 AM, Salvador Girbau wrote: Hi all, would it be possible to replace /usr/bin/[ with a symlink to /usr/bin/test ? Not really. Although [ and test are compiled from the same sources, they are compiled with

bug#13582: [PATCH] stat: add ext4 to the ext2/ext3 list

On Tuesday 29 January 2013 01:57:42 Bernhard Voelker wrote: tag 13582 + notabug close 13582 stop On 01/29/2013 07:13 AM, Mike Frysinger wrote: Since ext4 returns the same info as ext2/ext3, add it to the list. This fixes the output of running `stat -f / -c %T` on my system that has

bug#13582: [PATCH] stat: add ext4 to the ext2/ext3 list

Since ext4 returns the same info as ext2/ext3, add it to the list. This fixes the output of running `stat -f / -c %T` on my system that has an ext4 rootfs. * src/stat.c (human_fstype): Add ext4 to the S_MAGIC_EXT2 and FSTYPE_EXT2FS cases. --- src/stat.c | 4 ++-- 1 file changed, 2 insertions(+),

bug#13517: How to change the date format in linux

On Monday 21 January 2013 01:59:01 Vinay Jain wrote: Right now if i will fire a command: date '+%D' then it will display 01/20/13. I want that when i fire the command date '+%D' then it should be displayed as 20/01/2013. please read `man date` or `info date`. it explains how to use the +

bug#13352: [PATCH] cp: ignore EEXIST errors from mkdir

If you're copying multiple source trees into a single destination in parallel (which have overlapping dirs, but not files), you can easily hit a race condition. This can crop up more generally if you're running multiple installs from different build directories in parallel. You don't get as much

bug#13352: [PATCH] cp: ignore EEXIST errors from mkdir

On Thursday 03 January 2013 19:17:03 Paul Eggert wrote: Thanks for the bug report, but I'm not sure that's the right fix. Wouldn't it be better to address the following FIXME in cp.c? /* FIXME: Synch this function with the one in ../lib/mkdir-p.c. */ The function in mkdir-p.c doesn't

Re: dd: it doesn't continue after errors

On Friday 28 December 2012 06:41:02 YuGiOhJCJ Mailing-List wrote: I am trying to blank a 160 GB hard disk drive but I got an error and dd doesn't want to continue: $ sudo dd if=/dev/zero of=/dev/sdb conv=noerror,sync dd: writing to `/dev/sdb': Input/output error 6160537+0 records in

bug#13118: [PATCH] factor: disable longlong.h logic for x32 builds

On Wednesday 19 December 2012 21:29:50 Pádraig Brady wrote: Was this a runtime or build time issue BTW? What was the failure mode if runtime? build time. the asm code was rejected due to mismatched constraints. -mike signature.asc Description: This is a digitally signed message part.

bug#13118: [PATCH] factor: disable longlong.h logic for x32 builds

The current x86_64 asm code does not work for x32 ABIs, so disable it until someone can fix it. Simply deleting the q suffix is not enough. * src/longlong.h: Check for __ILP32__ for x86_64 targets. --- src/longlong.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian

On Mon, Nov 26, 2012 at 3:48 AM, Ashish, Agrawal wrote: I use the output of 'uname -p' in my product. It seems to work fine on very other Linux distro that I have worked on (ex. RHEL, SUSE Linux Enterprise Server and even Ubuntu 12.04), except Debian where it returns 'unknown'. The

bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian

On Mon, Nov 26, 2012 at 1:11 PM, Mike Frysinger wrote: the GNU version relies on the standard interfaces to do that (which they don't). to be clearer, the interfaces coreutils relies on don't exist on Linux, so it always issues unknown you can find the patch i've been keeping up-to-date

bug#13001: [PATCH] uname: add -i/-p decoding to Linux platforms

To add support for additional platforms, check out the show_cpuinfo() func in the linux/arch/ARCH/ source tree of the kernel. * src/uname.c: Include trim.h. (linux_procinfo): New function. (main): Call linux_procinfo when __linux__ is defined and PRINT_PROCESSOR or PRINT_HARDWARE_PLATFORM is

bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian

On Mon, Nov 26, 2012 at 3:26 PM, Pádraig Brady wrote: On 11/26/2012 06:51 PM, Mike Frysinger wrote: On Mon, Nov 26, 2012 at 1:11 PM, Mike Frysinger wrote: the GNU version relies on the standard interfaces to do that (which they don't). to be clearer, the interfaces coreutils relies on don't

bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian

On Mon, Nov 26, 2012 at 9:22 PM, Paul Eggert wrote: On 11/26/2012 10:51 AM, Mike Frysinger wrote: Paul: you were against this in the past [1], but in light of 594d5064c950fa1d99a9eafbd357c5f46320d002, can we reconsider ? I'm not sure what that hexadecimal number refers to it's the SHA1

bug#12738: 'sort' wastes cpu-cycles of all available cpus

On Friday 26 October 2012 05:42:31 Jim Meyering wrote: Schwidom, Frank wrote: In some situations sort wastes cpu-cycles of all available cpus. $ sort --version sort (GNU coreutils) 8.7 Packaged by Gentoo (8.7 (p1)) However, your version of sort is quite old and that bug was fixed

bug#12714: [PATCH] build: do not redefine _FORTIFY_SOURCE

On Wednesday 24 October 2012 12:09:27 Jim Meyering wrote: Mike Frysinger wrote: On Tuesday 23 October 2012 15:26:14 Jim Meyering wrote: Mike Frysinger wrote: If the active compiler or flags have already defined _FORTIFY_SOURCE, don't go overriding that. Otherwise we get a lot of spew

bug#12714: [PATCH] build: do not redefine _FORTIFY_SOURCE

If the active compiler or flags have already defined _FORTIFY_SOURCE, don't go overriding that. Otherwise we get a lot of spew about the flag being redefined. * configure.ac (FORTIFY_SOURCE): Check if _FORTIFY_SOURCE is defined. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1

bug#12714: [PATCH] build: do not redefine _FORTIFY_SOURCE

On Tuesday 23 October 2012 15:26:14 Jim Meyering wrote: Mike Frysinger wrote: If the active compiler or flags have already defined _FORTIFY_SOURCE, don't go overriding that. Otherwise we get a lot of spew about the flag being redefined. * configure.ac (FORTIFY_SOURCE): Check

bug#12715: coreutils-8.20: bad dependency information with man page generation

if i look at vanilla coreutils-8.20, i see: Makefile.in:man/uname.1: src/uname.c which seems to have originated from man/local.mk, but munged: man/uname.1: src/uname this causes parallel build problems because man/uname.1 generation can get scheduled before src/uname has been linked.

Re: [PATCH] build: do not require help2man at build-from-tarball time

On Monday 10 September 2012 06:46:23 Jim Meyering wrote: Stefano Lattarini wrote: On 09/10/2012 09:41 AM, Jim Meyering wrote: We can't have build-from-tarball requiring perl (via help2man) or regenerating a distributed .1 file when its .c file has not changed. From

Re: non-recursive make finished?

On Fri, Sep 14, 2012 at 12:30 AM, Jim Meyering wrote: Bernhard Voelker wrote: Some test-related things don't seem to be refurbished yet (although some of the following cases also didn't work with the old build system): a. 'make' in the 'tests' directory fails: No longer supported. you

Re: removing su from coreutils [Re: Fwd: [PULL] su

On Thursday 31 May 2012 04:12:17 Ludwig Nussel wrote: Mike Frysinger wrote: On Wednesday 30 May 2012 09:50:57 Karel Zak wrote: [...] IMHO is better to use PAM everywhere than duplicate non-PAM code and assume that the code is correct and well tested. PAM is abstraction, the final

Re: removing su from coreutils [Re: Fwd: [PULL] su

On Wednesday 30 May 2012 09:50:57 Karel Zak wrote: On Fri, May 25, 2012 at 01:48:29PM -0400, Mike Frysinger wrote: On Friday 25 May 2012 04:53:59 Karel Zak wrote: login - already merged Suse version into original login from utils-linux. The result is PAM-only

Re: removing su from coreutils [Re: Fwd: [PULL] su

On Friday 25 May 2012 04:53:59 Karel Zak wrote: pidof - from sysvinit; not sure, probably into procps-ng with the new project, this is probably possible su - will be merged from coreutils into util-linux (2.22 ?) login - already merged Suse version into original login from

Re: removing su from coreutils [Re: Fwd: [PULL] su

On Thursday 24 May 2012 09:50:40 Pádraig Brady wrote: On 05/24/2012 02:21 PM, Jim Meyering wrote: I would like to remove su.c, if/when possible from coreutils. The last time I proposed that, the Hurd was mentioned as a reason not to, since they relied on the su from coreutils. Is that

bug#11498: [PATCH] dircolors: add st/st-256color terminal types

See http://st.suckless.org/ * src/dircolors.hin: Add st and st-256color. Reported-by: Jeroen Roovers j...@gentoo.org Signed-off-by: Mike Frysinger vap...@gentoo.org --- src/dircolors.hin |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/dircolors.hin b/src

bug#11453: `ls` in coreutils-8.17 incorrectly shows broken symlinks in /

coreutils-8.16 works fine (confirmed), and i don't recall seeing this bug before, so looks like a regression with 8.17 easy to show: $ sudo ln -s dev /foo $ ls --color=auto / ... foo wrongly shows up in blinky text indicating it's a broken symlink ... $ ls --color=auto /. ... foo correctly shows

Re: setting permission for ... Permission denied

On Tuesday 27 March 2012 00:05:03 Peter Johansson wrote: This is with coreutils 8.4: $ /usr/bin/install --version install (GNU coreutils) 8.4 that's fairly old at this point. you should first attempt to upgrade to the latest version and see if the problem still exists. '/mnt/hpc' is a

bug#10472: `realpath --relative-to=path /` outputs inconsistent trailing slash

first some examples that look fine ... these all output the same thing: realpath --relative-to=/usr /usr/bin realpath --relative-to=/usr/ /usr/bin realpath --relative-to=/usr /usr/bin/ realpath --relative-to=/usr/ /usr/bin/ which is to say, they show: bin

bug#10472: `realpath --relative-to=path /` outputs inconsistent trailing slash

On Tuesday 10 January 2012 15:15:57 Mike Frysinger wrote: as does these: realpath --relative-to=/ /usr realpath --relative-to=/ /usr/ which is to say, they show: .. sorry, typo here ... these actually output: ../usr i guess that should be just usr. -mike

bug#10472: `realpath --relative-to=path /` outputs inconsistent trailing slash

On Tuesday 10 January 2012 17:30:48 Pádraig Brady wrote: Essentially in these edge cases the relative paths printed are valid, but not canonicalised. sure ... i think we all agree on that :) -mike signature.asc Description: This is a digitally signed message part.

bug#9804: [PATCH] include man-pages for non-default progs

At the moment, things like man/arch.1 are not included in the tarball. This makes perl a requirement if you want to build/install the arch helper. * man/Makefile.am (EXTRA_DIST): Add $(NO_INSTALL_PROGS_DEFAULT:%=%.1). --- man/Makefile.am |3 ++- 1 files changed, 2 insertions(+), 1

Re: libstdbuf installed in /usr/lib on biarch system

On Friday 14 October 2011 06:09:09 Philipp Thomas wrote: * Pádraig Brady (p...@draigbrady.com) [20111013 18:03]: The dir was changed to appease newer automake http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e23f1795 So it should be as easy as passing

Re: libstdbuf installed in /usr/lib on biarch system

On Friday 14 October 2011 11:36:27 Philipp Thomas wrote: * Mike Frysinger (vap...@gentoo.org) [20111014 17:29]: or --libexecdir when running ./configure That would work too, but as Andreas already wrote, libstdbuf.so shouldn't be part of a PROGRAMS primary. i'm not sure how that's relevant

Re: libstdbuf installed in /usr/lib on biarch system

On Friday 14 October 2011 13:57:43 Andreas Schwab wrote: Mike Frysinger vapier-abrp7r+bbdudnm+yrof...@public.gmane.org writes: i'm not sure how that's relevant. whether you set the path in configure or at make install time, you're still forcing all the libexec files to go to the same path

Re: libstdbuf installed in /usr/lib on biarch system

On Thursday 13 October 2011 11:32:23 Philipp Thomas wrote: Trying to build coreutils-8.14 fails because libstdbuf.so is installed in /usr/lib/coreutils instead of /usr/lib64/coreutils, i.e. $libdir seems to be ignored, which didn't happen in at least 8.12. Is this wad or a glitch and if the

bug#9418: case sensitivity buggy in sort

On Thursday, September 01, 2011 04:58:58 Michał Janke wrote: sort (GNU coreutils) 8.12 The case-sensitivity looks buggy in sort. Have a look at these examples: the million dollar question: what are your locale settings ? post the output of running `locale`. then see if you get different

Re: progress bar in cp

On Tuesday, August 09, 2011 16:59:33 Дмитрий Ильин wrote: Have you considered using rsync? Is there some reason you require this functionality in cp? Rsync is not in coreutils and is not always installed. but neither is a patched coreutils cp ;) -mike signature.asc Description: This is a

bug#9126: [PATCH] dircolors: add screen.Eterm to TERM list

* src/dircolors.hin: Add screen.Eterm. Reported-by: Kfir Lavi lavi.k...@gmail.com Signed-off-by: Mike Frysinger vap...@gentoo.org --- src/dircolors.hin |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/dircolors.hin b/src/dircolors.hin index 8b4a645..bab7c9b 100644

bug#8577: GNU coreutils-8.12 thinks GNU libc-2.13's getcwd() is buggy ?

On Thursday, April 28, 2011 14:52:08 Eric Blake wrote: glibc's getcwd() has _always_ been buggy. It fails to return a name for a current working directory whose name is longer than PATH_MAX bytes, even though (in most cases) such a name can still be determined by walking back through ..

Re: [PATCH] copy: adjust fiemap handling of sparse files

On Thursday, March 17, 2011 19:00:26 Pádraig Brady wrote: On 17/03/11 19:29, Mike Frysinger wrote: On Thursday, March 17, 2011 05:32:33 Pádraig Brady wrote: Also note the make_holes heuristic variable is no longer used in extent_copy due to this patch which came after the 8.10 http

Re: [PATCH] copy: adjust fiemap handling of sparse files

On Wednesday, March 16, 2011 19:55:56 Pádraig Brady wrote: On 16/03/11 19:18, Mike Frysinger wrote: well, in the bug report i was working with, we were seeing data loss. i wonder if it'd be possible to detect the fs/kernel version and error out when versions are found that are known

Re: [PATCH] copy: adjust fiemap handling of sparse files

On Thursday, March 17, 2011 05:32:33 Pádraig Brady wrote: This is the kind of patch appropriate for a distro, as they may or may not have a fix backported to their kernel. Gentoo, being a source distribution, has no kernel requirement. people are free to run on pretty much anything. we dont

git-version-gen headaches

the current git-version-gen script and its usage in packages such as coreutils is causing me headaches wrt distros. it currently assumes one of two states: - the current tree is a valid git repo belonging to the related project - the current tree is not a git repo (all the way

Re: git-version-gen headaches

On Saturday, February 19, 2011 14:49:32 Jim Meyering wrote: Jim Meyering wrote: Mike Frysinger wrote: further, some of the commands used in git-version-gen require write access to the .git repo (i.e. git update-index --refresh), which our package management tools flag as a violation

bug#8001: cp (8.10) sparse handling fails on compressed btrfs (cp/fiemap-2)

based on other threads (which i havent been following too closely), did we settle on this being a btrfs bug ? -mike signature.asc Description: This is a digitally signed message part.

bug#8001: cp (8.10) sparse handling fails on compressed btrfs (cp/fiemap-2)

2011/2/19 Pádraig Brady: On 19/02/11 18:28, Mike Frysinger wrote: based on other threads (which i havent been following too closely), did we settle on this being a btrfs bug ? Nope, cp 8.10 is not absolved yet. It may be btrfs not honoring FIEMAP_FLAG_SYNC, and/or it may be cp needing

bug#8079: rm command problem/suggestion

On Friday, February 18, 2011 20:20:24 Luca Daniel wrote: 1) The problem: I can't find an easy way to remove a type of file through all sub-directories with GNU tool rm (remove). There is not an option to search through all sub-folders , only in the current working directory. Back when I used

bug#8001: cp (8.10) sparse handling fails on compressed btrfs (cp/fiemap-2)

after upgrading from coreutils 8.9 to 8.10, the sparse handling in cp is silently breaking on btrfs filesystems with the compressed option enabled. using --sparse=never works fine, but auto or always tend to fail. the cp/fiemap-2 test catches the issue nicely. to reproduce (i'm using

Re: [coreutils] [patch] Re: Install enhancement request: capabilities

On Wednesday, November 10, 2010 07:00:51 Pádraig Brady wrote: Ideally the package archive format should support capabilities if they're needed, and tar et. al. should support the attributes if they're important. yes, but tar doesnt support it today From a package maint point of view, if

bug#6793: [PATCH] dircolors: add screen.rxvt terminator to TERM list

* src/dircolors.hin: Add screen.rxvt terminator. Signed-off-by: Mike Frysinger vap...@gentoo.org --- src/dircolors.hin |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/dircolors.hin b/src/dircolors.hin index 511fb16..ccd6613 100644 --- a/src/dircolors.hin +++ b/src

bug#6673: [PATCH] only build libstdbuf.so when stdbuf is enabled

until after we know the final enable list, and then only build libstdbuf.so when stdbuf is also enabled. Signed-off-by: Mike Frysinger vap...@gentoo.org --- configure.ac |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index e7037a1..acd397e

bug#5912: [PATCH] dircolors: add rxvt-256color rxvt-unicode256

Signed-off-by: Mike Frysinger vap...@gentoo.org --- src/dircolors.hin |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/dircolors.hin b/src/dircolors.hin index 6a4b1e3..511fb16 100644 --- a/src/dircolors.hin +++ b/src/dircolors.hin @@ -38,9 +38,11 @@ TERM mach-color

Re: install not atomic

On Sunday 28 February 2010 03:35:19 Ralf Wildenhues wrote: Hello bug-coreutils readers, a recent GCC bug report[1] the GNU install program is not atomic; i.e., when you install file $dest install file $dest then one of them may fail. For reproducability purposes, use several large

Re: Feature Request kill and ps

On Thursday 11 February 2010 17:36:55 Jan Girke wrote: I suggest kill eatin' names instead of numbers example: kill 'process name' what's wrong with `killall` ? -mike signature.asc Description: This is a digitally signed message part.

Re: How to create an empty file?

On Monday 25 January 2010 12:22:09 Peng Yu wrote: 'touch' will not make the file size empty if the file is not empty. I don't not want to use 'rm -f' first then touch because I might accidentally remove something if I type anything wrong. Could somebody let me a better way to create an empty

Re: expr exit status

On Tuesday 19 January 2010 02:11:14 salih k wrote: What are all the exit statuses I need to check just after expr command? Is it only need to check 1 or 2 or 3 for fail condition and zero for success ? please read the documentation -- `man expr` -mike signature.asc Description: This is a

Re: Build error with coreutils-8.3

On Saturday 09 January 2010 14:49:41 Mike Frysinger wrote: On Saturday 09 January 2010 03:58:02 Chris Clayton wrote: I'm getting a build error with coreutils-8.3. version 8.2 builds fine with the same toolset/glibc releases. The error is as follows: gcc version is 4.4.3 20100105

Re: Build error with coreutils-8.3

On Saturday 09 January 2010 03:58:02 Chris Clayton wrote: I'm getting a build error with coreutils-8.3. version 8.2 builds fine with the same toolset/glibc releases. The error is as follows: gcc version is 4.4.3 20100105 (prerelease). glibc is 2.7. seems to be an issue with =glibc-2.9. at

test-version-etc.sh fails when using the --with-packager-... configure options

the test-version-etc.sh falls over when configured with: --with-packager=Gentoo --with-packager-version='8.1 (p1)' this isnt a coreutils-8.1 regression ... been like this since the --with- packager-... options were added. FAIL: test-version-etc.sh (exit: 1) ===

Re: test-version-etc.sh fails when using the --with-packager-... configure options

On Wednesday 18 November 2009 22:43:04 Eric Blake wrote: According to Mike Frysinger on 11/18/2009 8:12 PM: the test-version-etc.sh falls over when configured with: --with-packager=Gentoo --with-packager-version='8.1 (p1)' ! COPYRIGHT Free Software Foundation, Inc. License GPLv3+: GNU

Re: rfc: exposing *at functions to shell

On Wednesday 11 November 2009 17:13:04 Eric Blake wrote: Here's a thought (no immediate rush to implement, though). Should we expose various *at functions to shell scripting, by adding a new option to specify which fd to pass as the directory argument? This would allow the creation of

Re: Updates on mv, cp commands

On Sunday 01 November 2009 06:56:45 BRAGA, Bruno wrote: I would like to propose and patch improvements on the mv (move) and cp (copy) commands, by adding options for progress information. this is the place for such things, but this topic has come up before and rejected (for specific commands).

Re: coreutils-7.6: df does not show filesystem mounted via mount(2)

On Thursday 29 October 2009 04:47:52 Gilles Espinasse wrote: Selon Stuart Kemp stuart_k...@hotmail.com: Yes, the app I was playing with does not call addmntent() or anything else to explicitly manipulate /etc/mtab. But it should not have to, since all of this mount-data is already available

  1   2   3   >