-18 Paul Eggert [EMAIL PROTECTED]
* lib/mountlist.c (ME_DUMMY) [!defined ME_DUMMY]: Ignore none
file systems. Problem reported by Bob Proulx.
Ignore proc file systems. Problem reported by [EMAIL PROTECTED]
(read_file_system_list): Make the parsing of dev=... more
.
Admittedly the attack is unlikely, but we should install something
like the following fix right away. Jim, I assume we're still in a
code-freeze now, so I won't install this, but it does look like a
fairly safe fix
2005-10-18 Paul Eggert [EMAIL PROTECTED]
* src/dircolors.c (append_quoted
[EMAIL PROTECTED] (Eric Blake) writes:
I was unable to determine from POSIX if this behavior is permissable
(close changing the timestamps of an open file descriptor
There wouldn't be much point to futimes() if the behavior were permitted.
POSIX is pretty careful in specifying when st_atime,
techno [EMAIL PROTECTED] writes:
[techno][7:35][~/coreutils-5.91]% ./configure
./configure:42: command not found: chmod
Jim's advice about BSD/OS 3.1 is good, but I'd like to get to the
bottom of the problem, and to do this I need to figure out exactly
in what way the BSD/OS 3.1 shell is
Andreas Schwab [EMAIL PROTECTED] writes:
How about adopting the C rule of parsing and use at most 3 digits in octal
escapes?
Makes sense. C says that octal escapes may be at most 3 digits, and
\400 is an error (assuming 8-bit chars).
C also says that hex escapes are of unlimited length.
Eric Blake [EMAIL PROTECTED] writes:
CVS cygwin has now been patched so that utimes() first searches for
open file descriptors visiting the same name, so that utimes() can
clear the scheduled update and close() no longer interferes, so no
patch is needed to coreutils.
That fixes this
Eric Blake [EMAIL PROTECTED] writes:
So am I allowed to assume 8-bit chars, or should I add code that checks
for char overflow, one hex digit at a time? And with 8-bit chars, should
\x100 parse as \x10 0, or should it raise a parse error?
Nevermind I see now that printf.c bypasses all
Paul A. Clarke [EMAIL PROTECTED] writes:
I don't think the GPFS use of dev= is documented.
That's OK. Hardly any of this is documented. What does GPFS use
dev= for? Does the patch I sent work for GPFS?
why is the df command looking for dev= in the mount options of
filesystems which don't
cp's behavior with fifos is sometimes not what one might want, but it
is traditional and standardized by POSIX and the default probably
shouldn't be changed at this point. (Maybe another option could be
added, though we'd have to see the details.)
Could you suggest a specific improvement to the
installed it (the code is currently
frozen) but I'd like you to test it if possible.
2005-10-21 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (df invocation): Correct/modernize documentation
for which file systems are ignored by default.
* lib/mountlist.c: Make
Eric Blake [EMAIL PROTECTED] writes:
It seems fishy that global lines do not cause errors, but terminal
specific ones do. Consistency would argue that we might want to also
check lines not belonging to the current terminal for validity, although
that requires a bigger change to dircolors.c
Dmitry V. Levin [EMAIL PROTECTED] writes:
Is this code duplication necessary? What about moving common code
to separate file?
It's not necessary as far as I know, and could be factored out.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Mikulas Patocka [EMAIL PROTECTED] writes:
The compilation gets a bit further with the patch, but it still
doesn't work --- this time it is problem of intel compiler --- it
can't extract its intercode from *.a files.
The Intel compiler mishandles static libraries? That sounds like
a real
Eric Blake [EMAIL PROTECTED] writes:
For the test mentioned above, a workaround in mkdir-p.c can be written
that skips the optimization of an initial stat() on platforms where stat()
can wrongly succeed
I'd been thinking of removing that initial stat() on all platforms,
under the argument
Thomas Templin [EMAIL PROTECTED] writes:
German translation of uname -r and uname -v is irritating
so is the english explanation
For the German translation, please contact the email addresses at
the start of the file po/de.po as they are in charge of that.
Thanks.
$ uname -v
#1 Mon Oct 10
Here's a proposed patch for that Cygwin incompatibility, which also
addresses several other issues. This is probably too big for the next
stable release, though, as it's a bit more than just a bug fix.
One of the side effects of this change is that 'mkdir' and 'install'
may not chdir back to the
Wyman Miles [EMAIL PROTECTED] writes:
Below is a diff. The changes are rather minor.
Hmm, can't this be done with a simple shell script wrapper, which does
the necessary arithmetic?
Any chance this can make it into the next rev of coreutils?
The next revision will be bug-fix only I think.
Daniel Kahn Gillmor [EMAIL PROTECTED] writes:
I don't know enough about the underlying system calls needed for such
a feature,
My kneejerk reaction is that this can currently be done only on
fancier OSes like Solaris. Maybe GNU/Hurd is fancy enough; I don't
know. As I understand it Debian
I installed this patch to fix a bug I found by inspecting the strace
output for ln. It's hard to write a test case for it, since it
requires write access to /.
2005-10-28 Paul Eggert [EMAIL PROTECTED]
* src/ln.c (FILE_BASENAME_CONCAT): Omit unnecessary slashes in the
boundary
How about this patch? I think it addresses all issues raised so far
on this thread.
2005-10-28 Paul Eggert [EMAIL PROTECTED]
* src/ln.c (do_link): In diagnostics, don't mention operands when
we know they did not contribute to the error.
--- src/ln.c.~1.153.~ 2005-10-28 15
, both in gnulib and coreutils.
2005-10-28 Paul Eggert [EMAIL PROTECTED]
* lib/savedir.c (savedir): Don't assume that xrealloc etc. leave
errno alone. Problem reported by Frederic Jolliton.
--- lib/savedir.c 19 Sep 2005 17:28:15 - 1.26
+++ lib/savedir.c 28
Theodoros V. Kalamatianos [EMAIL PROTECTED] writes:
It seems that my distribution (Mandrake 10.1) in the high security
mode restricts access to /proc,
Thanks for tracking that down. Does the following patch fix things
for you?
2005-10-30 Paul Eggert [EMAIL PROTECTED]
* lib
/getcwd.c
Thanks for mentioning this. I installed this patch to fix it, in both
coreutils and gnulib.
2005-10-29 Paul Eggert [EMAIL PROTECTED]
* lib/getcwd.c (__getcwd): Don't assume that system calls after readdir
leave errno alone. Problem reported by Dmitry V. Levin
Sergey Poznyakoff [EMAIL PROTECTED] writes:
OK, I just thought, however, that readdir itself is not required
to preserve the value of errno in case of succesful return.
That's correct. It must preserve errno only if it returns NULL at
the end of the directory.
In general, it seems a bad
think all of them I've installed
so far should go in :-).
2005-10-30 Paul Eggert [EMAIL PROTECTED]
Fix porting problems reported by Theodoros V. Kalamatianos.
* lib/fd-reopen.c [defined HAVE_CONFIG_H]: Include config.h,
so that large files can be opened.
* tests
Theodoros V. Kalamatianos [EMAIL PROTECTED] writes:
iskip=N : skip N bytes before each input block
iskiptail=N : skip N bytes after each input block
oseek=N : seek N bytes before each output block
oseektail=N : seek N bytes after each output block
I guess N could also be in blocks, but
[EMAIL PROTECTED] (Bob Proulx) writes:
But the hard link case is much more complicated than before. And
unfortunately does not cover the main case.
I'm afraid it's the best we can do for ENOENT without issuing more
system calls. If link(a,b) fails with ENOENT, it could be a problem
with
. Certainly glibc
itself uses /proc/self/fd in places other than its implementation of
futimes.
2005-10-30 Paul Eggert [EMAIL PROTECTED]
Fix porting problem reported by Theodoros V. Kalamatianos.
* lib/utimens.c (futimens) [HAVE_WORKING_UTIMES HAVE_FUTIMES]:
Don't assume
Thanks for the bug report archived in
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00326.html.
I installed this slightly-different patch into coreutils and gnulib:
2005-10-30 Paul Eggert [EMAIL PROTECTED]
* m4/chdir-long.m4 (gl_FUNC_CHDIR_LONG): Revamp wording and local
: `/mnt/microdrive': No such file or directory
/dev/hda7 19592804 8381160 10216372 46% /
Thanks for reporting that. I'm more inclined to install the following
patch, at least after the feature freeze is over.
2005-10-30 Paul Eggert [EMAIL PROTECTED]
* src/df.c
[EMAIL PROTECTED] (Bob Proulx) writes:
Is this on a development branch? Or just something to remember to
put in the main trunk once things are allowed to be a little
unstable again?
The latter, at least for now.
___
Bug-coreutils mailing list
That's an embarrassing bug! Thanks for reporting it. I installed
this patch into CVS coreutils (main branch).
We should add a test case but I'm not offhand sure which file it
should go into. Jim, advice?
2005-10-31 Paul Eggert [EMAIL PROTECTED]
* src/dd.c (skip): Fix off-by-one
What is the output of su --version? Perhaps it's SuSE's su and not
coreutils's.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Theodoros V. Kalamatianos [EMAIL PROTECTED] writes:
If the last output block is not obs-sized I think it is logical to
asume that no seeking/padding should happen afterwards. But I am not
sure what should happen if the block is obs-sized (i.e. a full
output block).
For lack of a better
Theodoros V. Kalamatianos [EMAIL PROTECTED] writes:
So I guess we have to fix dd to output null bytes to stdout, correct?
It should still lseek and ftruncate, if stdout is a regular file, a
directory (!), or a shared memory object.
Otherwise I guess it has to write null bytes, yes.
Vincent Lefevre [EMAIL PROTECTED] writes:
prunille:~ /opt/local/bin/gtail -c 2 blah
/opt/local/bin/gtail: cannot open `2' for reading: No such file or directory
Thanks for reporting this. I've installed the following patch.
2005-11-01 Paul Eggert [EMAIL PROTECTED]
* NEWS: tail -c
Vincent Lefevre [EMAIL PROTECTED] writes:
I have _POSIX2_VERSION=199209 to be able to use forms like head -5.
With coreutils 5.92, you don't need _POSIX2_VERSION=199209 in your
environment to use head -5. head -5 now has the traditional
meaning regardless of _POSIX2_VERSION's value. This
the following patch to minimize its scope.
2005-11-01 Paul Eggert [EMAIL PROTECTED]
* NEWS: tail -c 2 FILE and touch 010100 now operate as
POSIX 1002.1-2001 requires.
* doc/coreutils.texi (touch invocation): The old usage works only
for 1969-1999 now.
* src
[EMAIL PROTECTED] (Bob Proulx) writes:
Can you strace the program and see what the
system returns when rm tries to unlink the file?
Here's what I got on a Solaris 8 system:
lstat(junk, 0x7050) = 0
access(junk, 10) = 0
getuid()
Jim Meyering [EMAIL PROTECTED] writes:
I'd prefer that it go in tests/dd/skip-seek, partly because
the name fits, and also because I want to move away from
bourne-shell-based tests -- at least when it's easy to do so.
OK. However, I can't easily see how to modify that file to do the
test I
Jim Meyering [EMAIL PROTECTED] writes:
Here's the shell-command test I'd like to run:
test `echo abc | dd bs=1 skip=1 | cat` = bc
where the output of dd is a pipe.
I think you mean `input', there.
Yes, sorry. Anyway, thanks for stepping in and doing the work.
.
Also, we should probably remove ln --directory (-d, -F) while we're
at it, no? It has the same problem as the old rm -d.
In the meantime I installed the following patch on the mainline
branch.
2005-11-02 Paul Eggert [EMAIL PROTECTED]
* Version 6.0-cvs.
* NEWS: Mention that rm
Jim Meyering [EMAIL PROTECTED] writes:
But if someone submits a clean patch, I'll consider it.
Here's a patch that I hope is clean enough; it shortens the source
code by 18 lines. It doesn't fix any bugs so I have not installed it.
2005-11-04 Paul Eggert [EMAIL PROTECTED]
* src
Eric Blake [EMAIL PROTECTED] writes:
for cross compilation, should I be pessimistic and
make dir_name(//) always return // (unless overridden by priming the
cache, of course)? Or should I write the test with hard-coded knowledge
of the HOST values that are known to have distinct // (so far,
[EMAIL PROTECTED] (Robert Latham) writes:
In the time since the above thread was started, there is now an
implementation of lcm in src/system.h.
I'd rather use something more like buffer_lcm in diffutils, since it
handles weird cases without dumping core.
Ismail Donmez [EMAIL PROTECTED] writes:
All tr versions up to including coreutils 5.3.0 seems to be buggy
with Turkish
It's not just Turkish locales; it's multibyte locales in general.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
It's too much for an inlined function, I think.
/* Buffer primitives for comparison operations.
Copyright (C) 1993, 1995, 1998, 2001, 2002 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public
Jim Meyering [EMAIL PROTECTED] writes:
Do any of you know of platforms for which that would not work?
I.e., for which there is a useful (or better, `essential') compiler
lacking such support?
GCC 2.95.3 is still the C compiler for OpenBSD 3.6 (released November
2004), and it doesn't support
Dmitry V. Levin [EMAIL PROTECTED] writes about
http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00185.html:
Please do not forget to apply this patch, at least to development branch.
This would be an incompatible change, albeit one that I thinks make
sense, if only to be compatible
Theodoros V. Kalamatianos [EMAIL PROTECTED] writes:
Did anyone review the patch, or did it slip through the cracks ? I'd
really like to know if I need to imrove on this...
I haven't had the time to look at it yet. coreutils is still in
a feature freeze so it's not pressing.
[EMAIL PROTECTED] (Eric Blake) writes:
This in turn looks to be a bug in Solaris' /usr/include/limits.h
It's not really a bug, is it? The limits.h values have the correct
types. It's merely an incompatibility between the Solaris 7 limits.h
and GCC's warnings heuristic.
It looks like gcc
Gera, Geetanjali [EMAIL PROTECTED] writes:
If the length of a line is more than 1024 and I use fmt [fmt -s -w
77] on the file, the output file truncate characters of the line
after 1024, i.e. It does not display the characters of that line
after 1024 and continue further with next line. So,
Gera, Geetanjali [EMAIL PROTECTED] writes:
I am not quite sure about the version.
fmt --version will tell you. Here's what it says for me:
$ fmt --version
fmt (GNU coreutils) 5.93
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software. You may redistribute copies
Eric Blake [EMAIL PROTECTED] writes:
http://www.opengroup.org/austin/docs/austin_239.html mention that the
intent is to 'add to the OPTIONS except that '+' may be recognized as an
option delimiter as well as '-'.'
That won't happen for quite some time (my guess is not until 2007),
and in the
Michael Hyde [EMAIL PROTECTED] writes:
seq 1 0 2
produces a never-ending sequences of 1's. Shouldn't it just exit with
an error message?
In general, it's hard to predict ahead of time whether seq will
terminate. It's not equivalent to the halting problem, but it's
harder than it sounds.
Peter O'Gorman [EMAIL PROTECTED] writes:
I've attached the non-root verbose test failures here and a patch.
Thanks for doing that.
The patch may seem a little strange, it is. The HP-UX-10.20 compiler
does not like 64 bit types in switch statements!
Rather than modify the code, how about if
I installed the following in an attempt to address the issues brought
up in this thread, along with some other problems I noticed when
comparing GNU ln's to FreeBSD ln's behavior.
2005-11-16 Paul Eggert [EMAIL PROTECTED]
* NEWS: Improve quality of ln's diagnostics.
* doc
I installed the following documentation change to try to make the
behavior clearer.
2005-11-16 Paul Eggert [EMAIL PROTECTED]
* coreutils.texi (tail invocation): Say that the obsolete form
uses exactly one option and at most one file.
--- coreutils.texi.~1.295.~ 2005-11-16
Lemley James - jlemle [EMAIL PROTECTED] writes:
--- begin IBM note ---
Hi James,
This is not a defect. I wrote a new testcase that exhibits the same
behaviour as the one that was submitted.
IBM's test case is fine, but it's not related to the bug. The
bug, as I understand it, is
Does the following patch also work for you?
--- configure.ac.~1.71.~2005-10-23 15:59:37.0 -0700
+++ configure.ac2005-11-17 20:53:33.0 -0800
@@ -32,6 +32,7 @@ gl_DEFAULT_POSIX2_VERSION
gl_USE_SYSTEM_EXTENSIONS
gl_PERL
AC_PROG_CC
+AM_PROG_CC_C_O
AC_PROG_CPP
Phillip Susi [EMAIL PROTECTED] writes:
I searched the archives and found a thread from over a year ago
talking about adding support to dd for O_DIRECT, but it is not
documented in the man pages.
It's in coreutils 5.93 dd. Try, e.g., dd iflag=direct. It's
not documented with the phrase
Phillip Susi [EMAIL PROTECTED] writes:
The man pages at:
http://www.gnu.org/software/coreutils/manual/html_chapter/coreutils_11.html#SEC65
Those are obsolete. Unfortunately they are not generated automatically,
as they should be. I just did my quick best to bring them up to date,
and the
this
will work around the problem; if not, please let me know.
2005-11-18 Paul Eggert [EMAIL PROTECTED]
* configure.ac (AC_PROG_CC_STDC):
Use this instead of AC_PROG_CC, so that
we get a standard-conforming compiler. This relies on the new
m4/c.m4 file. Note that it's a bit
Lemley James - jlemle [EMAIL PROTECTED] writes:
I lost in my argument that they should do something about it; they are
clearly not going to.
Thanks for trying.
Does -qlanglvl=extc99 and/or -qlanglvl=extc89 fix the problem?
If so, we're done, since my installed-on-Friday patch will use that.
[EMAIL PROTECTED] writes:
This would suggest to me that md5sum -c reads the files in the checklist from
the wrong directory when directorynames look similar, perhaps because it is
truncating the names or something similar?
That would be bad, yes. Can you isolate the problem to a one-line
Vance, Jack D. [EMAIL PROTECTED] writes:
Hello - can you please tell me what the numeric value is in the following
output?
000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
1415102464.
The command used was od -Ad -tx1 run on a wiped 10.0GB hard drive with
10,005,037,056 bytes.
, but I thought I'd ask to make
sure.
2005-11-22 Paul Eggert [EMAIL PROTECTED]
* src/remove.c (AD_push): Remove assert that doesn't compile.
(rm): Don't assume C99 for (int i = ..., since GCC 4.0.2 rejects
it in default mode.
--- remove.c.~1.137.~ 2005-11-22 13:08
I took a very quick look and have one other comment:
-components of the specified directories\n\
+ components of the specified directories\n\
This isn't right: those should be leading spaces, without any tabs.
Perhaps you put the source code through
things. I installed the following instead. Thanks for
prompting us to look into the problem.
2005-11-23 Paul Eggert [EMAIL PROTECTED]
* src/copy.c: Improve performance a bit by optimizing away
unnecessary system calls and going to a block size of at least
8192
in an attempt to work around all
these problems. I'll also suggest a similar patch to gnulib.
2005-11-25 Paul Eggert [EMAIL PROTECTED]
* lib/Makefile.am (stdbool.h): Just copy stdbool_.h; no need to sed
any more.
* lib/stdbool_.h: Simplify greatly, under the assumption
POSIX reserves names ending in _t, and anyway I suspect that a system
header somewhere might declare ulonglong_t, so I installed this:
2005-11-25 Paul Eggert [EMAIL PROTECTED]
* src/od.c (unsigned_long_long_int): Renamed from ulonglong_t,
to avoid collision with POSIX name
I've installed this coreutils patch to fix the dev= issues you raised
last month.
2005-11-25 Paul Eggert [EMAIL PROTECTED]
* mountlist.c: Include limits.h.
(dev_from_mount_options)
[defined MOUNTED_GETMNTENT1 || defined MOUNTED_GETMNTENT2]:
New function
I've installed the patch along the lines that I proposed in early
October about this issue. Here it is again, slightly modified to
also treat inaccessible mounts as dummies, since they can happen
with shadowed mount points.
2005-11-25 Paul Eggert [EMAIL PROTECTED]
* NEWS: df updates
I'm puzzled as to why, in this day and age, shred (and any other
programs that might need lots of hard-to-guess random numbers) needs
to have its own random number generator. Why can't such programs just
read /dev/urandom? Is it because they need to fall back on something
on hosts that lack
Tim Waugh [EMAIL PROTECTED] writes:
rm -rf a b
mkdir a
mv a b/
fails on Linux with coreutils-5.93:
mv: target `b/' is not a directory: No such file or directory
In previous releases (such as 5.2.1) it has worked. The rename() call
is also happy with the trailing slash.
Is this a
Jim Meyering [EMAIL PROTECTED] writes:
If someone (Paul :-) contributes a module that reads /dev/urandom
but reverts to rand-isaac.c-like code as a fall-back source, we can
always switch later.
Yes, thanks, that was the sort of thing I had in mind (no pun intended...).
But obviously it can
Eric Blake [EMAIL PROTECTED] writes:
I read that as rename() sees that a is a directory, so it resolves
b/ as b/. to ensure that b/ is not the pathname of a
non-directory (it isn't, since b/. does not exist), then can go
ahead
No, because POSIX requires that Write access permission is
Eric Blake [EMAIL PROTECTED] writes:
I maintain that Linux is still
POSIX-compliant by allowing rename(a, b/) to succeed
It does appear that POSIX does not specify what should happen when you
do this:
mkdir new
cd new
touch a
mv a b/c
That is, if b does not exist, then rename(a, b/c) is not
[EMAIL PROTECTED] (Eric Blake) writes:
You are looking at the pre-2004 defects; try looking at the current ones
http://www.opengroup.org/austin/aardvark/latest/xshbug2.txt
But ERN 108 in that URL refers to what happens with rename(a,
b/.), which obviously should fail. It doesn't really
Dominik Smogór [EMAIL PROTECTED] writes:
What is the problem with my system. Is my system badly misconfigured?
Could be. I don't observe similar behavior on my system
(Debian stable, Linux kernel 2.4.27-2-686).
# dd if=/dev/hda of=/dev/null bs=1M count=100 skip=600 iflag=direct
100+0 records
regular expressions -- an acceptable limitation, I think, for that old
platform.
In an attempt to fix this problem I installed the following patch in
both coreutils and gnulib.
2005-12-01 Paul Eggert [EMAIL PROTECTED]
* m4/regex.m4 (gl_REGEX): Check whether off_t can be used
I installed this into coreutils to keep things a bit more in sync:
2005-12-01 Paul Eggert [EMAIL PROTECTED]
Sync from gnulib.
* lib/exclude.c: Include verify.h.
(verify): Remove. All callers changed to use verify.h's version.
* lib/strtoimax.c: Likewise
Ken Nellis [EMAIL PROTECTED] writes:
I write to recommend a change to the rm command: When deleting the
files specified on the command line, when encountering one that
doesn't exist, after diagnosing the error, rm should immediately
terminate instead of the current procedure of continuing to
Serge Leschinsky [EMAIL PROTECTED] writes:
[EMAIL PROTECTED]:~ # set -x ; IPP=ipsec0=eth0 virt=`expr $IPP :
'\([^=].*\)=.*'` echo $virt ; set +x
+ IPP=ipsec0=eth0
++ expr ipsec0=eth0 : '\([^=].*\)=.*'
+ virt=
+ set +x
I don't observe this behavior on my host (Debian stable x86, coreutils
5.93,
]
and Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (sort invocation): Add -h or --hash-sort
and --seed, plus an example illustrating -h.
* src/Makefile.am (sort_LDADD): Add $(LIB_GETHRXTIME).
* src/shred.c: Include rand-isaac.c. Move the ISAAC code
Wu Jianglin [EMAIL PROTECTED] writes:
what i want is to override the existent symbol link java.
You might try the -T (--no-target-directory) option of GNU ln 5.3.0
or later.
it does work on others unix platform.
Which Unix platform was that? Solaris 10 'ln' behaves like GNU ln
here. For
Georg Schwarz [EMAIL PROTECTED] writes:
at least it seems to surpress if not solve the issue. The code now compiles.
OK, thanks, I'll work on a patch along those lines.
The other issue about grep (which is configure complaining about grep not
supporting -e) can be worked around by setting
[EMAIL PROTECTED] (Georg Schwarz) writes:
cfe: Error: ./stat-time.h, line 93: Type struct timestruc of returning
expression is incompatible with type struct timespec of function return
type
I installed the following to fix that bug, in both gnulib and coreutils.
2005-12-07 Paul Eggert
dd, at least, should have support for Linux's new O_NOATIME flag.
(Perhaps cp as well? but that's another story.)
I installed this:
2005-12-07 Paul Eggert [EMAIL PROTECTED]
* NEWS: Mention dd's new noatime flag.
* doc/coreutils.texi (dd invocation): New noatime flag
Georg Schwarz [EMAIL PROTECTED] writes:
CONFIG_SHELL=/bin/ksh /bin/ksh -x configure
That command works nicely; what does make trouble is
env CONFIG_SHELL=/bin/ksh /bin/sh -x configure
I wouldn't bother testing that. You should run configure with the
same shell that you set CONFIG_SHELL to.
Jim Meyering [EMAIL PROTECTED] writes:
I'm tempted to say O_NOATIME should be the default for rm -r, but
maybe not for cp, find, du, ls, etc.
Yes, that makes sense.
How about if we suggest instead that laptop owners mount their file
systems with the noatime option? That solves the problem in
How about if we suggest instead that laptop owners mount their file
systems with the noatime option? That solves the problem in general,
rather than forcing app writers to modify cat, ls, sh, etc.
It'd be ok if there were a noatime mount option that applied only to
directories.
That's the
The Wanderer [EMAIL PROTECTED] writes:
Hmm. Speaking of echo and its requirements, is there any way to have it
print '-n', '-e' or '-E' in an instance where they are not preceded on
the line by anything which is not a recognized option?
That's how coreutils echo already behaves, in the latest
The Wanderer [EMAIL PROTECTED] writes:
Paul Eggert wrote:
The Wanderer [EMAIL PROTECTED] writes:
Hmm. Speaking of echo and its requirements, is there any way to
have it print '-n', '-e' or '-E' in an instance where they are not
preceded on the line by anything which is not a recognized
Frederik Eaton [EMAIL PROTECTED] writes:
By the way, here is a patch corresponding to my current version of the
code.
Thanks, I installed that. I'll look into merging some of my proposed
changes later.
___
Bug-coreutils mailing list
I don't get the results you do; I get the results you expected.
Possibly it's a locale problem. What is the output of the locale
command?
sort --version tells me I'm operating coreutils 5.93, which is
probably newer than the version you're running.
After looking through the sort -R patch and noting the segfault it
caused on 64-bit systems
http://lists.gnu.org/archive/html/bug-coreutils/2005-12/msg00137.html
I thought I'd back off to a more-conservative approach for now.
2005-12-12 Paul Eggert [EMAIL PROTECTED]
* Version 6.0-cvs
what's going on
If we don't document this issue, I suspect we'll get email from
pedants every now and then saying we aren't really sorting at random,
so it is probably worth addressing it. Any volunteers?
2005-12-12 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (sort invocation
Frederik Eaton [EMAIL PROTECTED] writes:
Well, I guess it's only a factor of two, but there's a difference
between bugs that cause a segfault in a tool that many people use, and
bugs that might cause a new feature with 0 existing users to not be
100% cryptographically secure.
I'm sympathetic
I installed this to work around a buggy compiler that had _Bool but
its implementation of _Bool was quite broken.
2005-12-13 Paul Eggert [EMAIL PROTECTED]
* lib/stdbool_.h (_Bool): Resurrect the #if [EMAIL PROTECTED]@ check,
to
work around compilers that have a (possibly
801 - 900 of 3247 matches
Mail list logo
