Re: RFC: do you use du --bytes (-b) [Re: 'du -b' bug in fileutils-4.1
David Eisner [EMAIL PROTECTED] writes: I was using du to get a sense of whether an rsync operation between two hosts was successful. I don't see how that can work in general, even if we make the changes suggested, since in general directory sizes won't be the same on different machines. Directory sizes are not under direct user program control. They might even be zero (and are, on some platforms, if memory serves). Perhaps if we changed 'du' to ignore directory sizes; but this is sounding more and more like a special case just for you. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: configure test working C stack overflow detection seems to loop
Gerard Beekmans [EMAIL PROTECTED] writes: I tried out the new 4.5.8 release and it doesn't exhibit the same symptoms. It runs the check and determines that I don't have a working C stack overflow, but without using up all the RAM. Is this normal for a Linux system? Yes, it's expected for coreutils 4.5.8, since it has a workaround for the problem. However, it's not clear to me that 4.5.8 is doing the right thing in general, since apparently some Linux kernels have extremely poor C stack overflow detection by default -- which is why the 4.5.7 test thrashed some people's systems -- and I suspect (without having the time to check this) that a similar problem might occur with coreutils when given weird test cases. I plan to look into this in more detail soon. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils uniq -d -u does not conform to POSIX
[EMAIL PROTECTED] writes:
But -u -d is clearly valid, since POSIX says it's valid.
have you a link to the POSIX docs?
http://www.opengroup.org/onlinepubs/007904975/utilities/uniq.html
In order to understand that page fully, you need to read a lot of the
other part of the spec. But for this particular issue the page is
pretty self-explanatory.
-u Discard the first repeated line.
This isn't as clear to me as only print unique lines
Perhaps not, but only print unique lines isn't correct.
Under this convention, -D is not incompatible with -d or with -u.
agreed, but redundant = should warn user as I summarised above
I don't see why a warning would be useful. GNU utilities often accept
redundant options without complaint.
All this is too complicated. IMHO uniq should just have
--group={min,max,num_to_show,delimter}
That's simpler? I dunno
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Fw: Redirection wildcarding under VMS
Bernard Giroud [EMAIL PROTECTED] writes: Index: configure.ac Wouldn't it be simpler to put this: #ifndef initialize_main # define initialize_main(argcp, argvp) #endif into system.h rather than modifying configure.ac? That is how diffutils does it. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Would like a way to silent ln warning: making a hard link to asymbolic link is not portable
[EMAIL PROTECTED] writes: I have found a linux-specific use for this in my boot scripts, and would like to be able to see other errors from ln without cluttering up the boot process with this one. How about if we just remove the warning instead? It annoys me too. I often use hard links to symlinks. (I know they're not portable, so I don't need a warning. :-) Solaris 'ln' doesn't warn in this case, and I think it's reasonable not to warn by default. There are lots of nonportable things in the GNU core utilities, so why warn about this usage in particular? ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: test -t FD vs. [FD]
Dan Jacobson [EMAIL PROTECTED] writes: $ man test -t [FD] file descriptor FD (stdout by default) is opened on a terminal I.e. argument optional $ help test -t FD True if FD is opened on a terminal. Not so optional with bash then. You guys should unify them. POSIX long ago decided that FD is not optional with test -t. GNU 'test' conforms to POSIX in this respect. This means GNU 'test' is incompatible with ancient Unix 'test', but that's life in the big city. The original specification had an ambiguous grammar, and POSIX removed the ambiguity by making FD required. Reference: http://www.opengroup.org/onlinepubs/007904975/utilities/test.html ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: test -t FD vs. [FD]
[EMAIL PROTECTED] (Paul Jarc) writes:
Paul Eggert [EMAIL PROTECTED] wrote:
POSIX long ago decided that FD is not optional with test -t. GNU
'test' conforms to POSIX in this respect.
bash's does, but coreutils' doesn't.
Good point. I looked at coreutils/src/test.c and noticed some other
incompatibilities with POSIX and with the GNU coding standards. Here
is a patch to fix them. Even with this patch, coreutils test
disagrees with Bash test on some cases but that is a subject for a
different email.
2003-06-30 Paul Eggert [EMAIL PROTECTED]
Add support for a [ that conforms to the GNU coding standards,
i.e., that does not depend on its name.
* src/lbracket.c: New file.
* README: Add [.
* man/Makefile.am (programs): Ignore [, since it doesn't have
a separate man page.
* src/Makefile.am (bin_PROGRAMS): Add [.
(__SOURCES): New var.
* src/test.c (LBRACKET): Define to 0 if not defined.
(main): Use LBRACKET rather than argv[0].
* src/test.c (one_argument): Do not check for -t if POSIXLY_CORRECT.
* src/test.c (main): Do not recognize --help or --version if
POSIXLY_CORRECT, when invoked as test. Handle [ ] correctly.
Do not bother testing that margv[margc] is non-null.
--- /dev/null Tue Mar 18 13:55:57 2003
+++ src/lbracket.c Mon Jun 30 16:08:27 2003
@@ -0,0 +1,2 @@
+#define LBRACKET 1
+#include test.c
Index: README
===
RCS file: /cvsroot/coreutils/coreutils/README,v
retrieving revision 1.9
diff -p -u -r1.9 README
--- README 16 Jun 2003 10:51:29 - 1.9
+++ README 1 Jul 2003 03:37:22 -
@@ -7,7 +7,7 @@ arbitrary limits.
The programs that can be built with this package are:
- basename cat chgrp chmod chown chroot cksum comm cp csplit cut date dd
+ [ basename cat chgrp chmod chown chroot cksum comm cp csplit cut date dd
df dir dircolors dirname du echo env expand expr factor false fmt fold
ginstall groups head hostid hostname id join kill link ln logname ls
md5sum mkdir mkfifo mknod mv nice nl nohup od paste pathchk pinky pr
Index: man/Makefile.am
===
RCS file: /cvsroot/coreutils/coreutils/man/Makefile.am,v
retrieving revision 1.16
diff -p -u -r1.16 Makefile.am
--- man/Makefile.am 4 Jun 2003 12:22:06 - 1.16
+++ man/Makefile.am 1 Jul 2003 03:37:22 -
@@ -148,7 +148,7 @@ check-x-vs-1:
programs = \
echo 'spy:;@echo $$(all_programs)' \
| MAKEFLAGS= $(MAKE) -s -C $(srcdir)/../src -f Makefile -f - spy \
-| fmt -1 | sort -u
+| fmt -1 | sort -u | grep -v '\['
.PHONY: check-programs-vs-x
check-programs-vs-x:
Index: src/Makefile.am
===
RCS file: /cvsroot/coreutils/coreutils/src/Makefile.am,v
retrieving revision 1.24
diff -p -u -r1.24 Makefile.am
--- src/Makefile.am 10 Apr 2003 19:11:07 - 1.24
+++ src/Makefile.am 1 Jul 2003 03:41:59 -
@@ -4,7 +4,7 @@ EXTRA_PROGRAMS = chroot df hostid nice p
EXTRA_SCRIPTS = nohup
bin_SCRIPTS = groups $(OPTIONAL_BIN_ZCRIPTS)
-bin_PROGRAMS = chgrp chown chmod cp dd dircolors du \
+bin_PROGRAMS = [ chgrp chown chmod cp dd dircolors du \
ginstall link ln dir vdir ls mkdir \
mkfifo mknod mv readlink rm rmdir shred stat sync touch unlink \
cat cksum comm csplit cut expand fmt fold head join md5sum \
@@ -129,6 +129,9 @@ uninstall-local:
transform = s/ginstall/install/; @program_transform_name@
ginstall_SOURCES = install.c copy.c cp-hash.c
+
+# This is for the '[' program. Automake transliterates '[' to '_'.
+__SOURCES = lbracket.c
cp_SOURCES = cp.c copy.c cp-hash.c
dir_SOURCES = ls.c ls-dir.c
Index: src/test.c
===
RCS file: /cvsroot/coreutils/coreutils/src/test.c,v
retrieving revision 1.86
diff -p -u -r1.86 test.c
--- src/test.c 17 Jun 2003 18:13:24 - 1.86
+++ src/test.c 1 Jul 2003 03:42:03 -
@@ -32,6 +32,10 @@
#define TEST_STANDALONE 1
+#ifndef LBRACKET
+# define LBRACKET 0
+#endif
+
#include system.h
#include error.h
#include euidaccess.h
@@ -859,7 +863,7 @@ unop (int op)
static int
one_argument (const char *s)
{
- if (STREQ (s, -t))
+ if (! getenv (POSIXLY_CORRECT) STREQ (s, -t))
return (TRUE == (isatty (1)));
return strlen (s) != 0;
@@ -1082,32 +1086,26 @@ main (int margc, char **margv)
atexit (close_stdout);
#endif /* TEST_STANDALONE */
- argv = margv;
+ /* Recognize --help or --version unless POSIXLY_CORRECT is set. */
+ if (! getenv (POSIXLY_CORRECT))
+parse_long_options (margc, margv, PROGRAM_NAME, GNU_PACKAGE, VERSION,
+ AUTHORS, usage);
- if (margv[0] strcmp (margv[0], [) == 0)
+ if (LBRACKET
Re: [patch] Add numerical suffixes to split
Jim Meyering [EMAIL PROTECTED] writes: However, if you can find a few other people who say they'd like that functionality and make a good case for it, I'll reconsider. If you go that route, I'd suggest adding an option --suffix-alphabet=STRING, so that the user can specify an arbitrary alphabet to use when generating the suffix. The default STRING would be abcdefghijklmnopqrstuvwxyz, as now. The current split.c is not portable to EBCDIC hosts, since it assumes that 'a' + 1 == 'b', 'b' + 1 == 'c', etc., and this is not true of EBCDIC hosts. Adding support for --suffix-alphabet should fix this bug as a side effect. One complication would be multibyte characters in STRING, though. Also, a question for Jesse: would csplit work for your particular application? It can generate numeric suffixes already. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: subtle sort bug?
gregory mott [EMAIL PROTECTED] writes: for example, en_IN repeatably produces proper results, but en_AU repeatably fails to handle some special characters properly. I reproduced your results on my host (Debian GNU/Linux 3.0r1). However, on my host what you were doing was a user error, as en_IN uses UTF-8 encoding but en_AU uses ISO-8859-1, and those two encodings are incompatible. Your email used UTF-8, so most likely your /tmp/sos file was UTF-8 (as was mine). One can't reliably sort a UTF-8 file using an ISO-8859-1 locale, so it wouldn't be surprising that an en_AU sort misfired. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: df fooled by multitrack CDROM
Dan Jacobson [EMAIL PROTECTED] writes: The du and df commands give differing results. Perhaps df can't see into multitrack CDROMs. df just reports what the underlying system call tells it (statfs on GNU/Linux), so most likely the problem is not in coreutils. Possibly there are multiple mounts; if so, plain df should show multiple filesystems mounted under /cdrom. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: subtle sort bug?
gregory mott [EMAIL PROTECTED] writes: can you point me to an appropriate RTFM that ideally would layout what encodings are used by what locales, or how to tell what encoding you have/need, etc usw? Sorry, no; this stuff tends to be scattered around all over the place. On my Debian GNU/Linux 3.0r1 system, the file /usr/share/i18n/SUPPORTED lists the encodings used by locales, but things may be different on your system. For general info about encodings you might try www.li18nux.org and/or Ken Lunde's book on encodings and character sets http://www.praxagora.com/lunde/cjkv-ip.html. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: subtle sort bug?
gregory mott [EMAIL PROTECTED] writes: when i pass textual input to sort, how does sort come to decide or infer the encoding? From the locale. It looks at the LC_ALL environment variable; if that isn't set it looks at LC_CTYPE; if that isn't set it looks at LANG; otherwise the default locale is system-dependent. you seem to say that a locale is associated with a particular encoding. Yes. on rh9, the locale definitions (eg /usr/share/i18n/locales/en_IN) appear to be in unicode. Some are UTF-8; some undoubtedly aren't. can you/anyone give me a clue? You might try reading the GNU C library manual on locales. http://www.gnu.org/manual/glibc-2.2.5/html_node/Locales.html Sorry, I don't use Red Hat, so you'll need to consult a Red Hat expert for details specific to your system. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in expand command.
That doesn't look like a bug to me. For example, the first line of hints.txt contains 1 . SPACE TAB T so there are three columns before the tab, which means that expand -t1 and expand -t2 should behave the same. Perhaps you didn't notice the SPACE? ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Adding numerical suffixes to split
Jesse Kornblum [EMAIL PROTECTED] writes: 2. The files we are working with will become evidence to be used in criminal proscecutions. If I were a criminal defense lawyer attacking your use of 'split' on technical grounds, I'd ask why you require a particular implementation of 'split' with nonstandard extensions. I'd have a harder time attacking your methods if they could be executed on any implementation of 'split' conforming to the standard specification for 'split' http://www.opengroup.org/onlinepubs/007904975/utilities/split.html (this is ISO/IEC 9945:2002, a formal international standard). If your procedures stick to the formal standard, anybody can check your work by running your procedures on any standard implementation (Solaris or Tru64, say). This would provide an extra check that the prosecution isn't incorrectly relying on some bug in the coreutils implementation of 'split'. The more commands that need to be executed, the greater the possibility that a mistake will be made True, but the number of commands that you'd have to put into a script ought to be significantly less than the number of lines of code in 'split' that you'd have to change. Also, you ought to have a script anyway -- since 'split' alone doesn't solve your problem, and since your users are not experts -- so it shouldn't be a major objection that you use a script. Given that the functionality for numerical suffixies already exists in csplit, why can't that be added to regular split? Wouldn't this be a trivial operation? This issue is really up to the coreutils maintainer, but if you supply a high-quality patch with a ChangeLog entry, I think you'll have a better chance of it getting accepted. Please see http://mail.gnu.org/archive/html/bug-coreutils/2003-07/msg0.html for an example of what a patch should look like. Also, I suggest that you ponder the suggestions and comments in http://mail.gnu.org/archive/html/bug-coreutils/2003-07/msg1.html. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in expand command.
[EMAIL PROTECTED] writes: Yes, I knew that the space was actually there. If you use the very first line of hints.txt file, as if you had a column ruleguide, you may notice that the output (expand- bug.txt) never show the start of the sentence below the first five of the ruleguide. Sorry, I don't follow. http://mail.gnu.org/archive/html/bug-coreutils/2003-07/msg00012.html contains this: [EMAIL PROTECTED] tmp]# expand -t1 hints.txt | cut -b1-9 012345678 1. To co 2. The M 3. After 4. The s 5. To re 6. Refer and this shows the start of the 6th sentence. expand -t2 also shows the start of the 6th sentence. So I still don't see the bug. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: df and multiple-mounted mountpoints
Tim Waugh [EMAIL PROTECTED] writes: With Linux it is possible to have a single mountpoint mounted several times; the last mounted fs is the one whose stats are visible, and they are stacked. What should df do in this case? Currently it shows the stats for the last mounted fs for each fs mounted on the mount point, which is misleading. Why is it misleading? I don't understand the situation, but from what you write only the last mounted fs is visible, i.e., is accessible to any application. Perhaps you could give an example of why it's misleading? ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: inconsistent uname -s option
Robert Millan [EMAIL PROTECTED] writes:
- Make the --help output dependant on the platform, and only say -s
is for the kernel when running uname on GNU/Linux.
I don't see why this proposed change is needed. The other kernels
that you mention are commonly called the OpenBSD kernel, the
FreeBSD kernel, etc. It's not misleading for uname -s to output
OpenBSD on an OpenBSD system.
On many systems, it happens to be that the kernel name is the same as
the operating system name, but this doesn't mean we should confuse the
two notions on all systems.
- POSIX says -s should:
Write the name of the implementation of the operating system.
And GNU uname does as POSIX requires. GNU uname's help string
identifies the implementation of the operating system with the
kernel. This is reasonable. POSIX itself has no notion of kernel,
so it can't talk about the kernel in its specification. But the GNU
help string does not need to be so pedantic.
It might be helpful to document this issue better in the coreutils
manual, to help forestall user confusion in the future. I notice a
similar discrepancy with uname -m. Here's a proposed patch.
2003-07-14 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (uname invocation): Explain the POSIX
terminology behind uname -m and uname -s.
--- coreutils.texi.~1.119.~ Mon Jul 14 14:02:30 2003
+++ coreutils.texi Mon Jul 14 14:48:01 2003
@@ -10972,7 +10972,8 @@ Print the hardware platform name
@cindex machine type
@cindex hardware class
@cindex hardware type
-Print the machine hardware name (sometimes called the hardware class).
+Print the machine hardware name (sometimes called the hardware class
+or hardware type).
@item -n
@itemx --nodename
@@ -11013,6 +11014,14 @@ Print the kernel release.
@cindex kernel name
@cindex name of kernel
Print the kernel name.
[EMAIL PROTECTED] 1003.1-2001 (@pxref{Standards conformance}) calls this
+``the implementation of the operating system'', because the
[EMAIL PROTECTED] specification itself has no notion of ``kernel''.
+The kernel name might be the same as the operating system name printed
+by the @option{-o} or @option{--operating-system} option, but it might
+differ. Some operating systems (e.g., FreeBSD, HP-UX) have the same
+name as their underlying kernels; others (e.g., GNU/Linux, Solaris)
+do not.
@item -v
@itemx --kernel-version
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: textutils version 2.1 bug
Parimi, Venkateshwara Rao [EMAIL PROTECTED] writes: On a solaris 2.6 machine configure dieing with segmentation fault. This appears to be a bug in your shell. I can't reproduce the bug in the following environment: coreutils 5.0 (This is the latest version of textutils.) ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.0.tar.gz Solaris 2.6, with the following patches (as of 2003-07-10): ftp://sunsolve.sun.com/pub/patches/2.6_Recommended.tar.Z GCC 3.2.3 You write Config is getting /bin/sh but do not know why make does use ksh, am still under confusion. The 'configure' script should not get /bin/sh on that platform. It should set CONFIG_SHELL to /bin/ksh (or to Bash, if you have installed that yourself). I'd like to know why configure gets /bin/sh; can you experiment by running sh -x configure? Also, which sh and ksh are you using? Here's what I get on my Solaris 2.6 system. If your shells are older, perhaps you need to install the free Sun patches for them. 67-dew $ type sh sh is /usr/bin/sh 68-dew $ type ksh ksh is /usr/bin/ksh 69-dew $ ls -l /usr/bin/sh /usr/bin/ksh -r-xr-xr-x 2 bin bin 186528 Jan 7 2003 /usr/bin/ksh -r-xr-xr-x 3 bin root 89028 Dec 18 2002 /usr/bin/sh 70-dew $ /usr/bin/sum /usr/bin/sh /usr/bin/ksh 18780 174 /usr/bin/sh 8794 365 /usr/bin/ksh From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 10:55 AM On my system it still generates the ((( that you are seeing as a problem with your ksh. But it is still best to keep on the later versions if possible. And hopefully it will detect and use /bin/sh instead, assuming that is a POSIX shell on your system. It's not. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: [Coreutils-announce] coreutils-5.0.1 released
Jim Meyering [EMAIL PROTECTED] writes: Is NEWS-OS 4.2R something you care about? Make variables Do people still use that OS? Sony NEWS-OS 4.2R was released in 1992, so I highly doubt it. However, NEWS-OS 4.2.1a+ (released 1995) is probably still in use by a diehard or two, since it was Sony's last BSD release and some people didn't want to switch to SVR4.2 when Sony did. I don't know whether it had that bug. I seem to remember that NEWS-OS (Sony?) was nearly nonexistent 8 or 10 years ago. The last Sony NEWS-OS release was 6.1.2, in 1996. The last unofficial patch from Sony is dated May 2000. Some people in Japan still run NEWS-OS, though I think it's more of a hobbyist-with-used-equipment crowd now. They were also responsible for my writing some horrible hack wrt EXIT_FAILURE or EXIT_SUCCESS. On that system (maybe not the same release), one of those was defined to the wrong value! Sorry about that. I was the one who sent you that bug report, lo these many years ago. I had a NEWS-OS box on my desk around 1990, running Sony NEWS-OS 4.0C. It defined EXIT_FAILURE to 0. But that bug is long dead. I wouldn't bother with worrying about leading-underscore names, unless someone real (i.e. not in a computer museum) reports a bug. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Coreutils 5.0.1: spurious error from uniq
Andreas Schwab [EMAIL PROTECTED] writes: LC_CTYPE=de_DE.UTF-8 LC_TIME=POSIX LC_COLLATE=POSIX This is fine-tuned to DTRT(tm) for my needs. Maybe the LC_CTYPE and/or LC_COLLATE settings are confusing glibc. I'll check that, and see if setting them to en_US.UTF-8 helps. POSIX says: If different character sets are used by the locale categories, the results achieved by an application utilizing these categories are undefined. http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap07.html So you're not allowed to mix LC_COLLATE=POSIX with LC_CTYPE=de_DE.UTF-8, and the results are undefined if you do. Similarly for LC_TIME. Also, perhaps the locale command should warn if it discovers incompatible character sets in the various locale categories. Do you have a POSIX.UTF-8 locale? That should fix your problem too. Anyway, it's still possible that 'uniq' has a bug, or perhaps 'strcoll', depending on your further investigation. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: [wish] sort : what about randomization ?
It'd be an amusing option to build, albeit not as easy as one might think at first glance. Here's a proposed addition to the coreutils TODO list. Or perhaps we should have a different program (unsort? assort?) instead. --- ../coreutils/TODO Mon Jul 14 11:39:37 2003 +++ TODOThu Jul 17 15:42:57 2003 @@ -86,3 +86,13 @@ sort: Compress temporary files when doin This improves performance when you can compress/uncompress faster than you can read/write, which is common in these days of fast CPUs. suggestion from Charles Randall on 2001-08-10 + +sort: Add an ordering option -R that causes 'sort' to sort according + to a random permutation of the correct sort order. Also, add an + option --random-seed=SEED that causes 'sort' to use an arbitrary + string SEED to select which permutations to use, in a deterministic + manner: that is, if you sort a permutation of the same input file + with the same --random-seed=SEED option twice, you'll get the same + output. The default SEED is chosen at random, and contains enough + information to ensure that the output permutation is random. + suggestion from Feth AREZKI, Stephan Kasal, and Paul Eggert on 2003-07-17 ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: textutils version 2.1 bug
Parimi, Venkateshwara Rao [EMAIL PROTECTED] writes: With the same shells it works fine on another machine with Solaris 2.6. What is the difference between the two machines? That would be one way to track down the problem. I still suggest that you install the Sun-recommended patches in ftp://sunsolve.sun.com/pub/patches/2.6_Recommended.tar.Z. It will save your time and ours. What I want to know is, what would be the next check done by the configure script that causing Segmentation fault. You should be able to find that out by running ksh -x ./configure instead of plain ./configure. 1) src/wheel-gen.pl has #!/usr/bin/perl hard-coded(I have perl in /usr/local/bin). Can this be auto detected? It could, but does it fix things to replace #!/usr/bin/perl -w with #!/usr/bin/env perl? I don't know what the -w does; can that be done inside the perl script instead? 2) Basic test of du fails because of the test file is written with less bytes than required (64 bytes). I vaguely recall that this is fixed in coreutils 5.0.1; can you try that? ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.0.1.tar.gz b) fail-2eperm of rm fails because of the error string expected is different From the actual error string returned parimiv diff fail-2eperm fail-2eperm.fixed 46c46 rm: cannot remove `a/b': Operation not permitted --- rm: cannot remove `a/b': Not owner This test-case bug still remains in 5.0.1, I think. But it's not a bug in rm, as far as I can see. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Coreutils 5.0.1: spurious error from uniq
Andreas Schwab [EMAIL PROTECTED] writes: 2003-07-18 Andreas Schwab [EMAIL PROTECTED] * memcoll.c (memcoll) [!HAVE_STRCOLL]: Clear errno. --- coreutils-5.0.1/lib/memcoll.c.~1~ 2003-06-06 22:11:58.0 +0200 +++ coreutils-5.0.1/lib/memcoll.c 2003-07-18 11:58:37.0 +0200 @@ -83,6 +83,7 @@ memcoll (char *s1, size_t s1len, char *s diff = memcmp (s1, s2, s1len s2len ? s1len : s2len); if (! diff) diff = s1len s2len ? -1 : s1len != s2len; + errno = 0; #endif Thanks for that fix. I checked it into gnulib. (Wow, your memcmp implementation sets errno? It's allowed to, but out of curiosity why does it do that?) The other part of your coreutils fix is probably better served by migrating gnulib's m4 stuff into coreutils; I'll address that in a different message. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Coreutils 5.0.1: spurious error from uniq
Andreas Schwab [EMAIL PROTECTED] writes: 2003-07-18 Andreas Schwab [EMAIL PROTECTED] * jm-macros.m4 (jm_MACROS): Check for strcoll. For this part of your patch I think it'd be better to use the gnulib module for memcoll. Something like this, and also copy m4/memcoll.m4 from gnulib. 2003-07-18 Paul Eggert [EMAIL PROTECTED] * jm-macros.m4 (jm_MACROS): Invoke gl_MEMCOLL. * memcoll.m4: New file, from gnulib. Index: m4/jm-macros.m4 === RCS file: /cvsroot/coreutils/coreutils/m4/jm-macros.m4,v retrieving revision 1.171 diff -p -u -r1.171 jm-macros.m4 --- m4/jm-macros.m4 12 Jul 2003 18:47:29 - 1.171 +++ m4/jm-macros.m4 18 Jul 2003 18:15:40 - @@ -66,6 +66,7 @@ AC_DEFUN([jm_MACROS], AC_REQUIRE([AC_FUNC_STRERROR_R]) AC_REQUIRE([jm_FUNC_NANOSLEEP]) AC_REQUIRE([jm_FUNC_MEMCMP]) + AC_REQUIRE([gl_MEMCOLL]) AC_REQUIRE([jm_FUNC_GLIBC_UNLOCKED_IO]) AC_REQUIRE([AC_FUNC_FNMATCH_GNU]) AC_REQUIRE([jm_FUNC_GROUP_MEMBER]) ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: wc annoyances
Daniel Russell [EMAIL PROTECTED] writes:
[ `cat autolist-next.num` -gt `wc -l autolist.txt` ]
That's easy enough to fix by using `wc -l autolist.txt` instead.
However, I agree with you that the leading spaces are annoying; this
has bitten me as well, in other examples. I looked into this, and it
turns out that the coreutils documentation is incorrect about what
POSIX requires for 'wc'. When this misunderstanding is corrected, 'wc
-l autolist.txt' can output no leading spaces. While I was at it, I
fixed another problem: wc's columns sometimes don't line up for files
bigger than 9,999,999 bytes. The fix handles only the case of regular
files, but that's an important case.
This patch fixes a couple of other minor related bugs that I noticed
while implementing this change: there was a confusion between and NULL,
and a possible arithmetic overflow.
2003-07-20 Paul Eggert [EMAIL PROTECTED]
wc count field widths now are heuristically adjusted depending
on the input size, if known. If only one count is printed, it
is guaranteed to be printed without leading spaces.
Previously, wc did not align the count fields if
POSIXLY_CORRECT was set, but POSIX did not actually require
this undesirable behavior, so it has been removed.
* NEWS: Document this.
* doc/coreutils.texi (wc invocation): Likewise.
* src/wc.c (number_width): New var.
(posixly_correct): Remove.
(struct fstatus): New struct.
(write_counts): Output fields of width number_width.
Do not worry about POSIXLY_CORRECT.
Use null file, not empty-string file, to denote stdin,
since is a valid file name on some hosts.
(wc, wc_file): New arg fstatus. Use it to avoid invoking fstat
if possible.
(wc): Avoid problems if end_pos - current_pos overflows.
Do not print odd message if stdin has a read error.
(get_input_fstatus, compute_number_width): New functions.
(main): Use them to implement the new behavior.
Ignore POSIXLY_CORRECT.
* tests/wc/Test.pm: Adjust to the new output widths.
Index: NEWS
===
RCS file: /cvsroot/coreutils/coreutils/NEWS,v
retrieving revision 1.112
diff -p -u -r1.112 NEWS
--- NEWS18 Jul 2003 08:53:32 - 1.112
+++ NEWS20 Jul 2003 07:33:23 -
@@ -1,4 +1,14 @@
GNU coreutils NEWS-*- outline -*-
+
+* wc count field widths now are heuristically adjusted depending on the input
+ size, if known. If only one count is printed, it is guaranteed to
+ be printed without leading spaces.
+
+* Previously, wc did not align the count fields if POSIXLY_CORRECT was set,
+ but POSIX did not actually require this undesirable behavior, so it
+ has been removed.
+
+
* Major changes in release 5.0.2:
** Bug fixes
Index: doc/coreutils.texi
===
RCS file: /cvsroot/coreutils/coreutils/doc/coreutils.texi,v
retrieving revision 1.121
diff -p -u -r1.121 coreutils.texi
--- doc/coreutils.texi 18 Jul 2003 07:50:39 - 1.121
+++ doc/coreutils.texi 20 Jul 2003 07:34:20 -
@@ -2532,17 +2532,17 @@ wc [EMAIL PROTECTED]@dots{} [EMAIL PROTECTED]@do
@end example
@cindex total counts
[EMAIL PROTECTED] POSIXLY_CORRECT
@command{wc} prints one line of counts for each file, and if the file was
given as an argument, it prints the file name following the counts. If
more than one @var{file} is given, @command{wc} prints a final line
containing the cumulative counts, with the file name @file{total}. The
counts are printed in this order: newlines, words, characters, bytes.
-By default, each count is output right-justified in a 7-byte field with
-one space between fields so that the numbers and file names line up nicely
-in columns. However, @acronym{POSIX} requires that there be exactly one space
-separating columns. You can make @command{wc} use the @acronym{POSIX}-mandated
-output format by setting the @env{POSIXLY_CORRECT} environment variable.
+Each count is printed right-justified in a field with at least one
+space between fields so that the numbers and file names normally line
+up nicely in columns. The width of the count fields varies depending
+on the inputs, so you should not depend on a particular field width.
+However, as a @acronym{GNU} extension, if only one count is printed,
+it is guaranteed to be printed without leading spaces.
By default, @command{wc} prints three counts: the newline, words, and byte
counts. Options can specify that only certain counts be printed.
Index: src/wc.c
===
RCS file: /cvsroot/coreutils/coreutils/src/wc.c,v
retrieving revision 1.86
diff -p -u -r1.86 wc.c
--- src/wc.c17 Jun 2003 18:13:24 - 1.86
+++ src/wc.c20 Jul 2003 08:49:04 -
@@ -92,15 +92,26
Re: man page portability concern
Wendy Palm [EMAIL PROTECTED] writes: Copyright \(co 2003 Free Software Foundation, Inc. \(co gives a copyright symbol on my linux box, but results in the curser going to the top of the window and overwriting on all my other machines sun blade (5.8 Generic_108528-19 sun4u sparc SUNW,Sun-Blade-100) irix (IRIX64 da 6.5 01200532 IP27) and all my Crays. can this character be pulled out of the Copyright line? or am i missing something here? I think you're not invoking 'nroff' correctly on the other hosts. \(co has meant the copyright symbol in troff ever since 1975 or so, so it should be widely portable, if the nroff/troff commands are set up properly. For example, on Solaris 8, 'nroff' by default outputs data suitable for a Teletype Corporation Model 37 terminal. If your output device isn't compatible with that ancient terminal, you need to use the -T option. For example, 'nroff -Tlp' will cause \(co to output the three characters 'c backspace O' which should print as something roughly corresponding to a copyright symbol on printers that understand the backspace character. Another possibility on Solaris 8 is to pipe nroff's output through the 'col' command (e.g., 'nroff -man manpage | col'); this will filter out the model-37 characters and will cause '\(co' to output as 'c', which is perhaps the best that can be done on some devices. Another possibility is to install groff ftp://ftp.gnu.org/gnu/groff/groff-1.19.tar.gz; it has a number of output options to deal with special symbols like the copyright symbol. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: wc annoyances
Jim Meyering [EMAIL PROTECTED] writes: Not that it matters, but in some unusual cases, the new widths are worse than the old: $ dd bs=1 seek=1G of=b /dev/null 2 /dev/null $ ./wc -lw b 0 0 b $ wc -lw b 0 0 b Yes, that's true. The only way to print minimal widths is to run the 'wc' algorithm on all the input files, collect the outputs, and then print them all at the end. I've been meaning to do that with df at some point (since df suffers from column overflow more), but it does have some disconcerting effects, since zero output is printed until it's all ready. Anyway, I noticed on glitch in the merged version; here's a patch. 2003-07-20 Paul Eggert [EMAIL PROTECTED] * src/wc.c (get_input_fstatus): Fix typo: `stat' was being invoked with a null pointer when there were no file arguments. --- wc.c.~1.88.~Sun Jul 20 13:50:35 2003 +++ wc.cSun Jul 20 13:58:40 2003 @@ -554,7 +554,7 @@ get_input_fstatus (int nfiles, char * co int i; for (i = 0; i nfiles; i++) - fstatus[i].failed = (file[i] STREQ (file[i], -) + fstatus[i].failed = (! file[i] || STREQ (file[i], -) ? fstat (STDIN_FILENO, fstatus[i].st) : stat (file[i], fstatus[i].st)); } ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: man page portability concern
[EMAIL PROTECTED] (Bob Proulx) writes: But wouldn't someone need 'col -b'? I have always used it that way and now can't say if it is require or not. : -b Do not output any backspaces, printing only the last character : written to each column position. Otherwise the description does not say it cleans up backspaces as you describe. col -b is needed to clean up some other backspaces, e.g. the backspaces used to implement boldface by repeated overprinting. But it isn't needed for \(co. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: 'expr' problems with strcoll and POSIX (coreutils 5.0.1)
Jim Meyering [EMAIL PROTECTED] writes: I suspect you did not mean to reintroduce those anachronistic casts. Yes, it wasn't intentional; I was just syncing. I just noticed that some parentheses are missing in CCLONE, and there are some redundant parentheses in that and other macros. I'll sync coreutils into gnulib after applying the following patch to the coreutils version. (The long list of copyright years is for conformance to the copyright advice in the gnu maintainer's manual.) 2003-07-22 Paul Eggert [EMAIL PROTECTED] * xalloc.h (XCALLOC, XREALLOC, CCLONE): Fix under- and over-parenthesization in macros. --- coreutils/lib/xalloc.h Fri Jul 18 00:02:34 2003 +++ gnulib-exit_failure/lib/xalloc.hTue Jul 22 14:55:52 2003 @@ -1,6 +1,7 @@ /* xalloc.h -- malloc with out-of-memory checking - Copyright (C) 1990-2000, 2003 Free Software Foundation, Inc. + Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, + 1999, 2000, 2003 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 License as published by @@ -53,9 +54,8 @@ void *xrealloc (void *p, size_t n); char *xstrdup (const char *str); # define XMALLOC(Type, N_items) xmalloc (sizeof (Type) * (N_items)) -# define XCALLOC(Type, N_items) xcalloc (sizeof (Type), (N_items)) -# define XREALLOC(Ptr, Type, N_items) xrealloc ((Ptr), \ - sizeof (Type) * (N_items)) +# define XCALLOC(Type, N_items) xcalloc (sizeof (Type), N_items) +# define XREALLOC(Ptr, Type, N_items) xrealloc (Ptr, sizeof (Type) * (N_items)) /* Declare and alloc memory for VAR of type TYPE. */ # define NEW(Type, Var) Type *(Var) = XMALLOC (Type, 1) @@ -69,7 +69,7 @@ char *xstrdup (const char *str); /* Return a pointer to a malloc'ed copy of the array SRC of NUM elements. */ # define CCLONE(Src, Num) \ - (memcpy (xmalloc (sizeof (*Src) * (Num)), (Src), sizeof (*Src) * (Num))) + (memcpy (xmalloc (sizeof *(Src) * (Num)), Src, sizeof *(Src) * (Num))) /* Return a malloc'ed copy of SRC. */ # define CLONE(Src) CCLONE (Src, 1) ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Test-ing file types
Maciek Olczak [EMAIL PROTECTED] writes:
# echo ~${file}~
~~
# [ -d ${file} ]; echo $?
0
POSIX requires this behavior. POSIX says that the shell command
`[ FOO ]' exits true (status 0) if FOO is not null, false (status
1) otherwise. In this case FOO is -d, which is not null, so
`[ -d ]' must exit true (status 0).
See:
http://www.opengroup.org/onlinepubs/007904975/utilities/test.html
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: possible new feature for chmod
Alfred M. Szmidt [EMAIL PROTECTED] writes: Because the same syntax is used in other places, e.g.: install -m %-rw-rw-r-- file directory mkdir -m %drwxr-xr-x directory and similarly for mkfifo and mknod. Cool, I didn't know this. Sorry, I didn't explain myself clearly enough. My idea was that if we extended the syntax this way, the same extension would apply to every program that parses modes. The above syntax does not yet work for install and mkdir, but it would work under my proposal. If we used a different option, we'd need to add a separate option to each of the above commands. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
coreutils 5.0.90 present but cannot be compiled (Solaris 9, c89)
While trying to track down Nelson H. F. Beebe's problems with Solaris 9, I built coreutils 5.0.90 on Solaris 9 sparc (Forte Developer 7 C 5.4) using the following options: CC=c89 CFLAGS=-xO5 -dalign -xlibmil -xcg92 -xsafe=mem CXX=CC CXXFLAGS=-xO5 and got the following diagnostics: checking sys/sysinfo.h presence... yes configure: WARNING: sys/sysinfo.h: present but cannot be compiled configure: WARNING: sys/sysinfo.h: check for missing prerequisite headers? configure: WARNING: sys/sysinfo.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## ... checking nfs/nfs_clnt.h presence... yes configure: WARNING: nfs/nfs_clnt.h: present but cannot be compiled configure: WARNING: nfs/nfs_clnt.h: check for missing prerequisite headers? configure: WARNING: nfs/nfs_clnt.h: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## Here is a patch. (Perhaps all of coreutils should invoke AC_CHECK_HEADERS in the new form? But I wasn't that ambitious here.) 2003-08-05 Paul Eggert [EMAIL PROTECTED] * m4/prereq.m4 (jm_PREREQ_PHYSMEM, jm_PREREQ_STAT): Ignore headers that are present but cannot be compiled. This avoids spurious warnings on Solaris 9 sparc with Forte Developer 7 C 5.4. Index: m4/prereq.m4 === RCS file: /cvsroot/coreutils/coreutils/m4/prereq.m4,v retrieving revision 1.72 diff -p -u -r1.72 prereq.m4 --- m4/prereq.m46 Jun 2003 07:07:13 - 1.72 +++ m4/prereq.m45 Aug 2003 22:57:16 - @@ -118,7 +118,7 @@ AC_DEFUN([jm_PREREQ_PHYSMEM], [ AC_CHECK_HEADERS([unistd.h sys/pstat.h sys/sysmp.h sys/sysinfo.h \ machine/hal_sysinfo.h sys/table.h sys/param.h sys/sysctl.h \ -sys/systemcfg.h]) +sys/systemcfg.h],,, [AC_INCLUDES_DEFAULT]) AC_CHECK_FUNCS(pstat_getstatic pstat_getdynamic sysmp getsysinfo sysctl table) AC_REQUIRE([gl_SYS__SYSTEM_CONFIGURATION]) @@ -191,7 +191,8 @@ AC_DEFUN([jm_PREREQ_STAT], AC_CHECK_FUNCS(statvfs) # For `struct statfs' on Ultrix 4.4. - AC_CHECK_HEADERS(netinet/in.h nfs/nfs_clnt.h nfs/vfs.h) + AC_CHECK_HEADERS([netinet/in.h nfs/nfs_clnt.h nfs/vfs.h],,, +[AC_INCLUDES_DEFAULT]) AC_REQUIRE([jm_AC_TYPE_LONG_LONG]) ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
vasnprintf.m4 patch for Solaris 2.5.1 wcslen problem
In http://mail.gnu.org/archive/html/bug-coreutils/2003-08/msg00021.html Vin Shelton [EMAIL PROTECTED] writes: 1. On SunOS-5.5.1, configuring with --disable-nls, I cannot link 'who': gcc -g -O2 -o who who.o ../lib/libfetish.a ../lib/libfetish.a -lgen -lnsl Undefined first referenced symbol in file wcslen ../lib/libfetish.a(vasnprintf.o) (symbol belongs to implicit dependency /usr/lib/libw.so.1) This problem arises because Solaris 2.5.1 puts the following functions into /usr/lib/libw.so.1, so you need to link with -lw if you use any of these functions: fgetwc fputwc getwc isenglish isideogram isnumber isphonogram isspecial iswalnum iswalpha iswcntrl iswctype iswdigit iswgraph iswlower iswprint iswpunct iswspace iswupper iswxdigit mbftowc putwc scrwidth towlower towupper ungetwc watoll wcscat wcschr wcscmp wcscoll wcscpy wcscspn wcslen wcsncat wcsncmp wcsncpy wcspbrk wcsrchr wcstod wcstok wcstol wcstoul wcswcs wcswidth wcsxfrm wctype wcwidth wscasecmp wscat wschr wscmp wscoll wscpy wscspn wslen wsncasecmp wsncat wsncmp wsncpy wspbrk wsrchr wstod wstok wstol wstoll wsxfrm At the end of this message is a patch for that, which I have tested on my Solaris 2.5.1 host. The patch applies to both coreutils and gnulib, so I'll CC: this to bug-gnulib. The patch below is suboptimal, as it links every executable with -lw, even though only 'who' needs the -lw option, since only 'who' needs wcslen. However, Sun stopped generating patches for Solaris 2.5.1 on 2002-09-22, so it's a dying OS version, and I don't think we need to optimize coreutils for Solaris 2.5.1 so long as it builds and runs correctly. /usr/lib/libw.so.1 is part of the SUNWcsu package, so it is a core library available on any Solaris 2.5.1 host, and we shouldn't have to worry that it might be on the build host but not on the run host. I notice that other gnulib modules use the above functions. There is a FIXME about this in regex.m4, for example. Quite possibly coreutils is not using some wide-char functions that it could use on Solaris 2.5.1. However, these problems don't prevent the coreutils build from succeeding, so I didn't investigate this further. 2003-08-08 Paul Eggert [EMAIL PROTECTED] * m4/vasnprintf.m4 (gl_PREREQ_VASNPRINTF): Solaris 2.5.1 needs -lw to get the wcslen function. --- vasnprintf.m4.~1.1.~Thu Jul 10 04:23:31 2003 +++ vasnprintf.m4 Fri Aug 8 23:37:20 2003 @@ -51,6 +51,9 @@ AC_DEFUN([gl_PREREQ_VASNPRINTF], AC_REQUIRE([gt_TYPE_WCHAR_T]) AC_REQUIRE([gt_TYPE_WINT_T]) AC_CHECK_FUNCS(snprintf) + + # Solaris 2.5.1 needs -lw to get the wcslen function. + AC_SEARCH_LIBS(wcslen, [w]) ]) # Prerequisites of lib/asnprintf.c. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: date(1) treats TZ '' differently from unset
Ed Avis [EMAIL PROTECTED] writes: On a system where local time is +0100: % (unset TZ; date +%z) +0100 % (TZ= date +%z) + Are you sure this is correct? This is a C library issue, not a coreutils issue, since coreutils simply repeats what the C library tells it. In many C libraries, TZ='' is equivalent to TZ='GMT0' or TZ='UTC0', and that's the behavior you're observing. An unset TZ is equivalent to a system-supplied default, typically the local time where the host is physically located. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Misc Problems with coreutils-5.0.90
Vin Shelton [EMAIL PROTECTED] writes: + diff -u out exp --- out 2003-08-07 13:37:17.441967000 -0400 +++ exp 2003-08-07 13:37:17.484972000 -0400 @@ -1,9 +1,9 @@ -0a/b/F -4a/b -8a +4a/b/F +8a/b +12 a === -0a/b/F -4a/b +4a/b/F +8a/b 4a === -8a +12 a I happen to have a Network Appliance and Solaris 8 box, and looked into this. Here is a patch. 2003-08-08 Paul Eggert [EMAIL PROTECTED] * tests/du/basic: Ensure that a/b/F has at least 65 bytes too. --- basic.~1.10.~ Fri Mar 28 04:55:04 2003 +++ basic Fri Aug 8 15:50:31 2003 @@ -19,11 +19,11 @@ framework_failure=0 mkdir -p $tmp || framework_failure=1 cd $tmp || framework_failure=1 mkdir -p a/b d d/sub || framework_failure=1 -printf 'make-sure-the-file-is-non-empty\n' a/b/F || framework_failure=1 # Ensure that these files contain more than 64 bytes, so that we don't # immediately disqualify file systems (e.g., NetApp) on which smaller # files take up zero disk blocks. +printf '%*s' 65 make-sure-the-file-is-non-empty a/b/F || framework_failure=1 seq --format=%100g 1 90 | head --bytes=4k d/1 cp d/1 d/sub/2 ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: possible new feature for chmod
Alfred M. Szmidt [EMAIL PROTECTED] writes: Why not fix these problems by disambiguating the syntax? You can put a new character in front of the new-format mode strings. E.g., chmod %-rw-rw-r-- file Why not fix it with a seperate option instead (which this basicly is)? Because the same syntax is used in other places, e.g.: install -m %-rw-rw-r-- file directory mkdir -m %drwxr-xr-x directory and similarly for mkfifo and mknod. I suppose we could use a --ls-mode option instead. But it seems more consistent to me to make the suggestion improvement part of the mode syntax, since it's meant to take the place of 755, which is already part of the mode syntax. If you don't like '%', perhaps you'd prefer '@'? That might be a little clearer. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: vfat lost file problem
Jim Meyering [EMAIL PROTECTED] writes:
shouldn't the above two references to source_dirname
be to dest_dirname instead, because only the limits of the
destination directory are relevant?
Either way should work, because when the code is executed we've
already verified that the source and destination are the same
directory.
It makes the code clearer to use the destination directory, though.
While we're on the subject of same.c, what do you think about the idea
of assuming stdlib.h? I notice a lot of occurrences of things like
HAVE_DECL_FREE -- is that because you still use hosts that don't have
stdlib.h? If so, you probably wouldn't like that part of the
following patch:
2003-08-18 Paul Eggert [EMAIL PROTECTED]
* lib/same.c: Include stdlib.h and string.h unconditionally,
as we're now assuming that part of hosted C89.
(free) [!HAVE_DECL_FREE]: Remove decl; no longer needed.
(same_name): Invoke pathconf on destination, not source, as
that's a bit clearer even if they are the same dir.
* m4/same.m4 (gl_SAME): Do not check for stdlib.h or string.h or free.
Check for pathconf.
Index: lib/same.c
===
RCS file: /cvsroot/coreutils/coreutils/lib/same.c,v
retrieving revision 1.11
diff -p -u -r1.11 same.c
--- lib/same.c 18 Aug 2003 07:47:40 - 1.11
+++ lib/same.c 18 Aug 2003 21:38:50 -
@@ -26,9 +26,7 @@
#ifdef HAVE_UNISTD_H
# include unistd.h
#endif
-#if HAVE_STDLIB_H
-# include stdlib.h
-#endif
+#include stdlib.h
#include sys/types.h
#include sys/stat.h
#include ctype.h
@@ -37,11 +35,7 @@
extern int errno;
#endif
-#if HAVE_STRING_H
-# include string.h
-#else
-# include strings.h
-#endif
+#include string.h
#include limits.h
#ifndef _POSIX_NAME_MAX
@@ -53,13 +47,6 @@ extern int errno;
#include error.h
#include xalloc.h
-#ifndef HAVE_DECL_FREE
-this configure-time declaration test was not run
-#endif
-#if !HAVE_DECL_FREE
-void free ();
-#endif
-
#define MIN(a, b) ((a) (b) ? (a) : (b))
#define SAME_INODE(Stat_buf_1, Stat_buf_2) \
@@ -121,13 +108,13 @@ same_name (const char *source, const cha
#if ! _POSIX_NO_TRUNC HAVE_PATHCONF defined _PC_NAME_MAX
if (same ! identical_basenames)
{
- long name_max = (errno = 0, pathconf (source_dirname, _PC_NAME_MAX));
+ long name_max = (errno = 0, pathconf (dest_dirname, _PC_NAME_MAX));
if (name_max 0)
{
if (errno)
{
/* Shouldn't happen. */
- error (1, errno, %s, source_dirname);
+ error (1, errno, %s, dest_dirname);
}
same = false;
}
Index: m4/same.m4
===
RCS file: /cvsroot/coreutils/coreutils/m4/same.m4,v
retrieving revision 1.1
diff -p -u -r1.1 same.m4
--- m4/same.m4 17 Aug 2003 17:58:01 - 1.1
+++ m4/same.m4 18 Aug 2003 21:38:50 -
@@ -1,5 +1,5 @@
-# same.m4 serial 1
-dnl Copyright (C) 2002 Free Software Foundation, Inc.
+# same.m4 serial 2
+dnl Copyright (C) 2002, 2003 Free Software Foundation, Inc.
dnl This file is free software, distributed under the terms of the GNU
dnl General Public License. As a special exception to the GNU General
dnl Public License, this file may be distributed as part of a program
@@ -9,6 +9,6 @@ dnl the same distribution terms as the r
AC_DEFUN([gl_SAME],
[
dnl Prerequisites of lib/same.c.
- AC_CHECK_HEADERS_ONCE(stdlib.h string.h unistd.h)
- AC_CHECK_DECLS_ONCE(free)
+ AC_CHECK_HEADERS_ONCE(unistd.h)
+ AC_CHECK_FUNCS(pathconf)
])
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-5.0.90 problems on Crays
Wendy Palm [EMAIL PROTECTED] writes: with the change i proposed, the only error i have with the tests is date-tests and i haven't had time to check what that problem is yet. I doubt whether the tests exercise the md5 and sha code a lot, and I suspect that there will be latent bugs, unless someone carefully inspects the code and makes sure that there are no problems. i'd be interested to know what programs are potentially problems with 32bits. possibly some shifting assumptions may be messed up. For example, here's the first use of md5_uint32 in md5.c: ((md5_uint32 *) resbuf)[0] = SWAP (ctx-A); SWAP is defined as follows: #ifdef WORDS_BIGENDIAN # define SWAP(n)\ (((n) 24) | (((n) 0xff00) 8) | (((n) 8) 0xff00) | ((n) 24)) #else # define SWAP(n) (n) #endif If Cray is a WORDS_BIGENDIAN host, this will put garbage bits into the high-order part of ((md5_uint32 *) resbuf)[0]. This is just the first occurrence that I found. Basically, someone needs to check every instance of md5_uint32 and make sure that it works OK. cc -hnointrinsics -Wl,-Dmsglevel=334:fatal -o [ lbracket.o ../lib/libfetish.a ../lib/libfetish.a -lgen GETTMC: invalid primary machine name on TARGET statement Does it work to change the -o [ to -o lbracket, and then to issue mv [ lbracket afterwards? ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: sort -o x -o y
Dan Jacobson [EMAIL PROTECTED] writes:
$ echo a|sort -o x -o y
$ ls
y
POSIX allows this behavior, but it's admittedly weird.
I think that option order should not matter, unless POSIX or the
documentation explicitly says otherwise. So I propose the following
patch. While looking into this problem I noticed that sort's -t
option doesn't let you specify a NUL as a field separator (this is a
related issue since 'sort' uses 0 to represent no option specified
yet). Also, the documentation and usage strings incorrectly say
white space several places where they should say blanks. Here's
a patch for these problems.
2003-09-02 Paul Eggert [EMAIL PROTECTED]
* NEWS: sort -t '\0' now uses a NUL tab.
sort option order no longer matters, unless POSIX requires it.
* doc/coreutils.texi (sort invocation): -d now overrides -i.
whitespace - blanks; whitespace isn't correct.
-t '\0' now specifies a NUL tab.
* src/sort.c (usage): Say blanks instead of whitespace,
Similar fixes for many comments.
(TAB_DEFAULT): New constant, so that we can support NUL as
the field separator.
(tab): Now int, not char. Initialize to TAB_DEFAULT.
(specify_sort_size): If multiple sizes are specified, use the largest.
(begfield, limfield): Support NUL tab char.
(set_ordering): Do not let -i override -d.
(main): Report an error if incompatible -o or -t options are given.
Report an error for -t ''. Allow -t '\0' to specify a NUL tab.
Index: NEWS
===
RCS file: /cvsroot/coreutils/coreutils/NEWS,v
retrieving revision 1.124
diff -p -u -r1.124 NEWS
--- NEWS27 Aug 2003 09:18:28 - 1.124
+++ NEWS2 Sep 2003 22:50:50 -
@@ -13,6 +13,12 @@ GNU coreutils NEWS
timestamps to their full nanosecond resolution; microsecond
resolution is the best we can do right now.
+ sort now supports the zero byte (NUL) as a field separator; use -t '\0'.
+ The -t '' option, which formerly had no effect, is now an error.
+
+ sort option order no longer matters for the options -S, -d, -i, -o, and -t.
+ Stronger options override weaker, and incompatible options are diagnosed.
+
** Bug fixes
stat no longer overruns a buffer for format strings ending in `%'
Index: doc/coreutils.texi
===
RCS file: /cvsroot/coreutils/coreutils/doc/coreutils.texi,v
retrieving revision 1.130
diff -p -u -r1.130 coreutils.texi
--- doc/coreutils.texi 17 Aug 2003 17:10:25 - 1.130
+++ doc/coreutils.texi 2 Sep 2003 22:51:09 -
@@ -2969,6 +2969,8 @@ converting to floating point.
@vindex LC_CTYPE
Ignore nonprinting characters.
The @env{LC_CTYPE} locale determines character types.
+This option has no effect if the stronger @option{--dictionary-order}
+(@option{-d}) option is also given.
@item -M
@itemx --month-sort
@@ -2976,7 +2978,7 @@ The @env{LC_CTYPE} locale determines cha
@opindex --month-sort
@cindex months, sorting by
@vindex LC_TIME
-An initial string, consisting of any amount of whitespace, followed
+An initial string, consisting of any amount of blanks, followed
by a month name abbreviation, is folded to UPPER case and
compared in the order @samp{JAN} @samp{FEB} @dots{} @samp{DEC}.
Invalid names compare low to valid names. The @env{LC_TIME} locale
@@ -2989,7 +2991,7 @@ category determines the month spellings.
@cindex numeric sort
@vindex LC_NUMERIC
Sort numerically: the number begins each line; specifically, it consists
-of optional whitespace, an optional @samp{-} sign, and zero or more
+of optional blanks, an optional @samp{-} sign, and zero or more
digits possibly separated by thousands separators, optionally followed
by a decimal-point character and zero or more digits. The @env{LC_NUMERIC}
locale specifies the decimal-point character and thousands separator.
@@ -3085,7 +3087,7 @@ than @var{size}.
@cindex field separator character
Use character @var{separator} as the field separator when finding the
sort keys in each line. By default, fields are separated by the empty
-string between a non-whitespace character and a whitespace character.
+string between a non-blank character and a blank character.
That is, given the input line @[EMAIL PROTECTED] foo bar}}, @command{sort} breaks it
into fields @[EMAIL PROTECTED] foo}} and @[EMAIL PROTECTED] bar}}. The field
separator is
not considered to be part of either the field preceding or the field
@@ -3093,6 +3095,10 @@ following. But note that sort fields th
as @option{-k 2}, or sort fields consisting of a range, as @option{-k 2,3},
retain the field separators present between the endpoints of the range.
+To specify a zero byte (@acronym{ASCII} @sc{nul} (Null) character) as
+the field separator, use the two-character string @samp{\0}, e.g.,
[EMAIL PROTECTED] -t '\0'}.
+
@item -T @var
Re: [Bug-gnulib] Rounding bug in human_readable from human.c
Lute Kamstra [EMAIL PROTECTED] writes:
10550 is written as 10k
Thanks for the bug report. I installed the following patch into gnulib.
2003-09-03 Paul Eggert [EMAIL PROTECTED]
* human.c (human_readable): Fix bug that rounded 10501 to 10k.
Bug reported by Lute Kamstra in
http://mail.gnu.org/archive/html/bug-gnulib/2003-09/msg3.html.
--- human.c.~1.21.~ Fri Jun 6 15:37:23 2003
+++ human.c Wed Sep 3 12:49:04 2003
@@ -355,11 +355,9 @@ human_readable (uintmax_t n, char *buf,
}
}
-if (inexact_style == human_ceiling
- ? 0 tenths + rounding
- : inexact_style == human_round_to_nearest
- ? 5 tenths + (2 rounding + (amt 1))
- : /* inexact_style == human_floor */ 0)
+if (inexact_style == human_round_to_nearest
+ ? 5 tenths + (0 rounding + (amt 1))
+ : inexact_style == human_ceiling 0 tenths + rounding)
{
amt++;
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: GNU/KFreeBSD triplet change
Robert Millan [EMAIL PROTECTED] writes: Please apply this patch for uname -o to cope with that. It also adds knetbsd-gnu, which is the Glibc-based/KNetBSD-based variant of GNU. Thanks, but your email contained no patch; see http://mail.gnu.org/archive/html/bug-coreutils/2003-09/msg00017.html. Could you please resend the patch, along with a ChangeLog entry? Thanks. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: install -D into directory
Koblinger Egmont [EMAIL PROTECTED] writes: Currently the form ``install -D some files /here/'' (with trailing slash) is unusable for anything Unfortunately POSIX standard says that standard utilities must ignore any trailing slashes on existing directory names. POSIX does not standardize 'install', but it's better if 'install' is consistent with standard utilities. Hence install -D some files /here/ should behave like install -D some files /here, if /here is an existing directory. One possible way around the problem would be to add a new option, say -e, to get the behavior that you want. install -e A B C DEST would do the equivalent of install -d DEST first, and then do the equivalent of install A B C DEST. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: dd bug
Buciuman Adrian [EMAIL PROTECTED] writes: I've post a message some weeks ago about a possible dd bug. I assume that you're talking about this one? http://mail.gnu.org/archive/html/bug-coreutils/2003-08/msg00105.html What do you think about ? Is that indeed a bug ? It's not easy to say. I can't easily reproduce the bug, since I don't have the faulty device that you have. Can you find out exactly in the source code where 'dd' is going wrong, and come up with a patch to fix it? ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: dd bug
Buciuman Adrian [EMAIL PROTECTED] writes: I have dozens of faulty diskettes , so I can snail- mail some to you. Thanks, but I'd rather figure it out directly. Possibly my floppy drive reader will behave differently with those diskettes. But I am now almost sure something is wrong in GNU dd , because I ' ve tried the dd that comes with FreeBSD . It worked well . The hardware was the same . It could be a GNU dd bug; or it could be a kernel or driver bug. To help decide this, can you please run the following shell command, and then email the contents of the file 'trace' to [EMAIL PROTECTED]? Thanks. strace -o trace dd if=/dev/fd0 of=test bs=720k conv=sync,noerror ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: regarding head/tail syntax
Jim covered most of the points nicely, but I thought I'd fill in some corners: Aron Griffis [EMAIL PROTECTED] writes: I don't see a motivation for their removal, since the older syntax is unambiguous and in heavy use by thousands of UNIX scripts already in existence. As Jim said, the motivation is POSIX conformance. I wasn't present when POSIX was written, but I suspect their motivations were as follows: (1) Options should use a regular syntax. (2) Option order should normally not matter. (You can find more details about this in http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap12.html.) Clearly, traditional tail doesn't obey these rules. For example: $ tail -1 /etc/motd Sun Microsystems Inc. SunOS 5.9 Generic May 2002 $ tail -f /etc/motd Sun Microsystems Inc. SunOS 5.9 Generic May 2002 ^C $ tail -1 -f /etc/motd tail: cannot open input $ tail -f -1 /etc/motd tail: cannot open input In the process of cleaning up this mess, the POSIX standardizers decided that tail -10 should mean the same thing as tail -1 -0, i.e. that 1 and 0 should be separate options, just as the alphabetic options are. This was for regularity. And if option order doesn't matter, then it should be equivalent to tail -0 -1, or to tail -01. Hence it wasn't right to use that syntax at all, so people are supposed to use the new tail -n 10 syntax instead. Mind you I'm not saying that I would have agreed with all this. I'm just trying to let you peek into what I suspect was the thought processors of the POSIX standardizers (who did all this work more than a decade ago). I seriously doubt that any of the commercial UNIXes will ever disallow the -number syntax That's quite possibly true. For example, Solaris (the only commercial UNIX I regularly use these days) does not conform to POSIX by default. You have to prepend /usr/xpg4/bin to your path to get a POSIX environment. I suppose Gentoo could do something like that, but I don't recommend it; it's a real pain in practice. Better would be Jim's suggestion to set _POSIX2_VERSION back to _POSIX2_VERSION=199209 somewhere -- either in the default login environment, or in your C library, or wherever, as a temporary transition aid. (Whose idea was it to set _POSIX2_VERSION to 200112 in Gentoo's C library, anyway? :-) ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: dd bug
Buciuman Adrian [EMAIL PROTECTED] writes:
read(0, 1 ..., 737280) = 36864
write(1, 1 ..., 737280) = 737280
read(0, 0x4015a000, 737280) = -1 EIO (Input/output error)
write(2, dd: , 4) = 4
write(2, reading `/dev/fd0\', 18) = 18
write(2, : Input/output error, 20)= 20
write(2, \n, 1) = 1
write(2, 0+1 records in\n, 15)= 15
write(2, 1+0 records out\n, 16) = 16
_llseek(0, 737280, [774144], SEEK_CUR) = 0
I think I see one problem, though I'm not sure it's your problem.
Here is a patch to CVS coreutils. I can't easily test this patch,
though, since I don't have your hardware. Can you try this patch out?
2003-09-22 Paul Eggert [EMAIL PROTECTED]
Fix bug that may be related to Buciuman Adrian's bug report in
http://mail.gnu.org/archive/html/bug-coreutils/2003-08/msg00105.html
where 'dd' created a file that was too large. The bug was that dd
assumed that the input file offset does not advance after a failed
read; but POSIX says that the input file offset is undefined after
a failed read.
This also causes 'noerror skip=...' to not fail on read error
if the skip causes a read. POSIX seems to require this.
It also fixes a FIXME that I noticed while in the neighborhood.
* src/dd.c (MAX_BLOCKSIZE): New macro.
(input_seekable, input_seek_errno, input_offset,
input_offset_overflow): New vars.
(write_output, dd_copy): Pass EXIT_FAILURE to quit, not 1.
(scanargs): Reject block sizes greater than MAX_BLOCKSIZE
(advance_input_offset): New function.
(skip_via_lseek): Set errno to zero when reporting our failure,
so that we don't report based on garbage errno.
(skip): If fdesc is standard input, advance the input offset.
Do not quit if reading, and if noerror was specified;
POSIX seems to require this.
If read fails on output file, report the earlier lseek failure
instead; this fixes a FIXME in dd_copy.
(advance_input_after_read_error): New function.
(dd_copy): Use it, instead of assuming that failed reads
do not advance the file pointer. Advance input offset
after nonfailed reads.
(main): Determine initial input offset, seekability of input,
and error if it wasn't seekable.
Index: dd.c
===
RCS file: /cvsroot/coreutils/coreutils/src/dd.c,v
retrieving revision 1.150
diff -p -u -r1.150 dd.c
--- dd.c18 Sep 2003 22:19:03 - 1.150
+++ dd.c22 Sep 2003 07:30:56 -
@@ -66,6 +66,12 @@
/* Default input and output blocksize. */
#define DEFAULT_BLOCKSIZE 512
+/* Maximum blocksize. Keep it smaller than SIZE_MAX, so that we can
+ allocate buffers that size. Keep it smaller than SSIZE_MAX, for
+ the benefit of system calls like read. And keep it smaller than
+ OFF_T_MAX, for the benefit of the large-offset seek code. */
+#define MAX_BLOCKSIZE MIN (SIZE_MAX, MIN (SSIZE_MAX, OFF_T_MAX))
+
/* Conversions bit masks. */
#define C_ASCII 01
#define C_EBCDIC 02
@@ -126,6 +132,19 @@ static uintmax_t r_partial = 0;
/* Number of full blocks read. */
static uintmax_t r_full = 0;
+/* True if input is seekable. */
+static bool input_seekable;
+
+/* Error number corresponding to initial attempt to lseek input.
+ If ESPIPE, do not issue any more diagnostics about it. */
+int input_seek_errno;
+
+/* File offset of the input, in bytes, along with a flag recording
+ whether it overflowed. The offset is valid only if the input is
+ seekable and if the offset has not overflowed. */
+static uintmax_t input_offset;
+bool input_offset_overflow;
+
/* Records truncated by conv=block. */
static uintmax_t r_truncate = 0;
@@ -479,7 +498,7 @@ write_output (void)
error (0, errno, _(writing to %s), quote (output_file));
if (nwritten != 0)
w_partial++;
- quit (1);
+ quit (EXIT_FAILURE);
}
else
w_full++;
@@ -582,26 +601,20 @@ scanargs (int argc, char **argv)
if (STREQ (name, ibs))
{
- /* Ensure that each blocksize is = SSIZE_MAX. */
- invalid |= SSIZE_MAX n;
+ invalid |= ! (0 n n = MAX_BLOCKSIZE);
input_blocksize = n;
- invalid |= input_blocksize != n || input_blocksize == 0;
conversions_mask |= C_TWOBUFS;
}
else if (STREQ (name, obs))
{
- /* Ensure that each blocksize is = SSIZE_MAX. */
- invalid |= SSIZE_MAX n;
+ invalid |= ! (0 n n = MAX_BLOCKSIZE);
output_blocksize = n;
- invalid |= output_blocksize != n || output_blocksize == 0;
conversions_mask |= C_TWOBUFS;
}
else if (STREQ (name
Re: nohup?
[EMAIL PROTECTED] (Bob Proulx) writes: Could you describe what that option does for those of us not having access to a solaris machine? On Solaris 9, nohup -p pid ... arranges for the referenced processes to become immune to hangups. Similiarly, nohup -g pgid ... arranges for the referenced process groups to become immune to hangups. There are two other related options: -F force. Grab control of the target process, even if another process already has control. -a always. Change the disposition of SIGHUP and SIGQUIT even if the process has installed a handler for either signal. I don't know why someone would want these options. Perhaps JGraham can explain why they'd be useful. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: du -x option doesn't work
erno palonheimo [EMAIL PROTECTED] writes: i noticed that -x option of du, which is supposed to make it stay inside one filesystem, doesn't apparently do anything. It works for me, with CVS coreutils and Linux kernel 2.4.18-bf2.4, when I use du -x /. Possibly the bug has been fixed since 5.0.90; if not, perhaps you can supply more details about your particular problem. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: bug in /bin/ls
Sorry, but it looks to me like your host has been rootkitted. If so, it's probably time to reinstall from scratch, and to do a better job of securing it next time. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup?
JGraham [EMAIL PROTECTED] writes: tell me you've never run a process that needed to run, then realized that you had to log off? I can't tell you that. OK, you're starting to convince me. http://www.chiark.greenend.org.uk/~peterb/linux/interfereproc/ suggests that it'll be a bit tricky to get this to work properly, though. It'd be nice to mimic Solaris nohup's capabilities, but we want the code to work on Solaris, Linux, HP-UX, etc. Perhaps someone can volunteer to find out how this should work portably. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup?
Jim Meyering [EMAIL PROTECTED] writes: So this would work like bash's `disown -h'? I think it's stronger than disown -h. Not that I'm an expert, but my impression is that disown -h merely arranges for the subprocess to continue undisturbed even if Bash is HUPped. But Solaris 'nohup -p 27' makes process 27 immune to nohup, regardless of 27's parent. I suspect it does this by pretending to be a debugger, attaching to process 27, and then causing the process to execute the equivalent of 'signal (SIGHUP, SIG_IGN)'. Hairy, huh? Perhaps disown -h is enough to solve the original requester's problem, and the original requester can be convinced to use bash. In that case we're done already. If not, then it's a reasonable request though I don't want to be the poor schmoe who has to implement it. Andreas Schwab [EMAIL PROTECTED] writes: You don't need nohup for that. Background processes will just continue running after logout. That's true for many shells, but not all. It's not true for a POSIX-compliant sh, as far as I can tell from reading the standard. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
CVS coreutils test problems with du and sort
The latest coreutils CVS has a differently-worded error message, so I had to install the following patch to get make check to work. Also, I suggest removing tests/sort/sort-tests from CVS. Its existence causes 'make check' to assume that all the test input files (e.g., tests/sort/01a.I) exist; but they aren't checked in under CVS, so all the 'sort' tests fail. 2003-10-12 Paul Eggert [EMAIL PROTECTED] * tests/du/no-x: Change wording of diagnostic to match latest du.c. * tests/sort/sort-tests: Remove from CVS; assume that people brave enough to check coreutils out from CVS can rebuild it. Index: tests/du/no-x === RCS file: /cvsroot/coreutils/coreutils/tests/du/no-x,v retrieving revision 1.1 diff -p -u -r1.1 no-x --- tests/du/no-x 22 Jan 2003 12:49:08 - 1.1 +++ tests/du/no-x 13 Oct 2003 05:40:29 - @@ -31,7 +31,7 @@ fail=0 # This must exit nonzero. du d /dev/null 2out fail=1 cat \EOF exp -du: cannot change to directory `d/no-x': Permission denied +du: `d/no-x': Permission denied EOF cmp out exp || fail=1 ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ping on GNU/KFreeBSD patch sent a while ago
Robert Millan [EMAIL PROTECTED] writes: http://mail.gnu.org/archive/html/bug-coreutils/2003-09/msg00032.html I had let that slide; sorry. I installed the following patch (which is not quite the same as what you proposed, but looks more correct to me) into gnulib, and it should percolate into coreutils soon. 2003-10-27 Paul Eggert [EMAIL PROTECTED] * host-os.m4 (UTILS_HOST_OS): Identify GNU/KFreeBSD and GNU/KNetBSD using their new names (which have a K in front of the kernel name). Requested by Richard Stallman. Index: host-os.m4 === RCS file: /cvsroot/gnulib/gnulib/m4/host-os.m4,v retrieving revision 1.2 retrieving revision 1.3 diff -p -u -r1.2 -r1.3 --- host-os.m4 16 Aug 2003 08:53:43 - 1.2 +++ host-os.m4 28 Oct 2003 03:06:18 - 1.3 @@ -30,8 +30,9 @@ AC_DEFUN([UTILS_HOST_OS], openbsd*) os='OpenBSD';; nsk*) os='NonStop Kernel';; nonstopux*) os='NonStop-UX';; - netbsd*-gnu*) os='GNU/NetBSD';; netbsd*)os='NetBSD';; + knetbsd*-gnu*) os='GNU/KNetBSD';; + kfreebsd*-gnu*) os='GNU/KFreeBSD';; msdosdjgpp*)os='DJGPP';; mpeix*) os='MPE/iX';; mint*) os='MiNT';; @@ -41,7 +42,6 @@ AC_DEFUN([UTILS_HOST_OS], hpux*) os='HP-UX';; hiux*) os='HI-UX';; gnu*) os='GNU';; - freebsd*-gnu*) os='GNU/FreeBSD';; freebsd*) os='FreeBSD';; dgux*) os='DG/UX';; bsdi*) os='BSD/OS';; ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] ping on GNU/KFreeBSD patch sent a while ago
Robert Millan [EMAIL PROTECTED] writes: http://mail.gnu.org/archive/html/bug-coreutils/2003-09/msg00032.html Thanks. But I didn't intend to change the netbsd*-gnu rule. That one corresponds to the system based on NetBSD's kernel and libc (as opposed to knetbsd*-gnu which is NetBSD's kernel with Glibc). OK, but then wy did the above-referenced patch get rid of the freebsd*-gnu* rule? That is, why is FreeBSD different from NetBSD in this area? config.guess doesn't do anything special for NetBSD. That is, config.guess's FreeBSD rule prepends k when it appends -gnu, but its NetBSD rule doesn't do that. Why are the two operating systems treated differently here? And if config.guess's NetBSD rule doesn't prepend k, why does the patch add a rule for knetbsd*-gnu? In any case, the following: - netbsd*-gnu*) os='GNU/NetBSD';; netbsd*)os='NetBSD';; Would call it NetBSD which is incorrect, so we need to find a better solution. Sorry, I'm lost. This is all getting pretty complicated. Can you explain what's going on here, from first principles? I'd like an explanation that I could put into a comment in host-os.m4. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Sort Bug
I don't get the results that you do. What is the output of the following commands on your host? sort --version locale [EMAIL PROTECTED] writes: [EMAIL PROTECTED]ls -l | sort -k 5 total 3165056 -rw-r--r-- 1 robertd users 678 Jul 10 15:15 rejected_tms_inbox.dmp.gz -rw-r--r-- 1 robertd users 840 Jul 21 13:50 161examples.dmp.gz -rw-r--r-- 1 robertd users2446 Aug 14 13:32 prob.dmp.gz That's not what sort -k 5 is supposed to do. It's supposed to sort lexicographically, so the proper order for the 1st four lines is: total 3165056 -rw-r--r-- 1 robertd users2446 Aug 14 13:32 prob.dmp.gz -rw-r--r-- 1 robertd users 678 Jul 10 15:15 rejected_tms_inbox.dmp.gz -rw-r--r-- 1 robertd users 840 Jul 21 13:50 161examples.dmp.gz because 2446 lexicographically precedes 678 (because 2 precendes 6). You probably want sort -k 5n or something like that. However, it's still worrisome that sort -k 5 doesn't work as it should. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: BUGs in de date command
Patricio Baya [EMAIL PROTECTED] writes: [EMAIL PROTECTED] controles]$ date vie oct 31 13:41:49 ART 2003 [EMAIL PROTECTED] controles]$ date -d 1 month ago mi oct 1 13:42:04 ART 2003 The re is a big mistake. If today is 31/10/2003 , 1 Month Ago must return or 30/09 or someting else, but not OCT 1 I don't see why it's a big mistake. 1 month before October 31 is September 31. But there is no September 31, so you've specified an ambiguous day. September 30 and October 1 are both reasonable ways to resolve the ambiguity. It might be nice to change date to behave the way that you like, but I don't see why the current behavior is a bug. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: suggestion - diff + patch
Stefanos Harhalakis [EMAIL PROTECTED] writes: I believe that it should have an option to compare source and destination files before replacing the destination. I like the basic idea, and have been using a wrapper like yours for many years. But doesn't the implementation have to be more complicated than that? For example, suppose the destination already exists, and has the proper contents, but has the wrong ownership? Or suppose the destination is supposed to be stripped? Or a backup was supposed to be made? Etc. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: conformance vs. compatibility
ari [EMAIL PROTECTED] writes: 'POSIXLY_CORRECT' may be specified if strict posix compliance must be followed. I see no reason why this cannot be the case with the 'head' and 'tail' functions. My feeling is that POSIXLY_CORRECT is not something that users would normally want to set, whereas the choice of POSIX standards is something that users have to deal with on occasion (unfortunately). That is why coreutils has the _POSIX2_VERSION environment variable. Setting _POSIX2_VERSION=199209 in your environment causes 'head', 'tail', etc. to behave the way that you'd like. It's up to your the coreutils installer (typically a software distribution maintainer) to specify the default value for _POSIX2_VERSION. If they don't specify a default value, coreutils defaults to the older standard. So the compatibility problems that you mention occur only when the coreutils installer has indicated a desire to conform to the new standard by default (even when that is incompatible with the old standard). If you like, you can always ask your coreutils installer to build coreutils so that it defaults to the old standard instead of to the new one. - Posix was designed to increase portability. Strict conformance in this manner cripples portability instead. It hurts some kinds of portability and helps others. It depends on what you want. Admittedly it is a judgment call. - In IEEE Std 1003.1 (2003 Edition), the 'head' manual page states (under the APPLICATION USAGE header): The obsolescent - number form is withdrawn in this version. Applications should use the -n number option. Note the use of should here. If applications using 'head' are not _required_ to use the '-n number' option, then the actual program should definitely support it. That doesn't follow. For example, an application can stop using head -3 and can instead use sed 3q. The application is not required to use head -n 3. That is, unless one would like to create a system that requires strict posix compliance of all executables present. I think we all agree that coreutils shouldn't require that all its users strictly conform to POSIX. However, coreutils does have a goal of conforming to POSIX itself. - GNU utilities support many options that are not covered in posix. True, but these options aren't under dispute, as they follow the syntactic guidelines of POSIX. There is a consistency argument for sticking to the guidelines. One may argue that 'tail -35' does not result in a multi-digit option of 35, but rather a null option, with argument of 35. That's not how the guidelines work. If 'tail' were to follow the guidelines, then 'tail -35', 'tail -3 -5', 'tail -5 -3', and 'tail -53' would all be equivalent. I don't think anybody'd like that. To illustrate my position further, let's examine another way that these programs violate posix standards: long options. I don't see why they violate the standards. A plain -- argument cannot possibly be an option (since it is a standard delimiter), and therefore - cannot possibly be an option name. Long options therefore are not part of the standard option syntax at all; they are a pure extension. I suspect this is by design, as RMS was involved in the original POSIX specification effort, and RMS likes long options. I fail to see why the GNU utilities should be configured to break posix compliance for the convenience of long options, yet not for the requirement of portability. It's a judgment call. Long options are clearly useful. It's less clearly useful to support options that have been officially obsolescent for more than a decade, and have been officially obsolete for almost two years. While these features may be considered obsolescent by some, they are certainly not obsolete. One can argue about de facto, but clearly they are obsolete de jure. At some point developers should get used to writing portable code that does not use the features. Reasonable people can disagree on when that point should be. In the All progress depends on the unreasonable man department, I've been running with _POSIX2_VERSION=200112 in my environment for many months. Any programs that want to be portable to my environment have to be fixed to not rely on these obsolete features. It's not been much of a problem, really. (I use Debian, if that matters.) ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: conformance vs. compatibility
ari [EMAIL PROTECTED] writes: [EMAIL PROTECTED] said this stuff: After 10 years of being merely `obsolescent', head -N has finally been officially declared to be `obsolete'. I have yet to see a pointer to where the historic usage has been declared obsolete, outside of personal declarations that it has been officially declared obsolete elsewhere. head -10 was marked as obsolescent in the 1992 edition of the POSIX standard, and POSIX withdrew the requirement to support head -10 in the 2001 edition of the standard. If you don't think that makes head -10 obsolete then I guess we'll just have to agree to disagree about what the word obsolete means. People can reasonably disagree about whether it was wise for POSIX to make head -10 obsolete, and about whether it was wise of coreutils to give the coreutils installer and/or the user the ability to disable support for head -10. But those are different issues. There's no real dispute that head -10 is obsolete. If this really bugs you, then the proper way to change things back to the way they used to be is to change POSIX. You can start this process by filing a defect report with the Austin Common Standards Revision Group; see http://www.opengroup.org/austin/. Features become obsolete all the time in the GNU world. For example, GCC 3.3 removed support for unescaped newlines in C strings. This broke a few programs, but it's not really a big deal in the overall scheme of things, and there are some real advantages to sticking with the standard usage. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: conformance vs. compatibility
[EMAIL PROTECTED] (Paul Jarc) writes: I think it ought to be possible for the user building coreutils to say what version of conformance they want - say, with a ./configure argument - and this should override the unistd.h definition. That might be reasonable. The coreutils maintainer should have the final say about this, though. He's probably tired of the whole subject, though, so I suspect he won't make this change unless someone proposes a nice patch to do it. Your other arguments about whether long-option syntax like --foo is conforming are not that convincing. At any rate they were settled long ago, I suspect, when RMS proposed the current long-option syntax to conform to POSIX as a pure extension, replacing the old long-option syntax. Personally I'd rather not reopen that can of worms; life is too short! ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Optimal buffer size for copy
[EMAIL PROTECTED] writes: From an organizational standpoint, is it appropriate to re-use the lcm routine residing in od.c in the following manner? I'd put it into the lib directory, so that the code can be shared. Also, it should take and return size_t, not unsigned int. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
man/Makefile.am problem with `test ...$(all_programs)...'
I noticed this problem while building coreutils from CVS:
test echo 'spy:;@echo $(all_programs)' | MAKEFLAGS= make -s -C ../src -f Makefile -f
- spy | ../src/tr -s ' ' '\n' | LC_ALL=C sort -u | grep -v '\[' : || exit 1
/bin/sh: all_programs: command not found
While fixing this, I also noticed that the test doesn't work if the
environment variable 'missing' happens to be set to 1, and that it
exits with nonzero status if $(programs) happens to output nothing
(I assume this was to avoid a shell syntax error in for p in `$(programs)`?
I used a dummy instead in the patch below.)
2003-11-05 Paul Eggert [EMAIL PROTECTED]
* man/Makefile.am (check-programs-vs-x):
Work even if $(programs) contains '$'.
Work even if 'missing=1' in environment.
Don't report an error simply because $(programs) outputs nothing.
--- man/Makefile.am.~1.27.~ Wed Sep 10 02:26:56 2003
+++ man/Makefile.am Wed Nov 5 23:41:46 2003
@@ -160,10 +160,11 @@ programs =
\
.PHONY: check-programs-vs-x
check-programs-vs-x:
- test $(programs) : || exit 1
- for p in `$(programs)`; do \
+ status=0; \
+ for p in dummy `$(programs)`; do\
+ test $$p = dummy continue; \
test $$p = ginstall p=install || : ; \
test -f $(srcdir)/$$p.x \
- || { echo missing $$p.x 12; missing=1; }; \
+ || { echo missing $$p.x 12; status=1; }; \
done; \
- test $$missing = 1 exit 1 || :
+ exit $$status
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
cut.c patch for unsigned overflow problems with sizes, etc.
I went through cut.c and found some problems on hosts where size_t is
wider than int. While I was at it, I fixed the widths of all the
integer types that I could find. Here's a proposed patch.
2003-11-05 Paul Eggert [EMAIL PROTECTED]
Fix 'cut' problems with size_t overflow and unsigned int.
More generally, resize integer variables to fit use more precisely.
* m4/jm-macros.m4 (jm_CHECK_ALL_TYPES): Check for uintptr_t.
* src/cut.c (ADD_RANGE_PAIR): Remove unnecessary parens.
(struct range_pair): Make members to be of type size_t, not unsigned.
(max_range_endpoint, eol_range_start): Now size_t, not unsigned.
(suppress_non_delimited, output_delimiter_specified,
have_read_stdin, print_kth, set_fields): Now bool, nt int.
(delim): Now unsigned char, not int.
(mark_printable_field, is_printable_field, is_range_start_index,
set_fields, set_fields, cut_bytes, cut_fields):
Use size_t, not unsigned, for field and byte counts.
(hash_int): Use uintptr_t, not unsigned, for pointers converted
to integers. This squeezes more info out of them.
(set_fields, cut_bytes, cut_fields, main):
Use bool, not int, for booleans.
(set_fields): Allocate zeroed byte array with xzalloc, not xcalloc.
Index: m4/jm-macros.m4
===
RCS file: /cvsroot/coreutils/coreutils/m4/jm-macros.m4,v
retrieving revision 1.180
diff -p -u -r1.180 jm-macros.m4
--- m4/jm-macros.m4 5 Oct 2003 11:42:11 - 1.180
+++ m4/jm-macros.m4 6 Nov 2003 08:03:50 -
@@ -256,7 +256,8 @@ AC_DEFUN([jm_CHECK_ALL_TYPES],
AC_REQUIRE([AC_TYPE_SIGNAL])
AC_REQUIRE([AC_TYPE_SIZE_T])
AC_REQUIRE([AC_TYPE_UID_T])
- AC_CHECK_TYPE(ino_t, unsigned long)
+ AC_CHECK_TYPE(ino_t, unsigned long int)
+ AC_CHECK_TYPE(uintptr_t, size_t)
gt_TYPE_SSIZE_T
Index: src/cut.c
===
RCS file: /cvsroot/coreutils/coreutils/src/cut.c,v
retrieving revision 1.107
diff -p -u -r1.107 cut.c
--- src/cut.c 4 Nov 2003 06:28:01 - 1.107
+++ src/cut.c 6 Nov 2003 08:03:52 -
@@ -58,7 +58,7 @@
{ \
if (n_rp = n_rp_allocated) \
{ \
- (rp) = x2nrealloc (rp, n_rp_allocated, sizeof (*(rp))); \
+ (rp) = x2nrealloc (rp, n_rp_allocated, sizeof *(rp));\
} \
rp[n_rp].lo = (low); \
rp[n_rp].hi = (high);\
@@ -68,8 +68,8 @@
struct range_pair
{
-unsigned int lo;
-unsigned int hi;
+size_t lo;
+size_t hi;
};
/* This buffer is used to support the semantics of the -s option
@@ -88,11 +88,11 @@ static size_t field_1_bufsize;
or degenerate range specification; this doesn't include the starting
index of right-open-ended ranges. For example, with either range spec
`2-5,9-', `2-3,5,9-' this variable would be set to 5. */
-static unsigned int max_range_endpoint;
+static size_t max_range_endpoint;
/* If nonzero, this is the index of the first field in a range that goes
to end of line. */
-static unsigned int eol_range_start;
+static size_t eol_range_start;
/* This is a bit vector.
In byte mode, which bytes to output.
@@ -120,16 +120,16 @@ char *program_name;
static enum operating_mode operating_mode;
-/* If nonzero do not output lines containing no delimeter characters.
+/* If true do not output lines containing no delimeter characters.
Otherwise, all such lines are printed. This option is valid only
with field mode. */
-static int suppress_non_delimited;
+static bool suppress_non_delimited;
/* The delimeter character for field mode. */
-static int delim;
+static unsigned char delim;
-/* Nonzero if the --output-delimiter=STRING option was specified. */
-static int output_delimiter_specified;
+/* True if the --output-delimiter=STRING option was specified. */
+static bool output_delimiter_specified;
/* The length of output_delimiter_string. */
static size_t output_delimiter_length;
@@ -138,8 +138,8 @@ static size_t output_delimiter_length;
string consisting of the input delimiter. */
static char *output_delimiter_string;
-/* Nonzero if we have ever read standard input. */
-static int have_read_stdin;
+/* True if we have ever read standard input. */
+static bool have_read_stdin;
#define HT_RANGE_START_INDEX_INITIAL_CAPACITY 31
@@ -225,14 +225,14 @@ With no FILE, or when FILE is -, read st
}
static inline void
-mark_printable_field (unsigned int i)
+mark_printable_field (size_t i)
{
size_t n = i / CHAR_BIT;
printable_field[n] |= (1 (i % CHAR_BIT
Re: Optimal buffer size for copy
Sorry to be a pain, but I now remember that there's similar code in diffutils/lib/cmpbuf.c's buffer_lcm function. It attempts to yield reasonable values if buffer sizes are zero, and it does a sanity check against maximum reasonable values. This all came about because of freaky buffer sizes in various operating systems, so I expect we'd run into similar problems here. Suppose we just split out buffer_lcm into a separate module and use that? ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: sleep with LANG=de_DE@euro
Jim Meyering [EMAIL PROTECTED] writes:
Sleep should accept numbers in the locale specified by the user.
I'm dubious about this. I searched POSIX for examples of standard
programs accepting command-line options or operands containing
floating-point values, and both examples that I found (namely, awk and
printf) require that the values must be parsed in the C locale, not in
the user-specified locale.
Clearly coreutils printf is nonconforming now, since it doesn't do
that. I vote that other utilities be consistent with POSIX. Here's a
proposed patch.
2003-11-24 Paul Eggert [EMAIL PROTECTED]
Parse floating-point operands and options in the C locale.
POSIX requires this for printf, and we might as well be
consistent elsewhere.
* doc/coreutils.texi (tail invocation, printf invocation,
sleep invocation, seq invocation): Document this.
* lib/Makefile.am (libfetish_a_SOURCES): Add c-strtod.c, c-strtod.h.
* lib/c-strtod.c, lib/c-strtod.h: New files.
* lib/xstrtod.h (xstrtod): Accept an extra arg, specifying the
conversion function.
* lib/xstrtod.c (xstrtod): Likewise. All callers changed to
include c-strtod.h and use c_strtod. Don't include stdlib.h; no
longer needed.
* src/printf.c: Remove decls of strtod, strtol, strtoul; no longer
needed now that we assume C89. Include c-strtod.h.
(xstrtod): Call c_strtod, not strtod.
* lib/xnanosleep.c: Don't include xstrtod.h; it's not needed.
--- ./doc/coreutils.texi.~1.138.~ Tue Nov 11 12:42:02 2003
+++ ./doc/coreutils.texiMon Nov 24 08:43:58 2003
@@ -2229,7 +2229,8 @@ During one iteration, every specified fi
changed size.
Historical implementations of @command{tail} have required that
@var{number} be an integer. However, GNU @command{tail} accepts
-an arbitrary floating point number.
+an arbitrary floating point number (using a period before any
+fractional digits).
@itemx [EMAIL PROTECTED]
@opindex --pid
@@ -8590,6 +8591,13 @@ directives and @samp{\} escapes in the s
function. The @var{format} argument is re-used as necessary to convert
all of the given @var{argument}s.
[EMAIL PROTECTED] LC_NUMERIC
+A floating-point argument must use a period before any fractional
+digits, but is printed according to the LC_NUMERIC category of the
+current locale. For example, in a locale whose radix character is a
+comma, the command @samp{printf %g 3.14} outputs @samp{3,14} whereas
+the command @samp{printf %g 3,14} is an error.
+
@command{printf} has one additional directive, @samp{%b}, which prints its
argument string with @samp{\} escapes interpreted in the same way as in
the @var{format} string, except that octal escapes are of the form
@@ -11813,7 +11821,8 @@ days
Historical implementations of @command{sleep} have required that
@var{number} be an integer. However, GNU @command{sleep} accepts
-arbitrary floating point numbers.
+arbitrary floating point numbers (using a period before any fractional
+digits).
The only options are @option{--help} and @option{--version}. @xref{Common
options}.
@@ -11884,8 +11893,8 @@ seq [EMAIL PROTECTED]@dots{} [EMAIL PROTECTED] [
@command{seq} prints the numbers from @var{first} to @var{last} by
@var{increment}. By default, @var{first} and @var{increment} are both 1,
-and each number is printed on its own line. All numbers can be reals,
-not just integers.
+and each number is printed on its own line. Any floating-point number
+may be specified (using a period before any fractional digits).
The program accepts the following options. Also see @ref{Common options}.
--- ./lib/Makefile.am.~1.175.~ Sun Nov 9 21:16:01 2003
+++ ./lib/Makefile.am Mon Nov 24 08:16:06 2003
@@ -42,6 +42,7 @@ libfetish_a_SOURCES = \
argmatch.c argmatch.h \
backupfile.c backupfile.h \
basename.c \
+ c-strtod.c c-strtod.h \
canon-host.c \
canonicalize.h \
closeout.c closeout.h \
--- /dev/null Tue Mar 18 21:55:57 2003
+++ lib/c-strtod.h Mon Nov 24 08:15:24 2003
@@ -0,0 +1 @@
+double c_strtod (char const *, char **);
--- /dev/null Tue Mar 18 21:55:57 2003
+++ lib/c-strtod.c Mon Nov 24 08:14:58 2003
@@ -0,0 +1,34 @@
+/* Convert string to double, using the C locale.
+
+ Copyright (C) 2003 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 License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software Foundation
Re: sleep with LANG=de_DE@euro
Jim Meyering [EMAIL PROTECTED] writes:
Wouldn't it be better (in case xstrtod is called with a
modified LC_NUMERIC locale) if c_strtod restored the original
setting for LC_NUMERIC, rather than the environment-derived one?
I was lazy and assumed that c_strtod would be called
only in environments where LC_NUMERIC was set from the
environment.
--- lib/c-strtod.c27 Nov 2003 07:46:01 - 1.1
+++ lib/c-strtod.c27 Nov 2003 08:31:30 -
@@ -27,8 +27,9 @@ double
c_strtod (char const *nptr, char **endptr)
{
double r;
+ char const *saved_locale = setlocale (LC_NUMERIC, NULL);
setlocale (LC_NUMERIC, C);
This isn't right, since the second setlocale can overwrite the storage
addressed by saved_locale.
r = strtod (nptr, endptr);
- setlocale (LC_NUMERIC, );
+ setlocale (LC_NUMERIC, saved_locale);
saved_locale might be null.
Maybe this instead?
double r;
char *saved_locale = setlocale (LC_NUMERIC, NULL);
if (saved_locale)
{
saved_locale = xstrdup (saved_locale);
setlocale (LC_NUMERIC, C);
}
r = strtod (nptr, endptr);
if (saved_locale)
{
setlocale (LC_NUMERIC, saved_locale);
free (saved_locale);
}
return r;
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Badly formatted 'ls -l'
Leah [EMAIL PROTECTED] writes:
`ls -l` sometimes incorrectly formats output due to naively assuming
file sizes cannot be larger than 8 digits. The following patch corrects
this.
Thanks for your bug report. That patch uncovers a few more problems
in 'ls' with column widths (including some potential buffer overruns,
sigh). Rather than fix the problems piecemeal, how about if we adjust
'ls' so that it adjusts all the column widths to fit the data, not
just the file sizes? Here's a proposed patch, relative to CVS
coreutils.
2003-12-03 Paul Eggert [EMAIL PROTECTED]
* NEWS: ls -l (and similar options) now adjust all columns to
fit the data. Generalized from a suggestion by Leah Q for file sizes.
* doc/coreutils.texi (What information is listed, chroot
invocation): Adjust example 'ls' output to match new behavior
with narrower output columns.
(The cut command): Remove example that cut the output of
'ls -l'. The output was incorrect even with the old 'ls',
and the whole idea of using 'cut' on 'ls -l' output is bogus
anyway.
* src/ls.c (INODE_DIGITS, LOGIN_NAME_MAX, ID_LENGTH_MAX): Remove.
(format_user_width, format_group_width, unsigned_file_size,
format_group): New functions.
(block_size_width): Renamed from block_size_size.
(inode_number_width, nlink_width, owner_width, group_width,
author_width, major_device_number_width, minor_device_number_width,
file_size_width): New vars.
(clear_files): Initialize them.
(gobble_file): Set them. Don't ceiling block_size_width to 7.
(print_long_file): Use them.
(gobble_file): Use a new local variable 'f' to make the code
smaller and more consistent with other functions.
(format_user): Output to stdout, not to a buffer, so that we
don't have to worry about buffer overrun. Update dired_pos.
(print_long_file): Don't put owner, group, author into buffer;
just print them directly. Don't assume link counts and
major and minor numbers fit into unsigned long int.
* tests/cp/same-file, tests/mv/part-symlink: Don't assume that
'ls' output is fixed-width.
Index: NEWS
===
RCS file: /cvsroot/coreutils/coreutils/NEWS,v
retrieving revision 1.149
diff -p -u -r1.149 NEWS
--- NEWS27 Nov 2003 08:18:45 - 1.149
+++ NEWS3 Dec 2003 09:28:23 -
@@ -29,6 +29,13 @@ GNU coreutils NEWS
(--dereference-args, aka -D) rather then the current meaning of --si.
Now, using -H elicits a warning to that effect.
+ When given -l and similar options, ls now adjusts the output column
+ widths to fit the data, so that output lines are shorter and have
+ columns that line up better. This may adversely affect shell
+ scripts that expect fixed-width columns, but such shell scripts were
+ not portable anyway, even with old GNU ls where the columns became
+ ragged when a datum was too wide.
+
** Bug fixes
printf, seq, tail, and sleep now parse floating-point operands
Index: doc/coreutils.texi
===
RCS file: /cvsroot/coreutils/coreutils/doc/coreutils.texi,v
retrieving revision 1.142
diff -p -u -r1.142 coreutils.texi
--- doc/coreutils.texi 27 Nov 2003 07:58:32 - 1.142
+++ doc/coreutils.texi 3 Dec 2003 09:29:31 -
@@ -5163,23 +5163,23 @@ $ touch a/sub/deeper/file
$ ls -gloRF --dired a
a:
total 8
- -rw-r--r--10 Nov 9 18:30 f1
- -rw-r--r--10 Nov 9 18:30 f2
- drwxr-xr-x3 4096 Nov 9 18:30 sub/
- drwxr-xr-x2 4096 Nov 9 18:30 sub2/
+ -rw-r--r-- 10 Dec 3 00:50 f1
+ -rw-r--r-- 10 Dec 3 00:50 f2
+ drwxr-xr-x 3 4096 Dec 3 00:50 sub/
+ drwxr-xr-x 2 4096 Dec 3 00:50 sub2/
a/sub:
total 4
- drwxr-xr-x2 4096 Nov 9 18:30 deeper/
+ drwxr-xr-x 2 4096 Dec 3 00:50 deeper/
a/sub/deeper:
total 0
- -rw-r--r--10 Nov 9 18:30 file
+ -rw-r--r-- 1 0 Dec 3 00:50 file
a/sub2:
total 0
-//DIRED// 55 57 98 100 141 144 186 190 252 258 327 331
-//SUBDIRED// 2 3 195 200 263 275 335 341
+//DIRED// 49 51 86 88 123 126 162 166 222 228 288 292
+//SUBDIRED// 2 3 171 176 233 245 296 302
//DIRED-OPTIONS// --quoting-style=literal
@end example
@@ -5190,11 +5190,11 @@ The offsets on the @samp{//SUBDIRED//} l
directory names: @file{a}, @file{a/sub}, @file{a/sub/deeper}, @file{a/sub2}.
Here is an example of how to extract the fifth entry name, @samp{deeper},
-corresponding to the pair of offsets, 252 and 258:
+corresponding to the pair of offsets, 222 and 228:
@example
$ ls -gloRF --dired a out
-$ dd bs=1 skip=252 count=6 out 2/dev/null; echo
+$ dd bs=1 skip=222 count=6 out 2/dev/null; echo
deeper
@end example
@@ -5208,8 +5208,8 @@ on a file whose name contains special ch
Re: [coreutils]/lib/getgroups.c, xmalloc usage...
Alfred M. Szmidt [EMAIL PROTECTED] writes: gbuf = xmalloc (gbuf, n * sizeof *gbuf); Thanks for reporting that. I installed the following patch into gnulib. This code is fairly new and gets compiled only for ancient hosts, which explains why nobody else has run into the problem yet. 2003-12-03 Paul Eggert [EMAIL PROTECTED] * getgroups.c (getgroups): xmalloc takes one argument, not two. Bug reported by Alfred M. Szmidt. Index: getgroups.c === RCS file: /cvsroot/gnulib/gnulib/lib/getgroups.c,v retrieving revision 1.9 retrieving revision 1.10 diff -p -u -r1.9 -r1.10 --- getgroups.c 29 Oct 2003 17:27:58 - 1.9 +++ getgroups.c 3 Dec 2003 10:17:42 - 1.10 @@ -48,7 +48,7 @@ getgroups (int n, GETGROUPS_T *group) /* No need to worry about address arithmetic overflow here, since the ancient systems that we're running on have low limits on the number of secondary groups. */ - gbuf = xmalloc (gbuf, n * sizeof *gbuf); + gbuf = xmalloc (n * sizeof *gbuf); n_groups = getgroups (n, gbuf); if (n_groups n) break; ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup.out placement so inflexible
Jim Meyering [EMAIL PROTECTED] writes: Please call the new option --output=FILE (no short-named option). If you do this, please also update the documentation: I see one detail here that needs to be nailed down. One might think that the user could easily implement the equivalent of: nohup --output=FILE COMMAND by executing: nohup COMMAND FILE However, these two commands should have different effects when FILE is a terminal: the former should send all output to FILE, whereas POSIX requires that the latter must send all output to 'nohup.out' instead. So, I suggest that the documentation and code make it clear that the --output=FILE output means something more than use the name FILE rather than the name 'nohup.out'. The option also means send the output to FILE regardless of whether FILE is a terminal. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: touch v5.00
Michael Rasmussen [EMAIL PROTECTED] writes: The -b option is missing. ?? Still present in v4.5.3 What is touch -b supposed to do? It's not in the standard; see: http://www.opengroup.org/onlinepubs/007904975/utilities/touch.html ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: -n (number)
Stephen Newman [EMAIL PROTECTED] writes: For years the option on tail was tail -number, now all of a sudden it's tail -n (number) is this a bug, if not why was it changed? This is covered in the coreutils manual; look for _POSIX2_VERSION. Perhaps your distribution provider changed the version of POSIX that they conform to? For more details, please see the following threads: http://mail.gnu.org/archive/html/bug-coreutils/2003-09/msg00087.html http://mail.gnu.org/archive/html/bug-coreutils/2003-11/msg00028.html ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: uniq: an option is missin in the info file
Gianni Ciolli [EMAIL PROTECTED] writes: The output of $ uniq --help contains the line -W, --check-fields=N compare no more than N fields in lines This isn't true of the latest coreutils release. Perhaps you have a version of uniq that is modified in your GNU/Linux distribution? If so, you should report a bug against that distribution. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: patch for 'df', --total from TODO
Chris Van Nuys [EMAIL PROTECTED] writes:
An example of the output (of course, it all lines up in the Unix
shell, doesn't paste well into Eudora though):
This seems to be a problem with your patch as well. Can you please
send your patches using a mechanism that doesn't mess up tabs or white
space? Perhaps you'll need to attach them, though it'd be better if
you can send them inline.
Here are some comments about the patch that you sent:
+/* Prints the total kilo, avail, and used, if --total is used */
+char *print_total[1024];
This should be a char buffer, not a char * buffer; I'm surprised the
patched code compiled without diagnostics (did it?). Also, there
shouldn't be an arbitrary limit on the length of the total line; the
code should still work even if the pathname is length 2000, for
example.
+ if (calculate_total)
+{
+ total_used += used;
+ total_kbytes += total;
+ total_available += available;
This doesn't sound right, as used, total, and available have
different units when they are used with different filesystems. One
can't simply add them up. The patch that you sent incorrectly assumes
that all filesystems use the same units.
SYNC_OPTION = CHAR_MAX + 1,
- NO_SYNC_OPTION
+ NO_SYNC_OPTION,
+ CALC_TOTAL
};
This should be TOTAL_OPTION, not CALC_TOTAL, for consistency with the
other enum names.
Also, the files doc/coreutils.texi and NEWS would need patches.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] fix coreutils-5.0.91 rejecting [ toto -eq tata ] like forms
Thierry Vignaud [EMAIL PROTECTED] writes: # unpatched coreutils-5.0.91: $ perl -e 'system(/usr/bin/[, 1, =, 1, ])' /usr/bin/[: too many arguments I don't get that behavior with unpatched coreutils 5.1.0; please see the transcript below. One theory is that your packaging somehow created a hard or symbolic link from /usr/bin/[ to /usr/bin/test. Such a link used to be valid with coreutils, but it is valid no longer, since [ and test now separate executables with different behaviors. This is to conform to the GNU coding standards, which say that an executable's behavior should not depend on its name. To test this theory, can you please send the output of the command (cd /usr/bin ls -li '[' test) to bug-coreutils? Thanks. Here's the transcript that I mentioned: $ perl -e 'system(/home/eggert/opt/Linux-2.4.18-bf2.4-unknown/merged/bin/[, 1, =, 1, ])' $ perl -e 'system(/home/eggert/opt/Linux-2.4.18-bf2.4-unknown/merged/bin/test, 1, =, 1, ])' /home/eggert/opt/Linux-2.4.18-bf2.4-unknown/merged/bin/test: too many arguments $ (cd /home/eggert/opt/Linux-2.4.18-bf2.4-unknown/merged/bin ls -li '[' test) 2507466 -r-xr-xr-x 2 eggert eggert 98583 2003-12-23 12:25 [ 2507539 -r-xr-xr-x 2 eggert eggert 86928 2003-12-23 12:25 test ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: readlink -f foo fails if the target of foo does not exist
Jim Meyering [EMAIL PROTECTED] writes: So here's a better spec: If canonicalize_file_name (FILE) succeeds, work exactly as now. else if lstat (FILE) succeeds, linkname = readlink (FILE) if linkname starts with `/', print linkname otherwise, print $(readlink -f $(dirname FILE))/linkname else, work exactly as now. Hmm, the above algorithm doesn't canonicalize linkname. If linkname contains . or .. components, shouldn't they be canonicalized out? For example, linkname might be ../bar, and if so the above algorithm would print /a/b/c/../bar when it should print /a/b/bar. Another possibility is that linkname could refer to symbolic links. For example, if linkname is s/x where s is a symbolic link to /, and /x does not exist, then you should print /x, not /a/b/c/s/x. Canonicalizing linkname as described above would result in a different file name FILE1 which couldn't be printed immediately, since it you would then have to fed back into the above algorithm. Unless the file system was mutating under you, presumably canonicalize_file_name (FILE1) would fail for the same reason that canonicalize_file_name (FILE) failed. However, lstat (FILE1) might succeed, or might fail. If it fails, you're done: if it succeeds and if readlink (FILE1) gives you an absolute link, you're done as well; but if readlink (FILE1) gives you a relative link, you have to construct a new name FILE2 and start over again. So this whole process might loop. Ouch! My head is spinning. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] cp --update --preserve
Paolo Montrasio [EMAIL PROTECTED] writes: Paul's suggestion can be modified in this way: 1) read the timestamp of the existing destination file (if it doesn't exist yet we don't have any problem and we can resume normal processing) 2) write the current time to destination file's atime 3) find out how many significative digits there are in atime 4) restore the original timestamp 5) perform the check according to the number of significative digits Yes, that's pretty much what I thought I was suggesting. All these steps need to be done only if the time stamps are slightly out of sync. If the source's time stamp is S and the destination's is T, then 'cp' needs to do the above steps only if (S - (S mod 2) = T T S), where by mod here I mean real-number modulo. The 2 is because some DOSish file systems have a time stamp resolution of only 2 seconds, and all other time stamp resolutions that I know of are equal to 2 seconds divided by some integer. Step (2) should use a time with an odd number of seconds and with nanoseconds = 9; that way, you're guaranteed to find out the correct resolution of any file system that I know about. It's simple enough to take the current time, subtract 1 second, then OR in 1 second, then set the nanoseconds field to 9; this will give a time in the recent past that has the properties we want. Step (4) cannot always be done: the original time stamp may have nanosecond resolution, but we can't restore it. This is why I was proposing doing it to a little test file instead. However, on further thought, you're right that the atime doesn't really matter all that much, so it's OK to just use the destination file as a guinea pig whose time stamp can be futzed with temporarily a bit. The further optimization I mentioned, is that you don't have to do any of this stuff if you've already computed the time stamp resolution for the destination file system. The smaller the resolution, the higher the chances are that you get some 0 in the least significative digits of the timestamp. For instance, if you have full nanoseconds resolution, the program will believe in the 10% of cases that you have a resolution of 10 nanoseconds. Not if you use nanoseconds==9 as I suggested above. That should handle all of the cases correctly. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
possible patch for coreutils 5.1.1 failure on OSF 3.2C
Christian Krackowizer [EMAIL PROTECTED] writes: OSF 3.2C fails: out exp differ: char 13, line 1 1c1 2004-01-16T05:56:38 --- 2004-01-16T04:56:38 FAIL: relative Most likely this is due to a bug in the new test script, as it uses a nonportable TZ setting. I also noticed it uses a time zone indication that isn't documented as being supported. Here's an untested patch. 2004-01-19 Paul Eggert [EMAIL PROTECTED] * tests/touch/relative: Use TZ=UTC0, not TZ=utc (which isn't portable). Problem reported by Christian Krackowizer. Also, use + rather than +0 to specify a time zone, as the documentation requires four digits. Index: relative === RCS file: /home/meyering/coreutils/cu/tests/touch/relative,v retrieving revision 1.1 diff -p -u -r1.1 relative --- relative16 Jan 2004 14:46:37 - 1.1 +++ relative19 Jan 2004 18:57:23 - @@ -17,7 +17,7 @@ trap '(exit $?); exit $?' 1 2 13 15 framework_failure=0 mkdir -p $tmp || framework_failure=1 cd $tmp || framework_failure=1 -touch --date='2004-01-16 05:26:38 +0' f || framework_failure=1 +touch --date='2004-01-16 05:26:38 +' f || framework_failure=1 if test $framework_failure = 1; then echo $0: failure in testing framework 12 @@ -29,7 +29,7 @@ fail=0 # Set times back by 30 minutes. touch --ref f --date='-30 min' f || fail=1 -TZ=utc command ls -og --time-style=+%Y-%m-%dT%H:%M:%S f out.1 || fail +TZ=UTC0 command ls -og --time-style=+%Y-%m-%dT%H:%M:%S f out.1 || fail sed 's/ f$//;s/.* //' out.1 out rm -f out.1 ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: tail question
Warren L Dodge [EMAIL PROTECTED] writes: On the two solaris systems the following command works. tail -1 file On linux is complains and says to use tail -n 1 file Any idea what caused this? It's because your GNU/Linux systems have unistd.h that claim conformance to POSIX 1003.1-2001, whereas your Solaris systems claim conformance to POSIX 1003.2-1992. The new POSIX standard disallows support for tail -1 and head -1 (even as extensions!). [EMAIL PROTECTED] (Bob Proulx) writes: You mean on solaris using which set of utilities? My understanding is that you now have three to choose from there. /usr/bin/tail /usr/xpg4/bin/tail /usr/local/bin/tail # Wherever you installed the GNU version. There's also /opt/sfw/bin/gtail on Solaris 8, with the companion CD installed. (Isn't Solaris wonderful? They have everything! :-) export _POSIX2_VERSION=199209 This will work for coreutils, but it might not work for other implementations that conform to POSIX 1003.1-2001. If the original poster wantes his scripts to be portable among both new and old systems, his best bet is stick to the compatible intersection of POSIX and widely-used platforms. Thus, he can replace tail -1 with sed -n '$p', and replace head -1 with sed 1q. Admittedly this is a hassle in the short run, so setting _POSIX2_VERSION=199209 may be his best bet in the short run. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: possible patch for coreutils 5.1.1 failure on OSF 3.2C
[EMAIL PROTECTED] (Paul Jarc) writes: Paul Eggert [EMAIL PROTECTED] wrote: + * tests/touch/relative: For 'ls' use TZ=UTC0, not TZ=utc (which isn't + portable). OOC, is TZ=UTC portable? TZ=UTC is not portable, but TZ=UTC0 has been standardized by POSIX for many years, and is portable to most pre-POSIX hosts. Here's the current standard in this area: http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html#tag_08_03 Some of the TZ stuff is new in the 2001 edition (e.g., 'zone' for internationalization), but the TZ=UTC0 part has been there since the late 1980s I think. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: tail question
[EMAIL PROTECTED] (Paul Jarc) writes: This is unclear to me. It sounds like what you mean is that the *spec* change predates 4.5.1, but the actually-exhibited *behavior* change is only a few months old. Is that right? I meant that the coreutils code itself introduced these changes before 4.5.1. The actually-exhibited behavior therefore changed before then. I've been using the new behavior for a couple of years myself, as the default way that I use the standard utilities, because I set _POSIX2_VERSION=200112 in my environment. The only thing that's changed recently is the choice of the default behavior if neither the installer nor the user specifies a preference. In this case, coreutils looks at unistd.h's _POSIX2_VERSION to determine the system default. Some implementations have recently claimed (typically incorrectly, I guess) to conform to the POSIX 1003.1-2001 standard for utilities and have therefore set unistd.h's _POSIX2_VERSION to 200112L. The coreutils build process by default takes them at their word. I typically use the latest Debian stable distribution (3.0r1). It doesn't have this problem since its unistd.h says that _POSIX2_VERSION is 199209L, which corresponds to POSIX 1003.2-1992. But I gather that other, more bleeding-edge distributions claim conformance to the newer POSIX standard. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: exit status patch for coreutils
Bernard Giroud [EMAIL PROTECTED] writes: Does POSIX specify all exit codes that might be returned from utilities ? It specifies them in some cases, but not all. For example, for diff 0 means success, 1 means differences, 1 means error. For env 0 means success, 127 means not found, 126 means not invokable, and 1-125 means some other error. There are other weird cases like that. Have you a pointer to the POSIX docs ? http://www.unix.org/single_unix_specification/ Might it be possible to use a scheme like values greater than 63 are warnings else errors...? I suspect that'd be difficult to achieve. It sounds simpler to put a wrapper between exit/_exit and the VMS exit. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 5.1.0 compile failure on Tru64 5.1b
(This is following up on
http://mail.gnu.org/archive/html/bug-coreutils/2004-01/msg00156.html.)
Tim Mooney [EMAIL PROTECTED] writes:
Are there platforms where including both inttypes.h and stdint.h, if both
are available, cause a clash?
I dimly recall some, but this should no longer be a problem now that
autoconf tests the include files serially. That is, it no longer
defines HAVE_STDINT_H if inttypes.h works and the combination of
inttypes.h followed by stdint.h does not work.
Fixing this requires fixing Autoconf, gnulib, coreutils, and probably
other platforms. I've started the ball rolling by installing the
following into Autoconf.
2004-01-26 Paul Eggert [EMAIL PROTECTED]
* doc/autoconf.texi (Default Includes): Include stdint.h even if
HAVE_INTTYPES_H is defined. This is needed on Tru64 5.1b with
Compac C V6.5-207 (dtk), which defines uintmax_t in stdint.h but
not inttypes.h. Problem reported by Tim Mooney in
http://mail.gnu.org/archive/html/bug-coreutils/2004-01/msg00147.html.
* lib/autoconf/headers.m4 (_AC_INCLUDES_DEFAULT_REQUIREMENTS):
Likewise.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.795
diff -p -u -r1.795 autoconf.texi
--- doc/autoconf.texi 23 Jan 2004 08:21:51 - 1.795
+++ doc/autoconf.texi 26 Jan 2004 23:25:42 -
@@ -3184,10 +3184,9 @@ Expand to @var{include-directives} if de
#endif
#if HAVE_INTTYPES_H
# include inttypes.h
-#else
-# if HAVE_STDINT_H
-# include stdint.h
-# endif
+#endif
+#if HAVE_STDINT_H
+# include stdint.h
#endif
#if HAVE_UNISTD_H
# include unistd.h
Index: lib/autoconf/headers.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/headers.m4,v
retrieving revision 1.36
diff -p -u -r1.36 headers.m4
--- lib/autoconf/headers.m4 24 Nov 2003 10:40:59 - 1.36
+++ lib/autoconf/headers.m4 26 Jan 2004 23:25:45 -
@@ -1,7 +1,7 @@
# This file is part of Autoconf. -*- Autoconf -*-
# Checking for headers.
#
-# Copyright (C) 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
+# Copyright (C) 2000, 2001, 2002, 2003, 2004 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 License as published by
@@ -250,10 +250,9 @@ ac_includes_default=\
#endif
#if HAVE_INTTYPES_H
# include inttypes.h
-#else
-# if HAVE_STDINT_H
-# include stdint.h
-# endif
+#endif
+#if HAVE_STDINT_H
+# include stdint.h
#endif
#if HAVE_UNISTD_H
# include unistd.h
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-5.1.2 and the stat command
Nelson H. F. Beebe [EMAIL PROTECTED] writes:
I suspect that the omission of the nanoseconds values in the
timestamps reported by GNU stat is simply an oversight that can be
easily rectified, and should be.
Thanks for reporting that. The following patch works for me on Solaris 8.
2004-01-31 Paul Eggert [EMAIL PROTECTED]
* src/stat.c: Include timespec.h.
(human_time): Accept nanoseconds arg. Also, accept time
rather than pointer-to-const-time, for clarity. All callers changed.
(print_stat): Pass nanoseconds arg to human_time.
Problem reported by Nelson H. F. Beebe.
Index: stat.c
===
RCS file: /home/meyering/coreutils/cu/src/stat.c,v
retrieving revision 1.61
diff -p -u -r1.61 stat.c
--- stat.c 21 Jan 2004 23:45:21 - 1.61
+++ stat.c 1 Feb 2004 07:21:28 -
@@ -52,6 +52,7 @@
#include quote.h
#include quotearg.h
#include strftime.h
+#include timespec.h
#include xreadlink.h
#define NAMEMAX_FORMAT PRIuMAX
@@ -326,16 +327,16 @@ human_access (struct stat const *statbuf
}
static char *
-human_time (time_t const *t)
+human_time (time_t t, int ns)
{
static char str[80];
- struct tm *tm = localtime (t);
+ struct tm *tm = localtime (t);
if (tm == NULL)
{
G_fail = 1;
return (char *) _(*** invalid date/time ***);
}
- nstrftime (str, sizeof str, %Y-%m-%d %H:%M:%S.%N %z, tm, 0, 0);
+ nstrftime (str, sizeof str, %Y-%m-%d %H:%M:%S.%N %z, tm, 0, ns);
return str;
}
@@ -525,7 +526,8 @@ print_stat (char *pformat, char m, char
break;
case 'x':
strcat (pformat, s);
- printf (pformat, human_time ((statbuf-st_atime)));
+ printf (pformat, human_time (statbuf-st_atime,
+ TIMESPEC_NS (statbuf-st_atim)));
break;
case 'X':
strcat (pformat, d);
@@ -533,7 +535,8 @@ print_stat (char *pformat, char m, char
break;
case 'y':
strcat (pformat, s);
- printf (pformat, human_time ((statbuf-st_mtime)));
+ printf (pformat, human_time (statbuf-st_mtime,
+ TIMESPEC_NS (statbuf-st_mtim)));
break;
case 'Y':
strcat (pformat, d);
@@ -541,7 +544,8 @@ print_stat (char *pformat, char m, char
break;
case 'z':
strcat (pformat, s);
- printf (pformat, human_time ((statbuf-st_ctime)));
+ printf (pformat, human_time (statbuf-st_ctime,
+ TIMESPEC_NS (statbuf-st_ctim)));
break;
case 'Z':
strcat (pformat, d);
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Error in libfetish.a
John D. Ballentine III [EMAIL PROTECTED] writes: the HP make failed with yet another interesting series of messages: -g -O2 -c `test -f 'human.c' || echo './'`human.c human.c: In function `adjust_value': human.c:111: parse error before `l' This is strange, since there isn't an identifier 'l' in line 111 of coreutils 5.0's lib/human.c file. I suspect a macro-expansion problem. What are the values of HAVE_INTTYPES_H, HAVE_STDINT_H, and uintmax_t in your config.h? Do your inttypes.h and/or stdint.h include files define uintmax_t and/or UINTMAX_MAX? If so, what values are they defined to? Do you have the same problem when you build the latest coreutils alpha? It has some fixes relevant to HP-UX, and may sidestep the problems you're having. You can find it at: ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.1.2.tar.gz ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: wc v. 4.5.3
Jeff Martens [EMAIL PROTECTED] writes: wc: /mnt/floppy/teaching.pdf:2447: Invalid or incomplete multibyte or wide character I think this bug is fixed in the latest coreutils ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.1.2.tar.gz; if not, please let us know the details. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: [Bug-gnulib] quotearg styles (documentation patch for coreutils)
Bruno Haible [EMAIL PROTECTED] writes:
Can you improve the wording here and in coreutils simultaneously?
OK, but let's start with coreutils since it's the user documentation
and is more visible. Once this is done the gnulib patch should be
straightforward.
in the default C locale
But the code does it differently: It uses quotes `like this' also if not
in the C locale and the two strings ` ' are not translated in the message
catalog.
Surely that is an implementation detail that is unimportant to the
user. From the user's point of view, if the strings are not
translated, that's the same as saying that ` and ' are appropriate
for the locale.
Here's the proposed patch to the coreutils documentation, which
reflects your other comments:
2004-02-09 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (Formatting the file names):
Improve wording for --quoting-style documentation.
Suggestions by Bruno Haible.
Index: coreutils.texi
===
RCS file: /home/meyering/coreutils/cu/doc/coreutils.texi,v
retrieving revision 1.153
diff -p -u -r1.153 coreutils.texi
--- coreutils.texi 2 Feb 2004 13:20:52 - 1.153
+++ coreutils.texi 9 Feb 2004 20:47:23 -
@@ -5922,29 +5922,39 @@ in C.
@item [EMAIL PROTECTED]
@opindex --quoting-style
@cindex quoting style
-Use style @var{word} to quote output names. The @var{word} should
+Use style @var{word} to quote names. The quoting-style algorithm
+takes a file name as input, and outputs a quoted version of the input
+name. The @var{word} should
be one of the following:
@table @samp
@item literal
-Output names as-is; this is the same as the @option{-N} or
+Output as-is; this is the same as the @option{-N} or
@option{--literal} option.
@item shell
-Quote names for the shell if they contain shell metacharacters or would
+Quote for the shell if the input contains shell metacharacters or would
cause ambiguous output.
+The quoting is suitable for @acronym{POSIX}-compatible shells like
[EMAIL PROTECTED], but it does not always work for incompatible shells
+like @command{csh}.
@item shell-always
-Quote names for the shell, even if they would normally not require quoting.
+Quote for the shell, even if the input would normally not require
+quoting.
@item c
-Quote names as for a C language string; this is the same as the
+Output a C character string literal, including the surrounding
+double-quote characters; this is the same as the
@option{-Q} or @option{--quote-name} option.
@item escape
-Quote as with @samp{c} except omit the surrounding double-quote
+Output a C character string literal, except omit the
+surrounding double-quote
characters; this is the same as the @option{-b} or @option{--escape} option.
@item clocale
-Quote as with @samp{c} except use quotation marks appropriate for the
-locale.
+Output a C character string literal, except use surrounding quotation
+marks appropriate for the locale.
@item locale
@c Use @t instead of @samp to avoid duplicate quoting in some output styles.
-Like @samp{clocale}, but quote @t{`like this'} instead of @t{like
+Output a C character string literal, except use surrounding
+quotation marks appropriate for the locale, and quote @t{`like this'}
+instead of @t{like
this} in the default C locale. This looks nicer on many displays.
@end table
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: ln -sf foo symlink_to_directory
[EMAIL PROTECTED] (Paul Jarc) writes: rm --as-is foo would be equivalent to unlink foo, and I didn't suggest adding this option to rm. rm's determination of whether to treat the path as a directory is already determined entirely from the command line, from -r/-R. Not exactly: if foo is an empty directory, rm -r foo calls rmdir (foo), whereas rm --as-is foo would call unlink (foo) and then would fail on most modern hosts. But I tend to prefer adding a flag to the existing commands. But I prefer Bruno's suggestion of adding a flag to the existing commands. Eh? An editing error on my part. Sorry. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: df du should honor $BLOCKSIZE
[EMAIL PROTECTED] (Peter Seebach) writes: BLOCKSIZEThe size of the block units used by several commands, most notably df(1), du(1) and ls(1). Can you find a complete list of BSD programs that use getbsize, and which contexts they use it in? Here's why I'd like to know the details. OpenBSD 3.2 'ls' treats BLOCKSIZE differently than coreutils-5.2.0 'ls' treats BLOCK_SIZE. The latter affects the st_size column, but the former doesn't. (See below.) So, even if we make BLOCK_SIZE default to BLOCKSIZE, the emulation won't be quite right for ls. I'm worried that there are other problems in other programs. - coreutils 5.2.0 - $ BLOCK_SIZE=512 ls -sl total 1072 1072 -rw-rw-r-- 2 eggert eggert 1045 Mar 19 2003 113277-05.zip $ BLOCK_SIZE=1024 ls -sl total 536 536 -rw-rw-r-- 2 eggert eggert 523 Mar 19 2003 113277-05.zip - OpenBSD 3.2 - $ BLOCKSIZE=512 /bin/ls -sl total 1072 1072 -rw-rw-r-- 2 eggert eggert 534737 Mar 19 2003 113277-05.zip $ BLOCKSIZE=1024 /bin/ls -sl total 536 536 -rw-rw-r-- 2 eggert eggert 534737 Mar 19 2003 113277-05.zip ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: uniq prints invalid unique lines multiple times
Reuben Thomas [EMAIL PROTECTED] writes: What I expect when I run with LANG=en_GB.UTF-8 is either for uniq to return an error (because the file is not valid text), or to print one single line (if it's being lenient). Can you please try coreutils-5.2.0? It has some patches in this area. ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.0.tar.gz If coreutils-5.2.0 is also broken for you, can you please use GDB to place a breakpoint on the xmemcoll function and see why it is not printing an error message for you? It is possible that you're seeing a bug in your C library's implementation of strcoll. If strcoll is returning a nonzero value for identical strings, and is not setting errno to indicate an encoding error exists in the strings, that would explain your symptoms. That's why I'm asking for the GDB debugging, if you still observe the bug in 5.2.0. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: chown xxx.yyy, POSIX, and LSB
Jim Meyering [EMAIL PROTECTED] writes:
If you do that, you should also adjust `chown --help' output
and coreutils.texi to describe the new default behavior.
But the practice elsewhere is to not document the old-fashioned POSIX
1003.2-1992 behavior in help strings; for example, sort --help and
tail --help don't.
As I caused this problem originally (sorry!), I looked into the POSIX
spec with tweezers and a fine-toothed comb, and I spotted an escape
hatch. Here is a simpler (and what I hope is a better) proposal: have
chown support the old syntax regardless of POSIX version of
POSIXLY_CORRECT. This conforms, is because POSIX allows the chown
user.group file behavior as an upward-compatible extension, so long
as it comes into play only where a vanilla chown would report an error
(which is what the code already does).
Here is a proposed patch.
2004-02-23 Paul Eggert [EMAIL PROTECTED]
* NEWS: Document the following.
* doc/coreutils.texi (chown invocation): Likewise.
* lib/userspec.c: Don't include posixver.h.
(parse_user_spec): Fall back on USER.GROUP parsing regardless
of POSIX version, as POSIX 1003.1-2001 allows that behavior as a
compatible extension. Simplify code by removing a boolean int
that was always nonzero if a string was nonnull.
Index: NEWS
===
RCS file: /home/meyering/coreutils/cu/NEWS,v
retrieving revision 1.178
diff -p -u -r1.178 NEWS
--- NEWS21 Feb 2004 09:26:56 - 1.178
+++ NEWS23 Feb 2004 23:02:56 -
@@ -14,6 +14,12 @@ GNU coreutils NEWS
The `|' and `' operators now use short-circuit evaluation, e.g.,
`expr 1 \| 1 / 0' no longer reports a division by zero.
+** New features
+
+ `chown user.group file' now has its traditional meaning even when
+ conforming to POSIX 1003.1-2001, so long as no user has a name
+ containing `.' that happens to equal `user.group'.
+
* Major changes in release 5.2.0 (2004-02-19) [stable]
Index: doc/coreutils.texi
===
RCS file: /home/meyering/coreutils/cu/doc/coreutils.texi,v
retrieving revision 1.161
diff -p -u -r1.161 coreutils.texi
--- doc/coreutils.texi 22 Feb 2004 15:44:32 - 1.161
+++ doc/coreutils.texi 23 Feb 2004 23:05:15 -
@@ -7712,11 +7712,13 @@ is omitted, only the group of the files
@end table
Some older scripts may still use @samp{.} in place of the @samp{:} separator.
[EMAIL PROTECTED] 1003.1-2001 (@pxref{Standards conformance}) does not allow that,
-but you may be able to work around the compatibility problems by setting
[EMAIL PROTECTED] in your environment.
-New scripts should avoid the use of @samp{.} because @sc{gnu} @command{chown}
-may fail if @var{owner} contains @samp{.} characters.
[EMAIL PROTECTED] 1003.1-2001 (@pxref{Standards conformance}) does not
+require support for that, but for backward compatibility @acronym{GNU}
[EMAIL PROTECTED] supports @samp{.} so long as no ambiguity results.
+New scripts should avoid the use of @samp{.} because it is not
+portable, and because it has undesirable results if the entire
[EMAIL PROTECTED]@samp{.}group} happens to identify a user whose name
+contains @samp{.}.
Warning: The @command{chown} command may clear the set-user-ID or
set-group-ID bits on some systems. The @command{chown} command is
Index: lib/userspec.c
===
RCS file: /home/meyering/coreutils/cu/lib/userspec.c,v
retrieving revision 1.39
diff -p -u -r1.39 userspec.c
--- lib/userspec.c 3 Nov 2003 14:57:41 - 1.39
+++ lib/userspec.c 23 Feb 2004 21:34:10 -
@@ -42,7 +42,6 @@
#endif
#include userspec.h
-#include posixver.h
#include xalloc.h
#include xstrtol.h
@@ -158,7 +157,6 @@ parse_user_spec (const char *spec_arg, u
struct group *grp;
char *g, *u, *separator;
char *groupname;
- int maybe_retry = 0;
char *dot = NULL;
error_msg = NULL;
@@ -171,17 +169,14 @@ parse_user_spec (const char *spec_arg, u
separator = strchr (spec, ':');
/* If there is no colon, then see if there's a `.'. */
- if (separator == NULL posix2_version () 200112)
+ if (separator == NULL)
{
dot = strchr (spec, '.');
/* If there's no colon but there is a `.', then first look up the
whole spec, in case it's an OWNER name that includes a dot.
If that fails, then we'll try again, but interpreting the `.'
-as a separator. */
- /* FIXME: accepting `.' as the separator is contrary to POSIX.
-someday we should drop support for this. */
- if (dot)
- maybe_retry = 1;
+as a separator. This is a compatible extension to POSIX, since
+the POSIX-required behavior is always tried first. */
}
retry:
@@ -311,10 +306,10 @@ parse_user_spec (const char *spec_arg, u
make check failures if BLOCK_SIZE is set in the environment
I ran into some make check failures when I set BLOCK_SIZE in my environment before running the coreutils tests. Here's a patch. 2004-02-25 Paul Eggert [EMAIL PROTECTED] * tests/du/deref-args, tests/du/exclude, tests/du/slash, tests/du/trailing-slash: Run envvar-check in case BLOCK_SIZE etc. are set. Index: tests/du/deref-args === RCS file: /home/meyering/coreutils/cu/tests/du/deref-args,v retrieving revision 1.3 diff -p -u -r1.3 deref-args --- tests/du/deref-args 18 Oct 2003 13:09:45 - 1.3 +++ tests/du/deref-args 25 Feb 2004 18:07:39 - @@ -7,6 +7,8 @@ if test $VERBOSE = yes; then du --version fi +. $srcdir/../envvar-check + pwd=`pwd` t0=`echo $0|sed 's,.*/,,'`.tmp; tmp=$t0/$$ trap 'status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 exit $status' 0 Index: tests/du/exclude === RCS file: /home/meyering/coreutils/cu/tests/du/exclude,v retrieving revision 1.4 diff -p -u -r1.4 exclude --- tests/du/exclude5 Feb 2003 14:29:59 - 1.4 +++ tests/du/exclude25 Feb 2004 18:08:14 - @@ -6,6 +6,8 @@ if test $VERBOSE = yes; then du --version fi +. $srcdir/../envvar-check + pwd=`pwd` t0=`echo $0|sed 's,.*/,,'`.tmp; tmp=$t0/$$ trap 'status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 exit $status' 0 Index: tests/du/slash === RCS file: /home/meyering/coreutils/cu/tests/du/slash,v retrieving revision 1.1 diff -p -u -r1.1 slash --- tests/du/slash 9 Jul 2003 09:59:58 - 1.1 +++ tests/du/slash 25 Feb 2004 18:08:07 - @@ -6,6 +6,8 @@ if test $VERBOSE = yes; then du --version fi +. $srcdir/../envvar-check + pwd=`pwd` t0=`echo $0|sed 's,.*/,,'`.tmp; tmp=$t0/$$ trap 'status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 exit $status' 0 Index: tests/du/trailing-slash === RCS file: /home/meyering/coreutils/cu/tests/du/trailing-slash,v retrieving revision 1.4 diff -p -u -r1.4 trailing-slash --- tests/du/trailing-slash 2 Oct 2003 20:29:12 - 1.4 +++ tests/du/trailing-slash 25 Feb 2004 18:08:23 - @@ -8,6 +8,8 @@ if test $VERBOSE = yes; then du --version fi +. $srcdir/../envvar-check + pwd=`pwd` t0=`echo $0|sed 's,.*/,,'`.tmp; tmp=$t0/$$ trap 'status=$?; cd $pwd; chmod -R u+rwx $t0; rm -rf $t0 exit $status' 0 ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Problem with __sys_siglist test under Tru64
Thanks for the bug report. 'configure' is generated from 'configure.ac', so I assume the following patch would be better. 2004-03-01 Paul Eggert [EMAIL PROTECTED] * configure.ac: Include signal.h when checking for strsignal, sys_siglist, and friends. Problem reported by Toney Leneis in http://mail.gnu.org/archive/html/bug-coreutils/2004-02/msg00136.html. Index: configure.ac === RCS file: /home/meyering/coreutils/cu/configure.ac,v retrieving revision 1.46 diff -p -u -r1.46 configure.ac --- configure.ac22 Feb 2004 14:57:52 - 1.46 +++ configure.ac1 Mar 2004 21:31:33 - @@ -225,7 +225,10 @@ if test $jm_cv_sys_tiocgwinsz_needs_term fi # For src/kill.c. -AC_CHECK_DECLS([strsignal, strtoimax, sys_siglist, _sys_siglist, __sys_siglist]) +AC_CHECK_DECLS([strtoimax]) +AC_CHECK_DECLS([strsignal, sys_siglist, _sys_siglist, __sys_siglist], , , + [AC_INCLUDES_DEFAULT +#include signal.h]) jm_LIB_CHECK ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: numeric sort gives incorrect result with comparing different formatted floating point numbers
Simon Oosthoek [EMAIL PROTECTED] writes: When sorting the data below (which is already sorted by sort) using sort -n which should numerically sort on the first column (equiv to sort -n -k 1) gives inconsistent output w.r.t numbers with missing digits. I don't get the same results that you do. When I use sort -n, all the output comes in the expected order. I do get the same output that you do if I specify plain sort without -n. Perhaps your sort wasn't being invoked as you expected? This output is derived from ns-2 simulator output, which outputs floating point numbers in a variety of ways (including exponential formatting) Then you should use -g instead of -n, assuming you don't mind the slower performance and the slightly-wrong answers due to floating-point rounding errors. Also (as Andreas Schwab mentioned) if you care about how ties are broken, you may need to specify sort -k 1,1g I figure sort -n doesn't convert the data to be sorted to a floating point number. That's correct, but sort -n should still work as you expected for your input. Here are the details about my configuration, if you want to compare notes as to why yours isn't working: $ sort --version sort (coreutils) 5.2.0 Written by Mike Haertel and Paul Eggert. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ uname -a Linux penguin 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 unknown unknown GNU/Linux $ locale LANG=C LC_CTYPE=en_US LC_NUMERIC=en_US LC_TIME=en_US LC_COLLATE=en_US LC_MONETARY=en_US LC_MESSAGES=en_US LC_PAPER=en_US LC_NAME=en_US LC_ADDRESS=en_US LC_TELEPHONE=en_US LC_MEASUREMENT=en_US LC_IDENTIFICATION=en_US LC_ALL=en_US ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: join docs vs. obsolescent options
Dan Jacobson [EMAIL PROTECTED] writes: The join man page should put the obsolescent options last. The join Info page should say which options are obsolescent. You don't mention which version you're talking about, but I think it's fixed in coreutils 5.2.0, where the man page doesn't mention the obsolete options at all (as they have been removed on POSIX 1003.1-2001 hosts). ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: [patch] coreutils-5.2.0: fix du/deref-args test
Tim Waugh [EMAIL PROTECTED] writes: -du -kD slink-to-64k | sed 's/^6[0-9]/64/' out +du -kD slink-to-64k | sed 's/^6[0-9]\|72/64/' out Alas, that \| isn't portable POSIX code. Perhaps better would be du -kD slink-to-64k | sed 's/^[67][0-9]/64/' out ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-0.52: Question about new ls -l output format
At Wed, 10 Mar 2004 15:30:46 -0300, Marcelo Ricardo Leitner [EMAIL PROTECTED] writes: I got here some bash scripts that broke with this change and I'm wondering why change such a thing, used for many years?. My original motivation for proposing the patch was that ls's output lines were getting too wide. Part of the problem was internationalized environments, where the dates can be quite wide in some locales. Part of it was the new options for file-size display, e.g. ls -l --block-size='1, where the file sizes get wide. df is next. (:-) Probably many other scripts around will broke. No doubt, but they were all broken anyway, since there's no standard for column widths here, and implementation behavior differs widely even if you assume the C locale. For example for ls -ld: drwxr-xr-x 41 eggert eggert 4096 Mar 10 15:54 . old GNU ls drwxr-xr-x 41 eggert eggert 4096 Mar 10 15:54 . new GNU ls drwxr-sr-x 41 eggert eggert 4096 Mar 10 15:54 .Solaris 9 ls drwxr-sr-x 41 eggert eggert 4096 Mar 10 15:54 . OpenBSD 3.2 ls I would like to know if there are plans to support the old method, None that I know of. It could be an option or envvar, but it'd probably be better to generalize this so that you could specify an arbitrary format for the line, and then mimic (say) Solaris ls if you want. Or even when outputing to a pipe, not to a terminal, It wouldn't be done that way, as that violates the GNU coding standard. It'd be an option or an environment variable or something like that. Anothor issue I found is the uid/gid column align, which changes if the uid/gid can be converted to a username/groupname or not. ls -l at a nfs shared directory, used as a shared storage for misc stuff, got so confusing! You're talking about this sort of thing? drwxrwxrwt 2 eggert eggert 4096 2004-03-10 13:37 .esd drwxrwxrwt 2 root root4096 2004-03-10 13:27 .font-unix -rw-r--r-- 1 999 0 2004-03-10 22:59 foox srw-rw-rw- 1 root root 0 2004-03-10 13:27 .gdm_socket I kind of prefer having the uid/gid numbers stick out like that. It makes it a bit clearer which entries are numbers and not names; I want unusual entries to stick out. Right-adjusting numbers also looks nicer when all the uid/gid entries are numbers. It's a relatively minor point, though. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#239288: coreutils: cp --preserve=timestamps -u copies repeatedly
Jim Meyering [EMAIL PROTECTED] writes:
http://article.gmane.org/gmane.comp.gnu.coreutils.bugs/1464
but no one has begun work on that, as far as I know.
Here's a proposed implementation for that idea. It was a bit trickier
than I thought it would be, mostly because I thought of more
optimizations.
2004-03-27 Paul Eggert [EMAIL PROTECTED]
* NEWS: cp -pu and mv -u (when copying) now take the destination
file system time stamp resolution into account.
* doc/coreutils.texi (mv invocation): Document this.
(cp invocation): Document -u (it was missing!) with new behavior.
* lib/utimecmp.c, lib/utimecmp.h, m4/utimecmp.m4: New files.
* lib/Makefile.am (libfetish_a_SOURCES): Add utimecmp.c, utimecmp.h.
* m4/prereq.m4 (jm_PREREQ): Require gl_UTIMECMP.
* src/copy.c: Include utimecmp.h.
(copy_internal): Compare time stamps using utimecmp rather than
MTIME_CMP.
Index: NEWS
===
RCS file: /home/meyering/coreutils/cu/NEWS,v
retrieving revision 1.194
diff -p -u -r1.194 NEWS
--- NEWS24 Mar 2004 17:38:58 - 1.194
+++ NEWS24 Mar 2004 23:15:42 -
@@ -4,6 +4,12 @@ GNU coreutils NEWS
** New features
+ cp -pu and mv -u (when copying) now don't bother to update the
+ destination if the resulting time stamp would be no newer than the
+ preexisting time stamp. This saves work in the common case when
+ copying or moving multiple times to the same destination in a file
+ system with a coarse time stamp resolution.
+
'df', 'du', and 'ls' now take the default block size from the
BLOCKSIZE environment variable if the BLOCK_SIZE, DF_BLOCK_SIZE,
DU_BLOCK_SIZE, and LS_BLOCK_SIZE environment variables are not set.
Index: doc/coreutils.texi
===
RCS file: /home/meyering/coreutils/cu/doc/coreutils.texi,v
retrieving revision 1.173
diff -p -u -r1.173 coreutils.texi
--- doc/coreutils.texi 24 Mar 2004 17:38:17 - 1.173
+++ doc/coreutils.texi 24 Mar 2004 23:11:13 -
@@ -6402,6 +6402,19 @@ results in an error message on systems t
@optTargetDirectory
[EMAIL PROTECTED] -u
[EMAIL PROTECTED] --update
[EMAIL PROTECTED] -u
[EMAIL PROTECTED] --update
[EMAIL PROTECTED] newer files, copying only
+Do not copy a non-directory that has an existing destination with the
+same or newer modification time. If time stamps are being preserved,
+the comparison is to the source time stamp truncated to the
+resolutions of the destination file system and of the system calls
+used to update time stamps; this avoids duplicate work if several
[EMAIL PROTECTED] -pu} commands are executed with the same source and
+destination.
+
@item -v
@itemx --verbose
@opindex -v
@@ -6798,6 +6811,11 @@ about each existing destination file.
@cindex newer files, moving only
Do not move a non-directory that has an existing destination with the
same or newer modification time.
+If the move is across file system boundaries, the comparison is to the
+source time stamp truncated to the resolutions of the destination file
+system and of the system calls used to update time stamps; this avoids
+duplicate work if several @samp{mv -u} commands are executed with the
+same source and destination.
@item -v
@itemx --verbose
Index: lib/Makefile.am
===
RCS file: /home/meyering/coreutils/cu/lib/Makefile.am,v
retrieving revision 1.182
diff -p -u -r1.182 Makefile.am
--- lib/Makefile.am 23 Mar 2004 17:34:05 - 1.182
+++ lib/Makefile.am 24 Mar 2004 20:20:57 -
@@ -115,6 +115,7 @@ libfetish_a_SOURCES = \
unistd-safer.h \
unlocked-io.h \
userspec.c userspec.h \
+ utimecmp.c utimecmp.h \
utimens.c utimens.h \
version-etc.c version-etc.h \
xalloc.h \
Index: m4/prereq.m4
===
RCS file: /home/meyering/coreutils/cu/m4/prereq.m4,v
retrieving revision 1.83
diff -p -u -r1.83 prereq.m4
--- m4/prereq.m418 Dec 2003 10:33:39 - 1.83
+++ m4/prereq.m424 Mar 2004 22:21:02 -
@@ -103,6 +103,7 @@ AC_DEFUN([jm_PREREQ],
AC_REQUIRE([gl_UNICODEIO])
AC_REQUIRE([gl_UNISTD_SAFER])
AC_REQUIRE([gl_USERSPEC])
+ AC_REQUIRE([gl_UTIMECMP])
AC_REQUIRE([gl_UTIMENS])
AC_REQUIRE([gl_XALLOC])
AC_REQUIRE([gl_XGETCWD])
Index: src/copy.c
===
RCS file: /home/meyering/coreutils/cu/src/copy.c,v
retrieving revision 1.159
diff -p -u -r1.159 copy.c
--- src/copy.c 12 Mar 2004 11:53:18 - 1.159
+++ src/copy.c 28 Mar 2004 00:09:07 -
@@ -39,6 +39,7 @@
#include quote.h
#include same.h
#include savedir.h
+#include utimecmp.h
#include utimens.h
#include xreadlink.h
@@ -945,16 +946,28 @@ copy_internal (const char *src_path, con
return 1
Re: date -d yesterday fails after daylight saving
Piotr Pitkowski [EMAIL PROTECTED] writes: But having 'date +%y%m%d -d yesterday' called just after midnight on march 28 and 29, I've got the same date (040327) due to daylight saving time shift. I couldn't reproduce this bug with coreutils 5.2.1. I set TZ=Europe/Warsaw in the environment and set the simulated current time to 1080512250 (Mon Mar 29 00:17:30 CEST 2004). I ran 'date +%y%m%d -d yesterday' and got the expected output 040328. There have been some changes in that area since 4.5.3 so perhaps the bug has been fixed since then. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: df bug with a big vfat partition [2]
Nicolas BENOIT [EMAIL PROTECTED] writes:
$df /dev/hda7 -h -T
FilesystemTypeSize Used Avail Use% Mounted on
/dev/hda7 vfat126G 35G 91G 28% /mnt/prtg
$strace df /dev/hda7 -h -T 21 | grep statfs
statfs(/mnt/prtg, {f_type=MSDOS_SUPER_MAGIC, f_bsize=32768,
f_blocks=4120920, f_bfree=2971459, f_files=0, f_ffree=0, f_namelen=260})
= 0
It looks to me like df is reporting the disk usage faithfully from
the numbers that statfs is giving it: 2971459 / 4120920 is 0.721,
which would mean 72% is free and 28% is in use. The Used and Avail
lines also seem to match the statfs call: e.g., 2971459 * 32768 B is
90.68 GiB. So, if these numbers are wrong, it's something wrong with
your kernel or file system code, not in df itself.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Problem installing coreutils-5.2.1 over the same prefix
DervishD [EMAIL PROTECTED] writes:
I've downloaded and installed coreutils-5.2.1 and the 'make
install-strip' command fails when installing 'mv', since old /bin/mv
(I install my coreutils in prefix '/')
Wow! You're brave.
is removed by 'config/install-sh' when it is still needed.
Thanks for reporting that. Here is a proposed patch to Automake's
install-sh to handle this case.
2004-04-01 Paul Eggert [EMAIL PROTECTED]
* lib/install-sh: If mv -f works, use it, and fall back to
the old test -f + rm -f + mv method only if mv -f does
not work. This improves performance in the usual case where
mv -f works. It also lets us install the mv command
without worrying about a small window where mv does not
exist (this problem was reported by Raul Nunez de Arenas
Coronado).
Index: install-sh
===
RCS file: /home/meyering/coreutils/cu/config/install-sh,v
retrieving revision 1.14
diff -p -u -r1.14 install-sh
--- install-sh 19 Jan 2004 17:53:12 - 1.14
+++ install-sh 1 Apr 2004 21:27:20 -
@@ -274,26 +274,35 @@ do
{ test -z $stripcmd || $doit $stripcmd $dsttmp; } \
{ test -z $chmodcmd || $doit $chmodcmd $dsttmp; }
-# Now remove or move aside any old file at destination location. We
-# try this two ways since rm can't unlink itself on some systems and
-# the destination file might be busy for other reasons. In this case,
-# the final cleanup might fail but the new file should still install
-# successfully.
-{
- if test -f $dstdir/$dstfile; then
-$doit $rmcmd -f $dstdir/$dstfile 2/dev/null \
-|| $doit $mvcmd -f $dstdir/$dstfile $rmtmp 2/dev/null \
-|| {
- echo $0: cannot unlink or rename $dstdir/$dstfile 2
- (exit 1); exit
-}
- else
-:
- fi
-}
-
# Now rename the file to the real destination.
-$doit $mvcmd $dsttmp $dstdir/$dstfile
+{ $doit $mvcmd -f $dsttmp $dstdir/$dstfile 2/dev/null \
+ || {
+ # The rename failed, perhaps because mv can't rename something else
+ # to itself, or perhaps because mv is so ancient that it does not
+ # support -f.
+
+ # Now remove or move aside any old file at destination location.
+ # We try this two ways since rm can't unlink itself on some
+ # systems and the destination file might be busy for other
+ # reasons. In this case, the final cleanup might fail but the new
+ # file should still install successfully.
+ {
+if test -f $dstdir/$dstfile; then
+ $doit $rmcmd -f $dstdir/$dstfile 2/dev/null \
+ || $doit $mvcmd -f $dstdir/$dstfile $rmtmp 2/dev/null \
+ || {
+echo $0: cannot unlink or rename $dstdir/$dstfile 2
+(exit 1); exit
+ }
+else
+ :
+fi
+ }
+
+ # Now rename the file to the real destination.
+ $doit $mvcmd $dsttmp $dstdir/$dstfile
+}
+}
fi || { (exit 1); exit; }
done
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
