Re: [Bug-tar] Error "Cannot allocate memory" incorrectly reported in some cases.

st that. > Similar issue exists in 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 err

Re: [Bug-tar] Error "Cannot allocate memory" incorrectly reported in some cases.

"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 b

Re: coreutils-5.92 - tests/cp/fail-perm fails when run as root

lly I 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 , so that large files can be opened.

Re: [Wishlist] dd: per-block skip data option

"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 b

Re: confusing error message from ln

[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 eit

Re: coreutils-5.92 - tests/cp/fail-perm fails when run as root

s shouldn't be able to look at /proc/self/fd. 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 (futimen

Re: Small patch for chdir-long.m4 and fpending.m4

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

Re: [PATCH] remove "dev=" mount option special processing for df

file or directory > df: `/mnt/memory-stick': No such file or directory > df: `/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, a

Re: confusing error message from ln

[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 B

Re: coreutils-5.92 - dd skip option completely broken

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)

Re: Unable to su root

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

Re: possible bug - output stream handling inconsistency in dd

Before proceeding too far in this matter can you please check the compatibility of your solution with the proposed action in XCU ERN 64? Please see and look for 'Enhancement Request Number 64'. Thanks.

Re: [Wishlist] dd: per-block skip data option

"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 bette

Re: possible bug - output stream handling inconsistency in dd

"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. _

Re: tail -c fails (coreutils 5.92)

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

Re: tail -c fails (coreutils 5.92)

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. T

POSIX-conformance patch for obsolete usages of "touch"

out this) I installed 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): T

Re: possible bug - output stream handling inconsistency in dd

"Theodoros V. Kalamatianos" <[EMAIL PROTECTED]> writes: > lseek is valid on e.g. /dev/hda and people > would not expect dd to null their data till it reached the desired > offset. True. I guess the algorithm should be to use lseek if possible, and to write nulls otherwise. Then ftruncate if pos

Re: coreutils 5.92, rm on Solaris, bad error message

[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()

Re: coreutils 5.92, rm on Solaris, bad error message

Jim Meyering <[EMAIL PROTECTED]> writes: > + /* Upon a failed attempt to unlink a directory, Solaris 9 sets > + errno to EPERM. One suggestion for the comment. The behavior in question (namely, unlink (dir) fails with errno==EPERM) is not just Solaris 9: it's required by POSIX. Linux

Re: coreutils-5.92 - dd skip option completely broken

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

Re: coreutils-5.92 - dd skip option completely broken

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. _

rm documentation contains obsolete references to --directory (-d)

quot;foo") depending on whether foo is a directory. 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 PR

Re: ln.c portability fix for hosts where / != //

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 E

Re: {base,dir}name // semantics

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 //

Re: better buffer size for copy

[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. ___

Re: tr is not working correctly with Turkish locale

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 http://

Re: better buffer size for copy

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 Lic

Re: making coreutils depend on c99

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 suppo

Re: tweaking default `ls -l` output to use locale before posix

"Dmitry V. Levin" <[EMAIL PROTECTED]> writes about : > 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 compatib

Re: possible bug - output stream handling inconsistency in dd

"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. ___

Re: tweaking default `ls -l` output to use locale before posix

Mike Frysinger <[EMAIL PROTECTED]> writes: > havent heard a peep yet about coreutils-5.3.0 since we last spoke ... so > either there are no problems or no one has noticed ;) OK, I've installed it in the trunk. (Maybe we'll get some peeps there)

Re: xstrtoimax compilation warning on Solaris 7

[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 st

Re: Usage of Fmt

"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

Re: Usage of Fmt

"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

Re: tail +16c syntax

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

Re: Bug Report for seq version 5.2.1

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 sou

Re: test failures building 5.93 and hpux compiler patch

"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 abo

Re: confusing error message from ln

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 diagn

Re: tail "-f" option fails two ways in version 5.93

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.~ 2

Re: Bug report: sort.c or AIX compiler

"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

Re: CVS automake vs. coreutils head

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 AC_PR

Re: O_DIRECT support in dd

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

Re: dd does not handle input from pipes correctly (coreutils-5.93)

Paul Mielke <[EMAIL PROTECTED]> writes: > The problem is this: if input is from stdin and stdin is a pipe, the > routine dd_copy assumes that a short read returned from "iread" > means that it has read a partial record. I think that's what dd is supposed to do. See, for example,

Re: CVS automake vs. coreutils head

Eric Blake <[EMAIL PROTECTED]> writes: > Yes - the important point is that AM_PROG_CC_C_O appear anywhere after > AC_PROG_CC. OK, thanks. I installed the following patch. Somehow the copyright dates got messed up in configure.ac so I fixed them too. 2005-11-18 Paul Eggert <[

Re: O_DIRECT support in dd

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 th

Re: Bug report: sort.c or AIX compiler

der versions of IBM's compilers.) I assume 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 compile

Re: FW: PMR 52061,370,000

"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 th

Re: Bug in md5sum (5.3.0) when checking lists of files?

[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 s

Re: od command

"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

remove.c patch needed to compile CVS cor3eutils with GCC 4.0.2

in pre-C99 compilers, 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.

Re: bugs in dirname module - coreutils portion

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 a

Re: better buffer size for copy

shandles sparse files among other 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 bl

Re: test failures building 5.93 and hpux compiler patch

0086.html>. I installed this patch into coreutils 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 mor

renamed ulonglong_t to unsigned_long_long_int in od.c

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 POSI

Re: [PATCH] remove "dev=" mount option special processing for df

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 . (dev_from_mount_options) [defined MOUNTED_GETMNTENT1 || defined MOUNTED_GETMNTENT2]:

Re: df reports bind mounts creating noisy output

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:

Re: sort --random-sort

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 /dev/

Re: "mv a b/" when b does not exist

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. > > I

Re: sort --random-sort

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 ca

Re: sort --random-sort

ThMO <[EMAIL PROTECTED]> writes: > /dev/urandom does *not* provide high quality pseudo-random numbers, Yes, and thanks for your comments, but the existing substitute doesn't provide them either, so from the point of view of randomness quality it wouldn't be a loss to use /dev/urandom if available

Re: "mv a b/" when b does not exist

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 permis

Re: "mv a b/" when b does not exist

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", "

Re: "mv a b/" when b does not exist

Eric Blake <[EMAIL PROTECTED]> writes: > According to Paul Eggert on 11/30/2005 10:57 AM: >> mkdir new >> cd new >> touch a >> mv a b/c >> >> That is, if "b" does not exist, then rename("a", "b/c") is not >> requir

Re: "mv a b/" when b does not exist

[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 a

Re: oflag=direct speed boost

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 record

Re: test failures building 5.93 and hpux compiler patch

use programs to mishandle strings larger than 2 GiB when processing 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]>

import some lib and m4 changes from gnulib

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.

Re: rm issue

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 continu

Re: possible bug in "expr" core utils 5.93

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

Re: sort --random-sort

ions. I'm still a bit puzzled about the part marked (*) above, though. 2005-12-03 Frederik Eaton <[EMAIL PROTECTED]> and Paul Eggert <[EMAIL PROTECTED]> * doc/coreutils.texi (sort invocation): Add -h or --hash-sort and --seed, plus an example illustrating -

Re: ln bug report

"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. F

Re: coreutils 5.93 on IRIX 5.3

[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 >return ((st)-> st_atim) ; Does the following patch to lib/stat-time.h fix things for you? It'

Re: Possible dd bug - no close of "if=/of=" fds

"HARDY, Steven" <[EMAIL PROTECTED]> writes: > I was expecting dd to explicitly close the if=/of= file descriptors It should do that. dd.c's main program invokes "atexit (close_stdout);", and this should invoke close_stdout (which reports an error) if the close fails. What is the output of the f

Re: coreutils 5.93 on IRIX 5.3

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 settin

Re: coreutils 5.93 on IRIX 5.3

[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 Pa

add dd support for O_NOATIME

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 invocati

Re: coreutils 5.93 on IRIX 5.3

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_

Re: add dd support for O_NOATIME

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

Re: add dd support for O_NOATIME

>> 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. Tha

Re: bug with 'test'

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 la

Re: bug with 'test'

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' i

Re: sort --random-sort

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 Bug-coreuti

Re: Problem with Linux sort

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. _

sort -R: a more-conservative approach

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]>

coreutils doc improvements for sort -R

least not if we don't document 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

Re: sort -R: a more-conservative approach

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 sympat

more stdbool portability fixes for coreutils

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

lib/Makefile.am change needed for recent stdbool.h fix

Whoops. This change is needed to go along with the previous change, for hosts that lack a working stdbool.h. I installed this on the head; the b5_9x branch doesn't need it. 2005-12-13 Paul Eggert <[EMAIL PROTECTED]> * Makefile.am (stdbool.h): Resurrect the 'sed&

HAVE__BOOL reversion for coreutils main branch

One more stdbool-related change. I hope this is the last one needed on the trunk for a while. It reverts to a previous version where HAVE__BOOL is concerned. 2005-12-13 Paul Eggert <[EMAIL PROTECTED]> * stdbool.m4 (AM_STDBOOL_H): Substitute HAVE__BOOL again, reverting 2

'cat' doesn't check close(STDOUT_FILENO)'s return value

On some operating systems, notices of output errors are sometimes delayed until you close the file. However, in the normal case coreutils 'cat' doesn't check the return value from 'close(STDOUT_FILENO)'. I installed this patch. 2005-12-13 Paul Eggert <[EMAIL PROT

change 'sort' to report error with "sort -R -i", etc.

sn't 100% clear about what to do with the particular combination "sort -i -n". I've filed a bug report about the "sort -i -n" issue with the Open Group; see <https://www.opengroup.org/sophocles/show_mail.tpl?source=L&listname=austin-review-l&id=1983>.

Re: [patch #3596] Sort directories before files in "ls"

Francesco Montorsi <[EMAIL PROTECTED]> writes: > could anyone have a look at this patch ? A lot of patches have been proposed; sorry, I've lost track of them. Which one in particular were you worried about? ___ Bug-coreutils mailing list Bug-coreu

Re: reverting `stat --format=FMT'

Jim Meyering <[EMAIL PROTECTED]> writes: > As planned, here's the change to revert stat --format=FMT to > its previous behavior. Note that with this change, backslash > escapes in a --format-specified format string are *not* interpreted. Looks good. A couple of minor comments. Unless I read th

tests/acl fixes for Solaris 8

"make check" failed on Solaris 8 because its shell didn't grok the syntax used in tests/acl. Also, I noticed it assumed /etc/passwd exists and contains all the user names, which isn't true for (e.g., NIS-based systems). I installed this: 2005-12-15 Paul Egger

Re: suggested feature/patch for ls: -P TYPES, --select-file-type=TYPES

I don't recall the earlier thread, but my kneejerk reaction is that this sort of thing can be done fairly easily with commands like "ls -l | grep '^d'". No doubt I'm missing something... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists

Re: Not finding sha256sum

Thanks for reporting that. The documentation is in error; it mistakenly describes a coreutils feature that isn't in the stable version yet. I installed the following patch on the b5_9x branch, and it should propagate to the web site after the next stable version is out. 2005-12-16 Paul E

Re: on "dd" using "seek" vs. "read" & >32-bit sizes

Linda Walsh <[EMAIL PROTECTED]> writes: > I can specify the "seek=BLOCKS" param, but it appears that "dd" doesn't > translate this to a "seek" command but instead uses "read" to to > sequentially access the block device. Is this the case or am I > hallucinating? Normally it uses lseek: $ dd

proposed tweaks for openat in coreutils

re_failed; - } + status = remove_dir (fd_cwd, ds, filename, x, cwd_errno); I can't figure out why the old code had that local boolean variable, rather than just passing cwd_restore_failed to remove_dir. Perhaps this was to help with debugging with GDB? 2005-12-16 Paul Eggert <

Re: suggested feature/patch for ls: -P TYPES, --select-file-type=TYPES

Moreno Baricevic <[EMAIL PROTECTED]> writes: > My point is that on a populated directory (e.g. /dev on 2.4), filtering > file types inside ls is faster than doing it externally by parsing a > huge output. How much faster? For example, what is the performance of your modified version of ls with t

<    4   5   6   7   8   9   10   11   12   13   >