,
merging it with the part that populates printable_field.
(main): Handle --complement.
in doc/ChangeLog:
2004-12-04 Jim Meyering [EMAIL PROTECTED]
* coreutils.texi (cut invocation): Say when --complement is useful.
2004-10-01 Paolo Bonzini [EMAIL PROTECTED
Stephane Chazelas [EMAIL PROTECTED] wrote:
(coreutils 5.2.1, on Debian Linux, C locale).
$ echo mmm | tr 'a\55z' a
aaa
(expected mmm)
$ echo abcd | tr 'abcd' '\133m*\135'
(expected [m*])
If I understand
http://www.opengroup.org/onlinepubs/009695399/utilities/tr.html
correctly,
Roberto Nibali [EMAIL PROTECTED] wrote:
...
Oh. I see that this has been fixed since 5.2.1.
...
Hmmm, has it really? Could you show me the changeset, please?
My use of `since' was misleading.
This was fixed *after* coreutils-5.2.1.
You can find the development version here:
Tim Waugh [EMAIL PROTECTED] wrote:
In 5.2.1, tr doesn't work for multibyte encodings such as UTF-8. Are
there any plans to fix this?
It's most certainly on the list, (hmm.. it's been on the list in my head
for years, but wasn't listed in the TODO file -- I've just added it there)
The same
Matt Kraai [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 5.2.1-2
$ csplit --help | head -3
Usage: csplit [OPTION]... FILE PATTERN...
Output pieces of FILE separated by PATTERN(s) to files `xx01', `xx02', ...,
and output byte counts of each piece to standard output.
When I run
Dmitry V. Levin [EMAIL PROTECTED] wrote:
...
According to documentation, futimes() may also fail with ENOSYS; in this
case, falling back on utimes() also looks reasonable:
+ if (errno != ENOENT)
+ if (errno != ENOSYS errno != ENOENT)
Thanks.
I've made that change.
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Dmitry V. Levin [EMAIL PROTECTED] wrote:
+ if (errno != ENOSYS errno != ENOENT)
Thanks.
I've made that change.
On further thought, this looks like a classic example where we should
be testing for known
Ulrich Hermisson [EMAIL PROTECTED] wrote:
Hello,
the following behaviour of sort -nu needs not necessarily be considered a
bug:
$ echo ,2,0,1,-2,3,-4 | tr , \n | sort -nu
-4
-2
1
2
3
Thanks for the report.
POSIX requires sort, with -n or `-kM,Nn', to interpret an empty field as 0.
Jim Meyering [EMAIL PROTECTED] wrote:
A string of zero digits is interpreted as `0'.
That sounds to me like it's talking about 00. Maybe A string
of no digits? Or A line that ends or has has nondigit characters
where the number would be?
Good point.
Thanks.
by a decimal-point
Vin Shelton [EMAIL PROTECTED] wrote:
To whom it may concern:
Thanks for the quick testing and report!
What compiler did you use?
On a SunOS-5.5.1 system (uname -a reports:
SunOS boise 5.5.1 Generic_103640-40 sun4u sparc SUNW,Ultra-5_10 Solaris)
I'm getting the following test failures:
Eric Blake [EMAIL PROTECTED] wrote:
I have access to an old Solaris 7 box at work, which has gcc 2.8.1. When
compiled with CFLAGS='', all non-root tests pass or are skipped. But with
the default CFLAGS='-g -O2', gcc miscompiles putchar() (basically, it
replaces '\n' with '\0'). This breaks,
Engel, Christian [EMAIL PROTECTED] wrote:
...
gmake[3]: Entering directory `/home/cre/coreutils-5.2.1/tests/stty'
FAIL: row-col-1
Thanks for the report.
FYI, that was not a problem with stty, but rather
with how one of Solaris' ioctls worked when rows or columns
was set to zero.
So that test
Adrian Bunk [EMAIL PROTECTED] wrote:
...
FAIL: tail-tests
[test f-1 failed]
Thanks for the report.
Here's the fix I checked in yesterday:
(I'll update the comment)
2005-01-14 Jim Meyering [EMAIL PROTECTED]
The test, tests/tail/f-1, failed on powerpc-apple-darwin7.7.0.
* src
Bryan Rood [EMAIL PROTECTED] wrote:
I am in dire straights. No matter what file I copy to my samba share, cp
won't copy more than 2,097,152KB. Can you help me with this or point me to
somewhere that explains why?
Your coreutils package may have been built without largefile support
or your
Eric Blake [EMAIL PROTECTED] wrote:
...
* src/od.c (OPENMODE): New macro.
(open_next_file): Use OPENMODE in fopen call.
...
Index: src/od.c
===
RCS file: /cvsroot/coreutils/coreutils/src/od.c,v
retrieving
Eric Blake [EMAIL PROTECTED] wrote:
...
Also, I noticed some other tests in the suite that were sensitive to group
names. At the moment, I'm not on the machine where I noticed all the
problems, but off the top of my head, I remember that at least
chown/separator was calling `id' directly
Johan Boule [EMAIL PROTECTED] wrote:
in the output of cp --help,
the line of --no-dereferrence should be merged with
the line of -P, like:
-P, --no-dereferrence never follow symbolic links
Thanks for pointing that out.
Now cp's --help output looks like this:
Usage: ./cp
Eric Blake [EMAIL PROTECTED] wrote:
...
However, the Makefile.am patches are still important to allow the
tests/help-version script to succeed without filling the disk (otherwise,
you eval `args=$yes.exe_args', then run `yes.exe .exe_args' which runs
away, rather than the intended `yes
Andreas Schwab [EMAIL PROTECTED] wrote:
$ ./cp --parents /bin/cp /tmp
./cp: failed to get attributes of `bin': No such file or directory
Thanks for the report.
I can't reproduce that:
$ ./cp --parents /bin/cp /tmp
$ find /tmp/bin
/tmp/bin
/tmp/bin/cp
$
Would you please investigate
Andreas Schwab [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Andreas Schwab [EMAIL PROTECTED] wrote:
$ ./cp --parents /bin/cp /tmp
./cp: failed to get attributes of `bin': No such file or directory
Thanks for the report.
I can't reproduce that:
Please make sure that /tmp
Eric Blake [EMAIL PROTECTED] wrote:
After further googling, it looks like there are several systems which have
VSWTC instead of VSWTCH, but still initialize mode-c_cc[VSWTC] with
CSWTCH [1]. The following patch fixes this situation for coreutils. It
also silences some annoyances from cvs
Eric Blake [EMAIL PROTECTED] wrote:
...
According to the cygwin mailing list,
http://sources.redhat.com/ml/cygwin/2005-02/msg00013.html, cygwin already
supports sparse files when you do lseek beyond EOF during writes. The
trick, however, is that NTFS on Windows XP does not create a hole until
Andreas Schwab [EMAIL PROTECTED] wrote:
Eric Blake [EMAIL PROTECTED] writes:
Index: tests/du/8gb
===
RCS file: /cvsroot/coreutils/coreutils/tests/du/8gb,v
retrieving revision 1.6
diff -u -p -r1.6 8gb
--- tests/du/8gb 3 May
Eric Blake [EMAIL PROTECTED] wrote:
According to James Youngman on 2/1/2005 3:17 AM:
Unix systems automatically generate sparse files when programs seek
forwards on their output file. There is no need to have a sparse
attribute. This is what coreutils' cp does.
Right now, the tests/du/8gb
Ian MacGregor [EMAIL PROTECTED] wrote:
I think I found a bug in the mv command.
...
When I change line #9 in the bash script from
mv /home/storage/backup.tar.gz /home/storage/`date +%Y%m%d-%k%M`-backup.tar.gz
to
mv /home/storage/backup.tar.gz /home/storage/`date +%Y%m%d-%I%M`-backup.tar.gz
Jeroen van Wolffelaar [EMAIL PROTECTED] wrote:
I've done a bit more reading and googling, and I found statvfs(2):
struct statvfs {
unsigned long f_bsize;/* file system block size */
unsigned long f_frsize; /* fragment size */
fsblkcnt_t
Paul Eggert [EMAIL PROTECTED] wrote:
This introduces a new format %S to stat -f -c.
...
Jim, this is an incompatible change to the output of stat -f, since
it changes the default format to output both block sizes. I think the
change is useful, but if you think that's too drastic right now
Sébastien Maret [EMAIL PROTECTED] wrote:
I am trying to install coreutils-5.3.0 on my PowerBook. I am running
MacOSX 10.3.8 (Darwin Kernel Version 7.8.0). The compilation goes well,
but one of the test fails with the following message:
make check
[...]
...
FAIL: nice
PASS: pathchk1
Geoffrey Odhner [EMAIL PROTECTED] wrote:
I have encountered a bug with the rm command. If I unpack the
coreutils-5.0 in a directory named .temp (I haven't tried any other
names for this bug) and then from the parent of the .temp directory say:
rm -rf .temp/
then I get the following
Eric Blake [EMAIL PROTECTED] wrote:
POSIX now requires pwd(1) to support -L and -P, that -L is the default,
and that -L reads $PWD to verify that it is a name (possibly with symbolic
links) of the current directory. Coreutils pwd currently implements none
of this, and behaves as though -P is
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
gethrxtime uses clock_gettime on Linux systems (and any other system
without nanouptime), so such systems will get link errors for
clock_gettime if it's in a separate library like -lrt.
Sorry, I didn't test with new
¤´Æ [EMAIL PROTECTED] wrote:
Hello. I have a question for cp tools.
CP tool is so convenient for make processing, but I¡¯ve had trouble with
copying some files.
cp: will not overwrite just-created `../../1H/uimdrv.h' with
`../../services/uim/uimdrv.h'
cp: will not overwrite just-created
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
$ mkdir a b c
$ touch {a,b}/important.h
$ cp a/*.h b/*.h c
cp: will not overwrite just-created `c/important.h' with `b/important.h'
Hmm, does POSIX allow this behavior? I just visited
http
Hi Bob,
I've noticed that my use of `source' below might be misunderstood.
Here's a snippet from the documentation that should help:
mv [OPTION]... SOURCE DEST
mv [OPTION]... SOURCE... DIRECTORY
[EMAIL PROTECTED] (Bob Proulx) wrote:
...
I know this is one of the features that you
[EMAIL PROTECTED] (Bob Proulx) wrote:
Jim Meyering wrote:
I've noticed that my use of `source' below might be misunderstood.
Here's a snippet from the documentation that should help:
mv [OPTION]... SOURCE DEST
mv [OPTION]... SOURCE... DIRECTORY
I can see that you are emphasizing
Paul Eggert [EMAIL PROTECTED] writes:
OK, I've just submitted an Aardvark for this to the POSIX folks (my
reference number 20050304a).
...
https://www.opengroup.org/sophocles/show_mail.tpl?source=Llistname=austin-review-lid=1907
Thanks for doing that!
Tim Waugh [EMAIL PROTECTED] wrote:
A Netapp NFS server containing a file (xxx) and a snapshot of the file
(.snapshot/xxx) will give them the same inode number.
Unfortunately, 'cp .snapshot/xxx xxx' (in order to recover the
snapshot version) fails with '... are identical' due to the inode
Jim Meyering [EMAIL PROTECTED] wrote:
...
That said, it might be worthwhile to change the SAME_INODE checks
in copy.c to also check same_file_attributes, where that macro
is defined like this (from diffutils/src/system.c):
Can someone make sure this patch works and let me know?
Just apply
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Can someone make sure this patch works and let me know?
Just apply it, build cp, and then run a command like
./cp .snapshot/F F
for some file F, on a NetApp-backed file system.
The above command should succeed
Mark Brand [EMAIL PROTECTED] wrote:
[This is a correction of my last e-mail that incorrectly referred to
chmod instead of chown in a couple of places. This report is about
chown. Sorry about that.]
I hope I'm not making a fool of myself, but here we go:
version: coreutils-5.2.1-3.rpm (from
should continue to support
it, so I documented it.
Thanks for all of that.
I've made the following additional changes (only in coreutils for now),
any one of which would have been enough to ensure that intprops.h is
included in the coreutils distribution:
2005-03-10 Jim Meyering [EMAIL PROTECTED
[EMAIL PROTECTED] (Paul Jarc) wrote:
Paul Eggert [EMAIL PROTECTED] wrote:
/* Bound on length of the string representing an integer value or type T.
Subtract 1 for the sign bit if t is signed; log10 (2.0) 146/485;
add 1 for integer division truncation; add 1 more for a minus sign
if
FYI, I found that making pr use a very long date string in its
header would overflow the stack:
2005-03-10 Jim Meyering [EMAIL PROTECTED]
Don't segfault for a long header date string, e.g.,
echo a|pr -D +%999A
* src/pr.c (init_header): Use x2nrealloc, rather than
checked, sizeof init_bigbuf is over 2600.
2005-03-10 Jim Meyering [EMAIL PROTECTED]
Don't segfault for a very long date format string, e.g.,
ls -ld --time-style=+%H .
* src/ls.c (long_time_expected_width): Use x2nrealloc, not alloca,
so format string abuse
[EMAIL PROTECTED] (Paul Jarc) wrote:
Jim Meyering [EMAIL PROTECTED] wrote:
Technically, yes, but that would prohibit applying that macro
to variables, which is useful. Currently there are uses like
that in the coreutils.
Ah - well, it's easy enough to factor, so you'd have to specify
[EMAIL PROTECTED] (Eric Blake) wrote:
This may be worthy of raising an issue with the austin group, but I
thought I'd ask here first. A complaint was raised on the cygwin list
that the following sequence had no interactive prompt:
$ uname
CYGWIN_NT-5.0
$ touch a
$ ln a b
$ mv -i a b
$
separate patch that
should make it harder to introduce such bugs in the future.
2005-03-12 Jim Meyering [EMAIL PROTECTED]
Add a little infrastructure to help prevent future bugs like the
one fixed below.
* src/stat.c (xstrcat): New function.
(print_statfs
Eric Blake [EMAIL PROTECTED] wrote:
The following patch, first proposed for cygwin, is needed on systems like
cygwin where not copying in binary mode can lead to data corruption. This
affects mv, cp, and install.
2005-03-15 Corinna Vinschen [EMAIL PROTECTED] (tiny change)
*
Tim Waugh [EMAIL PROTECTED] wrote:
coreutils-5.2.1:
$ mkdir /tmp/foo
$ cp -lL /lib/libc.so.6 /tmp/foo
$ ls -l /tmp/foo
total 4
lrwxrwxrwx 2 root root 13 Mar 8 10:59 libc.so.6 - libc-2.3.4.so
The man page says that -L always dereferences symbolic links, but when
used in conjuction with
Tim Waugh [EMAIL PROTECTED] wrote:
On Tue, Mar 15, 2005 at 04:38:03PM +0100, Jim Meyering wrote:
...
Thanks for the report.
I suppose this is a documentation bug, since
making hard links to symlinks is not portable.
I suppose -L and -l should mention that when they are used
together, cp may
Hi Bob,
[EMAIL PROTECTED] (Bob Proulx) wrote:
Jim Meyering wrote:
Is it worth it to make cp manually follow a sequence of symlinks
when given both -L and --link?
That would certainly be a nice capability.
If it is not worth it could that case be made an invalid case? That
way
, but utime fails with EOVERFLOW (which
isn't mentioned in Solaris man pages as one of the ways utime may fail).
utimes works the same way.
2005-03-20 Jim Meyering [EMAIL PROTECTED]
* src/pr.c (init_header): Add missing `%' in new format string.
(init_header): Use zero-filled
Paul Eggert [EMAIL PROTECTED] wrote:
I installed the following patches to sync from gnulib. The only
change that wasn't simply a file-copy was to lib/vasnprintf.c.
One of these days I should sync from coreutils to gnulib.
The biggest hassle will be all those AC_LIBSOURCES and AC_LIBOBJ
Paul Eggert [EMAIL PROTECTED] wrote:
Also, for those who prefer British spellings, should we be looking
at supporting colour synonyms (dircolours, LS_COLOURS, ls --colour,
etc.)?
No, option and environment variable names are American English. If we
wanted to localize them (I'm dubious), we
I was surprised to see that pr didn't reject as invalid a
negative page number. I've checked this in:
2005-04-01 Jim Meyering [EMAIL PROTECTED]
Don't let pr treat +1:-1 like +1:18446744073709551615.
* src/pr.c (strtoumax): Remove declaration.
(first_last_page): Use
FYI,
Before, 3 man pages (echo, printf, pwd) included a warning like this:
NOTE: your shell may have its own version of printf, which usually supersedes
the version described here. Please refer to your shell's documentation
for details about the options it supports.
I've put that warning
P.S. Which type of copyright thing do I need for this? If someone
can point me at the relevant stuff I'll try and get it sorted.
I'll send it separately.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Dmitry V. Levin [EMAIL PROTECTED] wrote:
According to NEWS file,
tee - now writes to standard output instead of to a file named -.
However, tee closes stdout more than once if file is named -:
$ env -i tee - /dev/null; echo rc=$?
tee: write error
rc=1
Proposed fix and testcases for tee
Paul Eggert [EMAIL PROTECTED] wrote:
Dr. David Alan Gilbert [EMAIL PROTECTED] writes:
OK, here is a handful of stuff against the CVS checkout.
Is this OK?
...
The examples need to be written up in doc/coreutils.texi as well.
Jim, do you think they should be before or after the exit-status
[EMAIL PROTECTED] (Eric Blake) wrote:
...
If anyone knows of any
other coreutils commands that are built-in, please let me know.
tcsh provides nice, nohup, and printenv. Not that csh-variants are
POSIX-compliant, but they are often a user's default shell, so these three
should also get the
[EMAIL PROTECTED] (Bob Proulx) wrote:
Olivier Delhomme wrote:
Here I have coreutils 5.2.1, debian 3.1 unstable, bash 3.00.16(1)
and I can not reproduce your problem. The hash value is correct and
without the \ at the beginning.
On my Debian system the md5sum utility is not the GNU one but is
Geert Jan van Oldenborgh [EMAIL PROTECTED] wrote:
a while ago I installed the very useful coreutils on my iMac. However,
when I tried to upgrade my free software collection with fink it
refused. The reason turned out to be a bew uname from coreutils, which
did not recognize the processor:
Bruno Haible [EMAIL PROTECTED] wrote:
Guillaume Chazarain wrote:
As it prints a message for the first time, it has to
initialize gettext, and I'm not sure this qualifies for the do as
little as possible in a signal handler rule.
I agree. The list of guaranteed async-safe function calls on
Guillaume Chazarain [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
If there is no better way to solve the problem, then I'd consider
leaving the code the way it is.
Don't forget, there is my workaround, it stills cause gettext() calls in
the signal handler, but I cannot make it fail, unlike
Stephen Mc Gowan [EMAIL PROTECTED] wrote:
While make install in /usr/ports/sysutils/coreutils I encountered
this error. I'm running FreeBSD 5.4 preRelease
configure: WARNING: sys/mount.h: present but cannot be compiled
configure: WARNING: sys/mount.h: check for missing prerequisite
This is probably due to a bug in how readdir works on your system.
Currently coreutils has a configure-time run-test that detects whether
rm's relatively expensive work-around code is required. But if that test
runs only on a file system that does not exhibit the bug, then rm is built
without the
Joey Hess [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 5.2.1-2
Severity: important
Tags: security
Our coreutils seems to be vulnerable to the problem described in
CAN-2005-1039.
http://www.securityfocus.com/archive/1/395489
A quick strace of mkdir -m 400 foo shows the problem:
Paul Eggert [EMAIL PROTECTED] wrote:
My kneejerk reaction is that it's not worth making this change. The
attack in question will work against almost any program that is
operated in an insecure directory, including the chmod program
itself. It'd be a real pain to work around this problem in
Paul Eggert [EMAIL PROTECTED] wrote:
Eric Blake [EMAIL PROTECTED] writes:
What was wrong with my proposed patch?
I had some qualms with it, because it added coupling between the test
cases and the rest of the code, by propagating BUILD_SRC_DIR and
EXEEXT from the latter to the former.
Paul Eggert [EMAIL PROTECTED] wrote:
I installed the following patch to remove fetish to coreutils in a few
That was overdue.
Long ago, when FIleutils, TExtutils, and SH-utils were merging,
I put test tarballs in a directory named fetish/, but people
noticed that some corporate content-filters
Allen Suski [EMAIL PROTECTED] wrote:
I have noticed that source requires the texinfo package (actually makeinfo)
in order to successfully compile and install.
Identifying this in the build time dependencies may save some others
frustration when starting from a fresh HP-UX 11.11 install.
Are
By the way, the coreutils anon CVS mirror syncronization
appears to be hung again,
I've just sync'd things.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Eric Blake [EMAIL PROTECTED] wrote:
Relevant clips from this cygwin bug report. When tty settings are weird
(I'm not sure whether the bug is in cygwin, xterm, or just bad tty
settings that could be reproduced elsewhere), backspace only repositions
the cursor on screen, so that the actual
is committed, but there will be some delay before
it reaches savannah.
2005-05-10 Jim Meyering [EMAIL PROTECTED]
* src/copy.c (abandon_move): Remove erroneous UNWRITABLE check.
This makes `mv -i --reply=no f1 f2' work as expected (in not
performing the move operation
Eric Blake [EMAIL PROTECTED] wrote:
According to Adam Price on 5/9/2005 11:39 PM:
Making check in touch
make check-TESTS
PASS: relative
0a1
touch: setting times of `/': Permission denied
FAIL: not-owner
I've noticed that cygwin also tends to fail this test, because the typical
cygwin
Paul Eggert [EMAIL PROTECTED] wrote:
Your message about nohup's problems had me nodding in agreement, as similar
problems have happened to me. Are there any objections to my
installing this patch into GNU coreutils?
2005-05-12 Paul Eggert [EMAIL PROTECTED]
* NEWS: nohup now closes
In reviewing parts of remove.c I noted (again) the race condition on
systems with an unlink that may remove directories, so added this comment:
+/* If anyone knows of another system for which unlink can never
+ remove a directory, please report it to [EMAIL PROTECTED]
+ The code below is
Paul Eggert [EMAIL PROTECTED] wrote:
...
How about this patch? It incorporates the above ideas.
2005-05-13 Paul Eggert [EMAIL PROTECTED]
* m4/prereqs.m4 (gl_PREREQ): Require gl_UNLINKDIR.
* src/remove.c: Include unlinkdir.h.
(UNLINK_CAN_UNLINK_DIRS): Remove.
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
That looks fine, and works fine here.
Please commit it.
OK, done. I also added Cygwin to the list of platforms that
can't unlink directories, as Eric Blake suggested.
Thanks!
I found that it needed a little change
Sp4wn Root [EMAIL PROTECTED] wrote:
The command tac does not obtain to read memory archives that are located in
/proc.
Example:
#tac /proc/cpuinfo
Thank you for the report.
That's fixed in the latest test release.
ftp://alpha.gnu.org/gnu/coreutils/
Peter Kratzer [EMAIL PROTECTED] wrote:
I have encountered a problem using the command ln -sf to replace a symlink
to a directory by a symlink to a different directory.
`ln -nsf' should do what you want.
___
Bug-coreutils mailing list
Dr. David Alan Gilbert [EMAIL PROTECTED] wrote:
From the current cvs (as of a few minutes ago) when I do
./expr 6 + -2
I get 8. Every other version of expr I've tried gets 4
which really does seem right.
(This is on ubuntu Linux gcc 3.3.5 on x86)
Can anyone replicate this?
I can :(
Paul Eggert [EMAIL PROTECTED] wrote:
The recent bug-fix to expr got me to thinking: why doesn't expr simply
compare integers of unlimited length, the way sort does? That can
be done cheaply. test has a similar problem. I installed the
following patch to implement this idea.
This fixes all
Paul Eggert [EMAIL PROTECTED] wrote:
...
2005-05-30 Paul Eggert [EMAIL PROTECTED]
Port to Solaris 10's rules for whether programs can chown files.
That is indeed an improvement.
Thank you!
___
Bug-coreutils mailing list
Frederik Eaton [EMAIL PROTECTED] wrote:
So, what is the current state of things? Who is in charge of accepting
patches? Are we decided that a 'shuffle' command but no 'sort -R'
facility would be best, or that it would be good to have both, or is
it still in question whether either would be
William Brendling [EMAIL PROTECTED] wrote:
...
Doesn't the standard ISO-8601 date format accomplish that, too?
Quite likely. I will have to find out what the ISO-8601 format is.
date already supports it:
$ date --iso=s
2005-06-07T08:14:28+0200
ls does, too, via --time-style=STYLE.
du's
Bill, thanks for pointing out the bad example.
I've added Bob's examples verbatim.
Thanks, Bob.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Frederik Eaton [EMAIL PROTECTED] wrote:
Here is a preliminary patch for basic shuffling functionality in
'sort', with same-keys-sort-together behavior. It adds two options:
-R to compare based on a hash of key, and --seed to specify salt
for the hash. If --seed is not given then the default is
Gregory Butenko [EMAIL PROTECTED] wrote:
I have compiled coreutils with hardened gcc and now the following
messages pop up when subtrees copied or moved:
mv: stack smashing attack in function copy_internal()
or
cp: stack smashing attack in function copy_internal()
-06-13 Jim Meyering [EMAIL PROTECTED]
* src/mkdir.c (main): Give a diagnostic for -- and skip -- each
relative directory name after make_dir_parents fails to restore
the working directory. Before, `mkdir -p' could create directories
in the wrong place in unusual
improve performance on the average, since mkdir
-p /some/existing/file must be a common case.
Finally, there was a new small bug in mkdir-p.c.
Patch and test case below.
2005-06-15 Jim Meyering [EMAIL PROTECTED]
* lib/mkdir-p.c (make_dir_parents): Don't let a failed chdir($PWD
[EMAIL PROTECTED] wrote:
I haven't looked too deeply into this,
so this is just a heads up.
Yep. I mentioned that coreutils/TODO wrt md5sum:
Look into improving the performance of md5sum.
`openssl md5' is consistently about 30% faster than md5sum on an idle
AMD 2000-XP system with
Mark Melahn [EMAIL PROTECTED] wrote:
The following patches make the shred man page and doc/coreutils.texi
documentation on shred more specific, to reflect the fact that shred
should, in fact, work normally in all ext3 journaling modes except
data=journal mode. Previous documentation gave the
Philip Rowlands [EMAIL PROTECTED] wrote:
I'm missing a feature in cut(1) and wanted to know if i) one can change
the behaviour of the return fields or ii) add an additional parameter
(let's say -F) to GNU cut. The latter option would ensure that things
don't get broken, whereas the first option
than number of blocks, seems to work fine though.
Thanks for the report!
I've made this change:
2005-06-21 Jim Meyering [EMAIL PROTECTED]
* tests/du/deref-args: Use --apparent-size to avoid the vagaries
of counting blocks. Kevin Mudrick reported that this test would
fail
[EMAIL PROTECTED] wrote:
...
OK, I'll have a look. FreeBSD seems to be faster again,
(don't compare these results to the previous mail):
[I've just noticed you used `sha1' below.
Is that a shell alias or function?
The program from coreutils is called sha1sum. ]
$time sha1 15MBfile
[EMAIL PROTECTED] wrote:
Does `mv (coreutils) 5.2.1' preserve hard links? In particular
Yes.
If you can make it fail to preserve links, please report it
with as much detail as possible.
Also, you might want to try the latest test release:
William Brendling [EMAIL PROTECTED] wrote:
The second iteration of my patch to du to show last modified date follows.
...
Thank you for the patch.
I've applied it, albeit with some difficulty due to changes
in leading white space and split lines caused no doubt by your
mail client.
I've made
[EMAIL PROTECTED] (James Youngman) wrote:
On Thu, Jun 23, 2005 at 08:45:05PM +, Eric Blake wrote:
This puts the invocation of rm without arguments in the
implementation's realm, where currently, coreutils is not consistent
on what it returns:
$ rm
rm: missing operand
Try `rm --help'
Paul Eggert [EMAIL PROTECTED] wrote:
I noticed the following disagreement between gnulib and coreutils:
--- gnulib/lib/canon-host.c 2005-05-13 23:03:57 -0700
+++ cu/lib/canon-host.c 2005-05-14 00:58:06 -0700
...
I assume that this was due to a warning from gcc -W about a missing
301 - 400 of 4474 matches
Mail list logo
