I installed this, to fix some errno glitches that I noticed when
writing the other paste patches.
2004-09-02 Paul Eggert [EMAIL PROTECTED]
Output correct errno-related diagnostic on paste I/O errors.
* src/paste.c (write_error, xputchar): New functions.
(paste_parallel
[EMAIL PROTECTED] (Paul Jarc) writes:
Sort of, but not quite.
I couldn't find the not quite part of your explanation.
Well, I tried. :-)
sort -rR should output in the reverse order of sort -R.
Nit: they shouldn't expect that unless they also specify a seed.
Yes, of course.
But sort -R
Thomas Habets [EMAIL PROTECTED] writes:
They may be the same number, but they sure aren't treated as equal
(sort-order equal) by sort. sort -n gives 3 3.0 3.000 every time
here, no matter the input order. As does 3 03 3.
That is because ties are broken at the end by a last-resort textual
) issue. You can find the POSIX conversions at
http://www.unix.org/version3/, in the dd man page there.
2004-09-03 Paul Eggert [EMAIL PROTECTED]
* coreutils.texi (dd invocation): Specify which conversion options
are mutually exclusive. Give a bit more detail about ascii
I installed this minor code cleanup. The only externally-visible
effect is to improve the quality of diagonstics for invalid usages of
incompatible conversions, and to fix a typo in the usage message.
2004-09-03 Paul Eggert [EMAIL PROTECTED]
* src/dd.c (usage): alternated EBCDIC
Crox Alexander Sanchez Rodriguez [EMAIL PROTECTED] writes:
I got this error from 'make check' on my Solaris 8 system, before
installing coreutils:
make[3]: Entering directory `/opt/sfw/src/coreutils-5.2.1/tests/stty'
FAIL: row-col-1
That's odd, as I don't get a problem when running make
Thanks for your 'stat' bug reports. I installed the following patch
to address your issues, and to simplify the code a bit.
2004-09-03 Paul Eggert [EMAIL PROTECTED]
* src/stat.c (HAVE_STRUCT_STATXFS_F_TYPE): Fix typo that prevented
it from ever being nonzero. Reported
While looking into coreutils's use of getopt, I noticed some bugs
in stty (not too surprising, as hacky as it is). I installed this
patch to fix the bugs I found, and clean up the code a bit.
2004-09-05 Paul Eggert [EMAIL PROTECTED]
* src/stty.c (valid_options): Remove.
(main
While fixing the aforementioned bugs I noticed some minor cleanup
possibilities in stty.c and installed this patch.
2004-09-05 Paul Eggert [EMAIL PROTECTED]
* src/stty.c (recover_mode): Arg is now char const *, not char *.
(main): Use STDIN_FILENO, not 0.
Simplify
Dan Jacobson [EMAIL PROTECTED] writes:
The docs make it look like test -n STRING and test STRING do the
same. However,
$ /usr/bin/test ``; echo $?
1
$ /usr/bin/test -n ``; echo $?
0
$ test ``; echo $?
1
$ test -n ``; echo $?
0
Those test cases are misleading, since they use ` (accent
Lucas Nussbaum [EMAIL PROTECTED] writes:
So 12345K 1M, but I think it is acceptable if
properly documented (no software will never output 12345K).
Unfortunately some software does output 12345K. For example:
$ echo '' | dd bs=1 seek=12641279 of=big
1+0 records in
1+0 records out
$ ls -l
Dan Jacobson [EMAIL PROTECTED] writes:
Please add a warning.
There's already a warning in the coreutils documentation, but I made
it a bit more explicit as follows:
2004-09-05 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (String tests): Improve quality of warning about
While looking at coreutils option processing I noticed that
od had a FIXME and a few other compatibility problems with
respect to POSIX and FreeBSD. I installed the following patch
to fix the problems I found.
2004-09-06 Paul Eggert [EMAIL PROTECTED]
* NEWS: Describe the following
Torkel Bjrnson [EMAIL PROTECTED] writes:
$ setenv BLOCK_SIZE human-readable
$ df --portability /
FilesystemSize Used Avail Use% Mounted on
/dev/sda1 177M 111M 57M 66% /
I think the last output is wrong. Since I request an output
format in compability/POSIX
Dmytro Taranovsky [EMAIL PROTECTED] writes:
mkdir: cannot create directory `new/new': No such file or directory
Here's another good one:
$ mkdir /bin/sh/foo
mkdir: cannot create directory `/bin/sh/foo': Not a directory
mkdir should print a more accurate error message,
Well, the existing
It might be worth mentioning that stat exit status bug was fixed in
a different way in CVS coreutils, I think in the 2004-08-03 patch. At
least I don't observe the bug now. Here's a brief summary of that
patch and a URL:
2004-08-03 Paul Eggert [EMAIL PROTECTED]
* src/stat.c (G_fail
Bruno Haible [EMAIL PROTECTED] writes:
It has the effect of changing the locale in an undesired way, when a mixed
locale is in effect. At least on AIX (all tested versions) and, if I recall
it correctly, also on Linux/libc5.
Aack. Thanks for mentioning that. I reverted the change, which I
I installed this patch to fix the bug recently mentioned by Glenn
Fowler, and also to document the argument-reordering properties of GNU
coreutils a bit better.
2004-09-08 Paul Eggert [EMAIL PROTECTED]
* NEWS: Document that tr xy -z now works as per POSIX.
Sort the descriptions
Dan Jacobson [EMAIL PROTECTED] writes:
plain
$ test
with no arguments is not documented.
Thanks. I added the following patch, with a similar patch to
coreutils.texi:
2004-09-08 Paul Eggert [EMAIL PROTECTED]
* src/test.c (usage): Document test (with no args) and [ ].
Index: src
Thanks for the documentation-improvement suggestion. I installed the
following (terser) patch.
Index: doc/coreutils.texi
===
RCS file: /home/eggert/coreutils/cu/doc/coreutils.texi,v
retrieving revision 1.208
diff -p -u -r1.208
Javier Fernndez-Sanguino Pea [EMAIL PROTECTED] writes:
On Wed, Sep 08, 2004 at 09:17:01PM -0700, Paul Eggert wrote:
Good, however, it only acknowledges the -e proposed documentation change.
There were also -w and -x ammendments in my patch... Are you going to
include them?
-e, -w, and -x
Stepan Kasal [EMAIL PROTECTED] writes:
I think the documentation still misses one thing, see the patch below.
Thanks. Good point. The doc was a bit messy so I installed the
following more-ambitious patch instead.
2004-09-09 Paul Eggert [EMAIL PROTECTED]
* coreutils.texi (sort
and doesn't describe all the
reasons why test -w FILE would succeed but writing to the file would
fail, so I installed the following patch instead. Thanks for
following up on this.
2004-09-09 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (test invocation):
Document -r, -w, -x
[EMAIL PROTECTED] (Bob Proulx) writes:
However, I can't see anywhere that expr is defined to always read
integers as decimal values.
The current documentation says under expr invocation
Operands are either integers or strings. Integers consist of one or
more decimal digits, with an optional
Cintia Del Rio [EMAIL PROTECTED] writes:
As you can see, it's messy to understand. Of course I didn't want
anything like this. I was thinking that a hexadecimal short would
give to me TWO HEXADECIMAL DIGITS, and not two bytes.
The latest CVS od --help now says:
-x same as -t x2, select
[EMAIL PROTECTED] (Bob Proulx) writes:
integer
An argument consisting only of an (optional) unary minus followed by
digits.
It also says, for example:
expr1 + expr2 Addition of decimal integer-valued arguments.
So, under your interpretation, expr 010 would print 8, but expr 010
+ 0
Bert Fischer [EMAIL PROTECTED] writes:
It is probably not a bug, but you might be interested anyway. Running
`make check' after building coreutils-5.2.1 I get a failed test for rm.
Odd; make check works for me with coreutils-5.2.1 on Solaris 9 (sparc).
Can you please try running the
Thomas Habets [EMAIL PROTECTED] writes:
Once upon a midnight dreary, Paul Eggert pondered, weak and weary:
Or should a random permutation merge all equal values?
Only if the ordinary sort would merge the equal values (i.e., if the
-u option is specified).
I mean merge them, then sort
return code:
$ id -gn fuu
id: unknown gid 199
$ echo $?
1
Yes that sounds right. Doesn't GNU id do that already, though?
2004-09-13 Paul Eggert [EMAIL PROTECTED]
* src/id.c (print_full_info): Don't exit with failure status simply
because a user or group number can't
[EMAIL PROTECTED] (Bob Proulx) writes:
The who program really can't do anything more than this. This also
applies to the other utmp programs such as finger and w.
But the interesting thing is that finger and w do do more than this;
the omit the dangling entry somehow.
If you log in again
I installed this; it doesn't change any behavior but cleans things up
a bit.
2004-09-18 Paul Eggert [EMAIL PROTECTED]
* src/cksum.c: Remove obsolete comment about POSIX 1003.2/D11.2.
The current standard (POSIX 1003.1-2004) is correct.
(crc_remainder) [defined CRCTAB
POSIX requires dd -- to behave like plain dd, but GNU dd doesn't
support this. Also, in the documentation and diagnostics, GNU dd
refers to operands as options in several places. I installed this fix:
2004-09-18 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (dd invocation
I installed this minor code cleanup; it doesn't fix any bugs.
I notice that md5sum's --string option isn't documented; is this
intentional?
2004-09-18 Paul Eggert [EMAIL PROTECTED]
* src/md5sum.c (STATUS_OPTION, STRING_OPTION): New enums.
(long_options, main): Use them instead
[EMAIL PROTECTED] writes:
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_03
`info libc TZ Variable`
suggests that implementation dependent TZs should start with a colon.
That advice is admirable but is quite rarely followed. In practice,
people almost
coreutils patch. Can you please try
it on your host? I was still unable to reproduce the problem on my
Solaris host, perhaps due to my own userid pattern. Thanks.
2004-09-19 Paul Eggert [EMAIL PROTECTED]
* tests/rm/fail-eperm: Don't try to remove writable files in a
sticky
Jim Meyering [EMAIL PROTECTED] writes:
I notice that md5sum's --string option isn't documented; is this
intentional?
It may be safely removed, now :-)
Goody, I love removing code. :-)
I installed this:
2004-09-19 Paul Eggert [EMAIL PROTECTED]
* src/md5sum.c (STRING_OPTION
I installed the following patch to fix a bug I introduced a few months
ago; sorry about that.
2004-09-19 Paul Eggert [EMAIL PROTECTED]
* src/echo.c (main): Don't pass NULL to strcmp when
POSIXLY_CORRECT and given no arguments.
Index: echo.c
Munzir Taha [EMAIL PROTECTED] writes:
This is not accurate due to localization. In Arabic for example, I can
response with the first letter of the Arabic word for Yes and it works.
Thanks for reporting this. I installed this fix:
2004-09-20 Paul Eggert [EMAIL PROTECTED
Jim Meyering [EMAIL PROTECTED] writes:
Just in case you didn't do the part for `man rm', here it is:
Thanks, I'd missed that. I installed your fix too.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
weird names that might look like options)
and that the following commands reject unknown options:
basename dirname factor hostname link nohup sync unlink yes
2004-09-21 Paul Eggert [EMAIL PROTECTED]
* NEWS: The following commands now reject unknown options:
basename dirname
Richard Stallman [EMAIL PROTECTED] writes:
I think a better solution is if we can turn off the new feature
of adapting the column widths to the data.
One way would be to extend --format to allow fairly arbitrary formats
that can specify column widths. For example, Emacs could do this:
ls
is rejected when in POSIX 1003.1-2001 mode
pending resolution of this issue at the Open Group level.
2004-09-23 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (tail invocation): Fix bugs in the description of
the obsolete syntax (e.g., it does not support -k or -m). Warn
Hans Ecke [EMAIL PROTECTED] writes:
Is there any way that chmod could first see if the requested status
change has already been fulfilled, and skip files where it would not
change anything?
Offhand I don't see why not. POSIX allows this behavior.
I can see that this would slow chmod down
Here's a proposed patch to implement RMS's request to support Emacs
dired fixed-width columns. It's a bit of a quick hack, and is
therefore undocumented. A better long-term approach is to allow
arbitrary formats, but that'd take more work (notably in the
documentation) and this is simpler.
This
Toralf Frster [EMAIL PROTECTED] writes:
http://bugs.gentoo.org/show_bug.cgi?id=53881
Those symptoms don't appear to come from coreutils 5.2.0,
so I suspect that it was a bug introduced in the Gentoo port.
___
Bug-coreutils mailing list
[EMAIL
Alexandre Peshansky [EMAIL PROTECTED] writes:
ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.1.tar.gz
Nope, same error:
make[3]: Entering directory `/home/aproot/coreutils-5.2.1/tests/stty'
FAIL: row-col-1
I don't observe these symptoms on my Solaris 8 host. Here is some of
my system
Dan Jacobson [EMAIL PROTECTED] writes:
$ env k-o=4 ...
OK, thanks, I installed this patch to address this and a somewhat-related
issue (special built-in utilities).
2004-10-11 Paul Eggert [EMAIL PROTECTED]
* coreutils.texi (Special built-in utilities): New node.
(printf
Micha Kosmulski [EMAIL PROTECTED] writes:
I am using a UTF-8 locale and all coreutils except for tr seem to
agree on that. However, tr behaves differently and seems to always
assume that 1 byte == 1 character even in a UTF-8 locale.
Most coreutils utilities do not support UTF-8 in general,
Dan Jacobson [EMAIL PROTECTED] writes:
Sure hope microsecond differences seen by
touch -r a b; stat -c %y a b
are fixed by it too.
touch operates by means of system calls. If the system calls
mishandle submicrosecond time stamps, touch will as well. So you'll
have to direct your bug reports
OK, apparently the test is failing whenever stty rows 0 columns 0
is run.
How are you running the test? I.e., are you running it from an xterm,
from Emacs, or what? Are you redirecting stdin, stdout, or stderr?
What happens when you run these commands, on a fresh terminal,
without any I/O
Dan Jacobson [EMAIL PROTECTED] writes:
BTW, in Info are you sure
$ LC_CTYPE=zh_CN.big5 /usr/local/bin/printf \
'\u4e2d\u6587\n' sample.txt
does what you intend?
You need to have the proper locale support. I'm not sure
what qp-encode is supposed to do, so I'm not sure what
to
Most likely you are sorting in a locale that discards information
about quotes and spaces before doing comparison. Try setting the
environment variable LC_ALL to C and then sorting. The command
sort --help talks about this briefly, and the documentation says
more.
Alexandre Peshansky [EMAIL PROTECTED] writes:
bash-2.03$ ssh -V
ssh: SSH Secure Shell 3.2.0 (non-commercial version) on sparc-sun-solaris2.8
...
bash-2.03$ src/stty rows 0 columns 0
bash-2.03$ truss -v ioctl src/stty size
...
ioctl(0, TCGETS, 0xFFBEFA80)= 0
Alexandre Peshansky [EMAIL PROTECTED] writes:
From the above it looks like ioctl cannot find ldterm.dat where it
looks for it (/usr/lib/locale/C/LC_CTYPE/ldterm.dat). On my system
I found it in /usr/lib/locale/en_US.UTF-8/LC_CTYPE/ldterm.dat I
created symlink to it in
this change instead?
2004-10-13 Paul Eggert [EMAIL PROTECTED]
* tests/stty/row-col-1: Set LC_ALL=C.
Index: tests/stty/row-col-1
===
RCS file: /fetish/cu/tests/stty/row-col-1,v
retrieving revision 1.8
retrieving revision 1.9
diff
Alexandre Peshansky [EMAIL PROTECTED] writes:
Tried (applied patch) - didn't help.
At this point I'm at a bit of a loss.
Have you tried using an OpenSSH client, from a Linux box? That seems
to be the only difference between your host and mine. If you still
have a problem with OpenSSH, then
/coreutils/coreutils/src/od.c).
2004-09-27 Paul Eggert [EMAIL PROTECTED]
* src/od.c (format_address_paren): c is optional, so don't output
it if it's '\0'.
--- old/src/od.c6 Sep 2004 07:46:43 - 1.151
+++ new/src/od.c28 Sep 2004 01:09:03 - 1.152
Donn Washburn [EMAIL PROTECTED] writes:
After a very clean compile on a SuSE 9.0 box of coreutils 5.2.1.
I modified the directories only for make install. From Xwindows
su request the root passwd. If I suppy it I get
[EMAIL PROTECTED]:/media/hdb2/xap su
Password: correct password typed
I installed this minor code cleanup:
2004-10-04 Paul Eggert [EMAIL PROTECTED]
* src/expr.c (NEW, OLD): Remove, partly to avoid
reference to obsolescent macro XMALLOC.
All uses replaced by xmalloc and free.
--- src/expr.c 3 Aug 2004 06:00:24 - 1.95
+++ src
[EMAIL PROTECTED] writes:
In general I don't agree with the unlocked versions of the glibc
functions being exposed.
I'm afraid that ship has already sailed, as POSIX (with the
Thread-Safe Functions extension) requires support for functions like
getc_unlocked.
Couldn't glibc set a flag
Mike Westall [EMAIL PROTECTED] writes:
Any ideas whats up with this
What happens when you compile and use the latest stable coreutils
release instead? That way, we can try to isolate whether your problem
is specific to Red Hat's changes to sort.
Alexandre Peshansky [EMAIL PROTECTED] writes:
This is a report of the test failed when doing 'make check' for
coreutils-5.0 on Sun Solaris.
I suspect that bug is fixed in the current coreutils version, here:
ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.1.tar.gz
[EMAIL PROTECTED] writes:
Although not a bug, sort's documentation might be wise to explicitly
mention that -u's behaviour is effected by options like -n.
The CVS version of coreutils
http://savannah.gnu.org/projects/coreutils/ says this
in its Texinfo documentation:
The commands @code{sort
Dan Jacobson [EMAIL PROTECTED] writes:
# stat -c %y m o
2004-10-10 01:56:36.561517778 +0800
2004-10-10 01:56:36.561517000 +0800
which must be the key to why cp -up will update repeatedly.
Yes, that most likely explains it. Here's a patch:
[EMAIL PROTECTED] (Bob Proulx) writes:
I am unable to reproduce the problem locally.
I think your attempt didn't capture all the relevant parts of the bug.
Here's how I reproduced it, both with coreutils 5.2.1 and with CVS
coreutils. On my host, /tmp and /home are different file systems;
this
I installed the following patch to fix some bugs in pathchk.
It was easier to rewrite most of the guts rather than to fix
each bug one by one, so I took the liberty of adding m'self
to the credits.
2004-10-17 Paul Eggert [EMAIL PROTECTED]
* AUTHORS: Add self to pathchk.
* doc
none none [EMAIL PROTECTED] writes:
[15:39:08]$ touch -d '20041001 18:00 +0400' test
[15:39:21]$ ls -al test
-rw--- 1 user users 0 2004-10-01 14:00:21 test
Thanks for reporting that; the bug has been fixed in CVS coreutils.
___
Bug-coreutils
Often this means that your utmp file is corrupted. When files like
that go bad, different commands interpret them differently.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
I installed this patch to make the documentation clearer:
2004-10-20 Paul Eggert [EMAIL PROTECTED]
* src/fmt.c (usage): Improve description of --prefix.
Problem reported by Edward Welbourne.
Index: fmt.c
===
RCS
Could you please forward your suggestion to the Dutch translator for
coreutils?
http://www2.iro.umontreal.ca/translation/registry.cgi?team=nl says
that coreutils is assigned to Freek de Kruijf. You probably first
want to check the latest translations in
I installed this, since pathchk as of 2004-09-21 wants options before
operands:
2004-10-24 Paul Eggert [EMAIL PROTECTED]
* coreutils.texi (pathchk invocation): Options must precede operands.
Index: coreutils.texi
===
RCS
Nico Schottelius [EMAIL PROTECTED] writes:
What I am asking you: Why does chown accept arguments, which are
not at the beginning? Is that a glibc bug or feature?
It's a feature. To avoid the problem, prepend ./ to *, e.g.,
chown nico.nico ./*.
You'll run into similar problems with commands
I installed this in an attempt to keep up with the POSIX
interpretations process:
2004-10-28 Paul Eggert [EMAIL PROTECTED]
* coreutils.texi (Standards conformance): Use head -10 rather
than head -1 as example of obsolete usage, since the POSIX
consensus is that head -1
environment variables (e.g., LC_ALL) are all
documented together? Just a thought.
2004-10-29 Paul Eggert [EMAIL PROTECTED]
* coreutils.texi: Document TZ better, and adjust to new getdate.texi.
(Top): Update menu.
(pr invocation, Formatting file timestamps, touch invocation
by Paul Eggert [EMAIL PROTECTED] in August 1999 to do
- the right thing about local DST, and in February 2004 to support
- nanosecond-resolution time stamps. Unlike previous versions, this
- version is reentrant. */
+ the right thing about local DST. Also modified by Paul Eggert
+ [EMAIL
I installed this:
2004-10-29 Paul Eggert [EMAIL PROTECTED]
* NEWS: Document getdate changes.
Index: NEWS
===
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.245
retrieving revision 1.246
diff -p -u -r1.245 -r1.246
Daniel Richard G. [EMAIL PROTECTED] writes:
Building coreutils-5.2.1 on a Sun machine, with the source tree on a
separate read-only NFS mount:
Sun's make doesn't support VPATH well. As mentioned in the
coreutils INSTALL file, you need a version of make that supports
VPATH if you want to
Daniel Richard G. [EMAIL PROTECTED] writes:
I made do with gmake, but it's typical for an Autotools-based source tree
to support out-of-tree builds without needing GNU Make.
It often works with simpler builds, yes. But I've had a lot of trouble
with more-complicated ones. It's not worth
Albert Chin [EMAIL PROTECTED] writes:
Solaris 2.5.1 has uint32_t in synch.h.
Also in pthread.h and semaphore.h.
So, how do we solve this? Do I augment m4/uint32_t.m4 to include
synch.h if available and then add:
#ifdef HAVE_SYNC_H
#include sync.h
#endif
wherever uint32_t is needed?
Albert Chin [EMAIL PROTECTED] writes:
This worked. Please apply.
OK, I applied this change to coreutils:
2004-11-03 Paul Eggert [EMAIL PROTECTED]
* src/system.h: Don't #define and #undef getopt around stdlib.h,
as this breaks the new regime that does #define getopt
m4 files. Jim Meyering
fixed some of this, and I installed this to try to fix the rest:
2004-11-03 Paul Eggert [EMAIL PROTECTED]
* lib/Makefile.am (libfetish_a_SOURCES): Remove setenv.c.
* m4/prereq.m4 (gl_PREREQ): Require gt_FUNC_SETENV.
* m4/setenv.m4: New file, from
(Sorry, I mis-sent the following email to bug-gnulib. Here it is
again, at the right place.)
I installed this obvious fix:
2004-11-03 Paul Eggert [EMAIL PROTECTED]
* src/stty.c: Include vasprintf.h since we use vasprintf now.
--- stty.c.~1.128.~ 2004-09-21 15:12:13 -0700
Wes Hardin [EMAIL PROTECTED] writes:
It seems to me that at a minimum, you'd want as many responses to
match across OSes on the same hardware.
That would be nice, but it's more important for GNU uname to print
the same thing that Solaris uname does, for compatibility reasons.
Typically, the
QUAZI ISLAM [EMAIL PROTECTED] writes:
I'm trying switch new user in Solaris 8 by using su - ortorg and it
takes about a minute to change it.
But if I do su - qislam it change immediately.
Most likely this is something to do with problems accessing
ortorg's home directory, or executing their
Brendan Byrd/SineSwiper [EMAIL PROTECTED] writes:
I hashed out a patch for mv which is more or less the opposite of the
--symbolic-link option for cp. Instead of creating symlinks on the
destination before the copy, it creates symlinks on the source after
the move.
Before we talk about the
karl s. eiringer [EMAIL PROTECTED] writes:
(it seems that original is excluded first, but '*' includes the
directories [original + subdirs] again)
Yes, that's right. The documentation says that --exclude applies only
when recursing; it doesn't apply to the top-level command-line
arguments.
it more
consistent to uniformly use size_t for indexes.
2004-11-05 Paul Eggert [EMAIL PROTECTED]
* src/sort.c (inittables, sort_buffer_size, getmonth, mergefps,
first_same_file, merge, sort, main): Use size_t for indexes into arrays.
This fixes some unlikely havoc-wreaking
really need is a 16-to-1 merge followed by a
2-to-1 merge. I installed this patch.
2004-11-06 Paul Eggert [EMAIL PROTECTED]
* src/sort.c (first_same_file): Remove. Move most of the code to
(avoid_trashing_input): New function.
(merge): Avoid some silly merges, e.g
Brendan Byrd/SineSwiper [EMAIL PROTECTED] writes:
Hmmm...it was in an attachment, according to my Sent file. I guess
the mailing list doesn't support attachments.
The mailing list supports attachments (e.g., see
http://lists.gnu.org/archive/html/bug-coreutils/2004-10/msg00066.html)
but your
John Lowe [EMAIL PROTECTED] writes:
strftime.c:63: header file 'wchar.h' not found
Does the following patch to lib/strftime.c fix things for you?
--- strftime.c 2003-09-29 23:44:01 -0700
+++ /tmp/strftime.c 2004-11-08 09:53:22 -0800
@@ -56,10 +56,10 @@ extern char *tzname[];
Jim Meyering [EMAIL PROTECTED] writes:
Vacillating even more, do I want cp ever to remove its source FILEs?
Probably not. That's a strong argument to making this an 'mv' option
rather than a 'cp' option.
For now, I'm inclined to add an option to cp rather than mv,
but am open to arguments
I installed this:
2004-11-10 Paul Eggert [EMAIL PROTECTED]
* config/texinfo.tex, lib/allocsa.h, lib/mbswidth.c, lib/mktime.c,
lib/readlink.c: Sync from gnulib.
--- config/texinfo.tex 3 Nov 2004 07:44:15 - 1.49
+++ config/texinfo.tex 11 Nov 2004 04:58:29 -
Inspired by the recent changes to mktime.c for right-shift on Crays, I
installed similar changes to getdate.y, strftime.c, and quotearg.c.
This is both for gnulib and for coreutils:
2004-11-10 Paul Eggert [EMAIL PROTECTED]
* lib/getdate.y (SHR): New macro, which is a portable
Ramrez Snchez-Escobar Jos Julio [EMAIL PROTECTED] writes:
medusa1.cbm.uam.es 84% head -{1,v} 2_md6_cool_min.outmd ; tail -{1,v}
2_md6_cool_min.outmd
== 2_md6_cool_min.outmd ==
tail: -v: No existe el fichero o el directorio
== 2_md6_cool_min.outmd ==
| wallclock() was called 390080
I installed this patch to have sort warn if a temporary file can't
be removed in normal operation (e.g. because someone did a chmod a-w
/tmp in the middle of the sort :-). Also, I removed some code from
the critical section and tuned zaptemp a bit.
2004-11-12 Paul Eggert [EMAIL PROTECTED
, but I just checked POSIX and it allows this
behavior so I turned it on unconditionally.
In theory this change might break some scripts. Does anybody think
this will be a problem in practice? If so, I suppose we could enable
the new behavior only conditionally.
2004-11-14 Paul Eggert [EMAIL
[EMAIL PROTECTED] writes:
Personally I don't think sending SIGUSR1 is a user friendly interface
I agree. Also, its implementation isn't portable: it assumes that
stdio is reentrant, which isn't true in general. This should get
fixed at some point.
But it's not just SIGUSR1. I think this
Paul Eggert [EMAIL PROTECTED] writes:
Come to think of it, if we wanted to support progress-bar add-ons, the
output line should also contain a full byte count,
While adding this I also tuned the diagnostic a bit (using more-standard
SI forms, e.g.). And I discovered that we do need to be able
.
Fortunately (:-), these dates weren't documented either. For now, I
installed the following patch into both gnulib and coreutils; it
causes last june to be rejected as a syntax error. If someone wants
to add support for this usage that'd be even better.
2004-11-16 Paul Eggert [EMAIL PROTECTED
I looked at the Debian 5.2.1-2 patches for the coreutils texinfo
documentation and was inspired to write the following patch. It uses
my own wording but addresses the Debian issues.
2004-11-16 Paul Eggert [EMAIL PROTECTED]
* coreutils.texi: Changes inspired by Debian coreutils 5.2.1-2
301 - 400 of 3246 matches
Mail list logo
