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
> >
> >
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
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-sy
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 e
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
* 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 g
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
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 coreutils.
On 14 Sep 2016 16:13, Antonio Ospite wrote:
> * src/dircolors.hin: Add .mjpg and .mjpeg multimedia files.
lgtm
-mike
signature.asc
Description: Digital signature
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 support such LS_OPTIONS
i got this bug report today about sort mismatches. the order of the
inputs changes the order of the outputs which surprised me. but it
might be a nuance of unicode collation i'm not familiar with ?
$ printf '%s\n' aarch64 abc zed | LC_ALL=nb_NO.UTF-8 sort -u
aarch64
abc
zed
$ printf '%s\n' abc a
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' (did
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=, p@ent
On Thursday 28 November 2013 15:31:06 Linda Walsh wrote:
> While I do have an alias that says:
> alias ls='ls -CF --show-control-chars --color=always'
there's your problem. don't use --color=always.
-mike
signature.asc
Description: This is a digitally signed message part.
* src/dircolors.hin: Add putty-256color
Reported-by: Thomas D. , 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
+++ b/src/dircolors.hin
@@ -37,6 +37
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 progr
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
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(+)
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 + op
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 doe
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
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.
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 a/src/longlon
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
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 add support for additional platforms, check out the show_cpuinfo()
func in the linux/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 requested
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
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
> follo
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 bu
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
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. ea
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.
> >
&g
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 deletion
See http://st.suckless.org/
* src/dircolors.hin: Add st and st-256color.
Reported-by: Jeroen Roovers
Signed-off-by: Mike Frysinger
---
src/dircolors.hin |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/dircolors.hin b/src/dircolors.hin
index 4606d1a..316c212
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
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.
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 ju
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
a
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 deletions(-
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
* src/dircolors.hin: Add screen.Eterm.
Reported-by: Kfir Lavi
Signed-off-by: Mike Frysinger
---
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
--- a/src/dircolors.hin
+++ b/src
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 .. li
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_SYN
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.
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 u
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 linu
* src/dircolors.hin: Add screen.rxvt & terminator.
Signed-off-by: Mike Frysinger
---
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/dircolors
until after we know the final enable list, and then only build libstdbuf.so
when stdbuf is also enabled.
Signed-off-by: Mike Frysinger
---
configure.ac |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e7037a1..acd397e 100644
--- a
Signed-off-by: Mike Frysinger
---
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
TERM mlterm
TERM
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
>
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.
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 empt
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
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:
> >
> >
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.
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 So
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)
===
**
On Wednesday 11 November 2009 18:13:41 Andreas Schwab wrote:
> Eric Blake writes:
> > Mike Frysinger writes:
> >> --at-fd might be a better explicit option without getting too verbose ?
> >
> > Indeed.
>
> Note that the "at" in those functions is act
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
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 comma
On Thursday 29 October 2009 04:47:52 Gilles Espinasse wrote:
> Selon Stuart Kemp :
> > 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 from the kernel
On Monday 26 October 2009 09:12:16 Eric Blake wrote:
> According to Mike Frysinger on 10/24/2009 11:38 PM:
> >> But right now we call putenv("a=b"), which puts "a=b" into the
> >> environment instead of unsetting "a".
> >
> > which i
On Saturday 24 October 2009 08:28:01 Eric Blake wrote:
> According to Mike Frysinger on 10/24/2009 12:11 AM:
> > On Friday 23 October 2009 14:44:03 Eric Blake wrote:
> >> Is 'env -i -u a=b' really supposed to output a=b, or should it be an
> >> error (becaus
On Friday 23 October 2009 16:33:01 Eric Blake wrote:
> Eric Blake byu.net> writes:
> > Is 'env -i -u a=b' really supposed to output a=b, or should it be an
> > error (because a=b is not a valid environment name)? Right now, it is
> > the former, because we are using putenv() to remove variables f
On Friday 23 October 2009 14:44:03 Eric Blake wrote:
> Is 'env -i -u a=b' really supposed to output a=b, or should it be an error
> (because a=b is not a valid environment name)? Right now, it is the
> former, because we are using putenv() to remove variables from environ,
> rather than unsetenv
On Friday 04 September 2009 03:27:00 Jim Meyering wrote:
> Kamil Dudka wrote:
> > Looks good to me. I wrote that nonsense as I had misunderstood semantic
> > of the AC_ARG_ENABLE macro...
>
> Thanks for the review.
> This time I tested carefully ;-)
>
> After each of the first three, below, grep LI
n tests and warn if not found
Signed-off-by: Mike Frysinger
---
m4/jm-macros.m4 | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4
index 416a0af..f4d43f1 100644
--- a/m4/jm-macros.m4
+++ b/m4/jm-macros.m4
@@ -105,17
On Friday 21 August 2009 16:53:55 John Taylor wrote:
> I'm trying to build coreutils-7.4 with a cross-compilator (gcc-4.4.1)
> that runs on i686-unknown-linux-gnu and produces code for
> x86_64-unknown-linux-gnu. When building coreutils, I get the following
> error message:
>
> ../../coreutils-7.4/
On Monday 17 August 2009 16:26:20 Jim Meyering wrote:
> Pádraig fixed a few bugs (thanks!), and I've pulled in
> the latest from gnulib, so here's another snapshot.
> Thanks to everyone who has been helping.
>
> I'm expecting to switch from statfs to statvfs after releasing
> coreutils-7.5, assumin
i cant figure out if i'm doing something stupid here or sort is doing
something wrong ...
consider this (reduced) input:
/path/._cfg_asciidoc.conf%/path/%._cfg_%asciidoc.conf
/path/._cfg_docbook.conf%/path/%._cfg_%docbook.conf
/path/._cfg0001_asciidoc.conf%/path/%._cfg0001_%asciid
On Thursday 07 May 2009 15:29:23 Mike Frysinger wrote:
> Signed-off-by: Mike Frysinger
> ---
> src/dircolors.hin |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> +TERM screen-256color-bce
pingaling ...
-mike
___
Bug
On Tuesday 26 May 2009 17:05:29 Kamil Dudka wrote:
> On Tuesday 26 of May 2009 22:55:37 Poor Yorick wrote:
> > Building coreutils to install in an alternate location which has its own
> > libcap and glibc (self-compiled):
> >
> > CC ls.o
> > In file included from ls.c:43:
> >
> >
On Tuesday 19 May 2009 13:05:31 Chris Weston wrote:
> r...@localhost:/mnt/sys/external> strace -v ls -l log_1848_1239927341.core
> svr4_syscall() = 0
this strace is pretty much garbage from what i can see. i havent the foggiest
why it would be so utterly broken, sorry.
-
On Monday 18 May 2009 20:56:05 Chris Weston wrote:
> I'm trying debug an issue with my one of my disks in my system. I have an
> ext3 file system mounted and ls -l is reporting an impossible size for two
> of the files: log_1848_1239927341.core and log_1848_1239927341.core~. The
> size is 98P. This
Signed-off-by: Mike Frysinger
---
src/dircolors.hin |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/dircolors.hin b/src/dircolors.hin
index 63af8cb..aa8f357 100644
--- a/src/dircolors.hin
+++ b/src/dircolors.hin
@@ -44,6 +44,7 @@ TERM rxvt-cygwin-native
TERM rxvt
On Monday 04 May 2009 15:03:35 Matthew Woehlke wrote:
> binutils wrote:
> > I couldn't remove coreutils-7.3 directory after installation, even if
> > using sudo.
> >
> > bash-4.0$ rm -rf coreutils-7.3/
> > rm: cannot remove directory `coreutils-7.3/lib': Directory not empty
>
> I've seen problems l
On Saturday 02 May 2009 20:30:39 binutils wrote:
> I couldn't remove coreutils-7.3 directory after installation, even if using
> sudo.
>
> bash-4.0$ rm -rf coreutils-7.3/
> rm: cannot remove directory `coreutils-7.3/lib': Directory not empty
>
> bash-4.0$ sudo rm -rf coreutils-7.3/
> rm: cannot rem
On Tuesday 21 April 2009 08:19:23 Philip Rowlands wrote:
> On Tue, 21 Apr 2009, Toralf F?rster wrote:
> > For a long time I used the command "factor" to test my system WRT the cpu
> > ondemand governor of the linux kernel, eg for issues like this :
> > http://bugzilla.kernel.org/show_bug.cgi?id=123
On Thursday 23 April 2009 15:35:20 Jim Meyering wrote:
> Jim Meyering wrote:
> > Mike Frysinger wrote:
> >> On Friday 17 April 2009 18:28:07 James Youngman wrote:
> >
> > ...
> >
> >>> The patch itself looks good, but it might be worth leaving in
On Saturday 18 April 2009 16:58:52 Jim Meyering wrote:
> Mike Frysinger wrote:
> > On Friday 17 April 2009 18:28:07 James Youngman wrote:
> >> The patch itself looks good, but it might be worth leaving in a
> >> comment indicating why the optimisation should not be reint
On Friday 17 April 2009 18:28:07 James Youngman wrote:
> On Fri, Apr 17, 2009 at 5:46 PM, Jim Meyering wrote:
> > diff --git a/src/copy.c b/src/copy.c
> > index 9b0e139..3cbeba4 100644
> > --- a/src/copy.c
> > +++ b/src/copy.c
> > @@ -699,10 +699,6 @@ copy_reg (char const *src_name, char const
> >
On Monday 13 April 2009 03:45:54 maguowei2723 wrote:
> I want to replace all the word of "root" to "administrator" in test.txt
> file.I get a bit part of the file:
>
> root 1 0.0 0.1 2008 768 ?Ss 21:03 0:03 /sbin/init
> root 2 0.0 0.0 0 0 ?S< 2
On Friday 27 March 2009 06:00:55 Pádraig Brady wrote:
> Pádraig Brady wrote:
> > However in the bug report you're seeing the issue with coreutils-7.1
> > which should have the fix. Also Jim checked that the original textutils
> > had this issue but you say coreutils-5 did not?
>
> Ah, 7.1 has the i
a user reported an issue with coreutils' sort and -b/-k usage. it seems to be
a regression from 5.x -> 6.x, or maybe a bug fix :).
the simple case:
$ printf 'a b c\na b c\n' | sort -u -b -k1,1
a b c
a b c
the user contests that there should only be one line displayed (and that is
how coreuti
On Wednesday 25 March 2009 16:57:26 Olivier Delhomme wrote:
> Le Wed, 25 Mar 2009 18:51:41 +0100, Adilson Bonanovisky disait :
> > Please, how can I execute the following idea: $ su gimp &
> > but really in bacground?
>
> I can not figure out what you want to do, but you might try
> this :
>
> if [
this version passes all tests for me on my x86_64/Linux system
-mike
signature.asc
Description: This is a digitally signed message part.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
On Thursday 12 March 2009 09:47:34 Jim Meyering wrote:
> Mike Frysinger wrote:
> > this might sound like a no brainer, but `make check` will fail if
> > attempted to run offline because of the test-getaddrinfo test. perhaps
> > it should attempt a simple "is the network
On Thursday 12 March 2009 09:47:34 Jim Meyering wrote:
> Mike Frysinger wrote:
> > this might sound like a no brainer, but `make check` will fail if
> > attempted to run offline because of the test-getaddrinfo test. perhaps
> > it should attempt a simple "is the network
On Thursday 12 March 2009 09:05:25 Jim Meyering wrote:
> Mike Frysinger wrote:
> > it's been a while, so i dont remember if this has been reported already,
> > but if groups is disabled via the command line, the misc/groups-dash test
> > is still run. since the groups
this might sound like a no brainer, but `make check` will fail if attempted to
run offline because of the test-getaddrinfo test. perhaps it should attempt a
simple "is the network alive" and SKIP if it isnt ?
-mike
signature.asc
Description: This is a digitally signed message part.
___
it's been a while, so i dont remember if this has been reported already, but
if groups is disabled via the command line, the misc/groups-dash test is still
run. since the groups program is not coming from coreutils, the output is not
as expected and things fail. perhaps a new func in test-lib.
On Tuesday 10 March 2009 06:47:11 Pádraig Brady wrote:
> Mike Frysinger wrote:
> > On Tuesday 10 March 2009 06:11:47 Jim Meyering wrote:
> >> Mike Frysinger wrote:
> >>> mkudir() { (u=$1; g=$2; shift 2; install -d -o"$u" -g"$g" "$@"); }
On Tuesday 10 March 2009 06:11:47 Jim Meyering wrote:
> Mike Frysinger wrote:
> > mkudir() { (u=$1; g=$2; shift 2; install -d -o"$u" -g"$g" "$@"); }
>
> Good idea.
> I prefer to use "local", and thus to avoid forking a subshell.
in g
On Tuesday 10 March 2009 05:54:49 Jim Meyering wrote:
> Pádraig Brady wrote:
> > Caleb Cushing wrote:
> >> be awesome if mkdir had a way to specify the user:group ownership
> >> being made. given this would be limited by perms. but as root it could
> >> be good.
> >>
> >> just throwing it out there
On Friday 27 February 2009 21:54:55 Jen Donier wrote:
> We have been working with Michael LeBlanc at Xandros Support and have had
> one problem after another with the new Xandros 4 which we purchased in
> December and installed. See details below.
so you should keep working with Xandros. noth
On Sunday 22 February 2009 03:34:24 Jim Meyering wrote:
> Mike Frysinger wrote:
> > On Saturday 23 February 2008 01:12:24 Mike Frysinger wrote:
> >> On Saturday 23 February 2008, Paul Eggert wrote:
> >> > Mike Frysinger writes:
> >> > > i'm us
On Saturday 23 February 2008 01:12:24 Mike Frysinger wrote:
> On Saturday 23 February 2008, Paul Eggert wrote:
> > Mike Frysinger writes:
> > > i'm using coreutils-6.10 with acl-2.2.47 on linux-2.6.24. when using
> > > ext2 with acl support enabled, `cp -p`
the current man/Makefile.am does not create and distribute man pages for non-
standard programs like arch, hostname, and su. this is a pain when working
with cross-compiling as the install target will attempt to run the binary and
generate the man page which will of course fail.
a simple workar
On Wednesday 11 February 2009 13:31:57 Karl Berry wrote:
> $ ls --version
> ls (GNU coreutils) 6.12
> Packaged by ... some distro string here ...
>
> That looks like the right place to me. I'd be tempted to put a blank
> line between "Packaged by ..." and "Copyright ...".
the attached
On Wednesday 11 February 2009 02:04:11 Jim Meyering wrote:
> Mike Frysinger wrote:
> ...
>
> >> > i was thinking a common change to the version-etc module to add a
> >> > "packager" field rather than having every package out there allow
> >> &
1 - 100 of 263 matches
Mail list logo
