bug#20835: rmdir foo/. fails

[Ed Avis]

Stephane Chazelas  gmail.com> writes:

>Solaris 10 behaves like linux (EINVAL for ".", EEXIST for "..").
>The rmdir utility there is more explicit:
>
>$ rmdir D/. D/..
>rmdir: directory "D/.": Can't remove current directory or ..

I think that error message would be an improvement on GNU rmdir's current
behaviour.  Although programmers can understand what EINVAL means and look it
up in the POSIX spec, printing 'Invalid argument' is not friendly to those
who are less wizardly.

(That said I would change it to "Can't remove . or ..", since the user did
not ask to remove the current directory.)

-- 
Ed Avis 

bug#20835: rmdir foo/. fails

[Ed Avis]

POSIX documents that EINVAL be returned for rmdir('foo/.') but as far as I
can see from the link you sent it does not document the error status for
rmdir('foo/..') beyond saying that it shall fail.  As it happens, it returns
ENOTEMPTY on Linux.

OK, you point out that foo/. might not always be the same thing as foo.
How about this: if foo/. has the same inode number as foo then rmdir proceeds.
If not, it prints an error a bit more helpful than 'Invalid argument'.

-- 
Ed Avis 

bug#20835: rmdir foo/. fails

[Ed Avis]

Thanks Pádraig Brady for your reply.  You mentioned the manual page for
rmdir(2) and the POSIX spec.  But isn't that POSIX spec talking about the
rmdir(2) system call - not the rmdir(1) executable?

As far as I know there is no requirement that rmdir(1) be an exact wrapper
for rmdir(2); rather its purpose as stated in the the documentation is to
remove empty directories.  If it can do that job better by handling foo/.
rather than giving an Invalid argument error, surely that's an improvement?

  "The meaning of deleting pathname/. is unclear, because the name
   of the file (directory) in the parent directory to be removed is
   not clear, particularly in the presence of multiple links to a directory."

In theory that is true but don't all modern Unix systems disallow creating
hard links to a directory?  So in practice 'foo/.' is pretty unambiguous.

But out of interest,

  "If the path argument refers to a path whose final component
   is either dot or dot-dot, rmdir() shall fail."

Does POSIX document the error status that should be returned in these cases?

-- 
Ed Avis 

bug#20835: rmdir foo/. fails

[Ed Avis]

% mkdir foo
% rmdir foo/.
rmdir: failed to remove ‘foo/.’: Invalid argument
% rmdir --version
rmdir (GNU coreutils) 8.23
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.


I suggest that 'rmdir foo/.' should be equivalent to 'rmdir foo'.
Strangely, 'rmdir foo/..' does work as expected (that is, it fails with
'Directory not empty').

Note that Emacs command completion (in shell-mode) will complete foo to foo/.

-- 
Ed Avis 

Re: Patch to check for required programs when building from source checkout

[Ed Avis]

Jim Meyering  meyering.net> writes:

>>% printf 'automake-1.10%s\n' .1 a|sort -V
>>automake-1.10a
>>automake-1.10.1

>IMHO this means automake is muddying the waters by giving
>something-newer-than automake-1.10.1 the version string "1.10a".

Or that sort -V is incorrect.  Note that Perl's Sort::Versions thinks 1.10a is 
newer than 1.10.1.  Eric Blake mentioned that m4_version_compare also thinks 
so.

It's really not good to have different tools disagree about version ordering so 
I suggest reconciling sort -V against Sort::Versions, autoconf and any other 
version-string-comparing tool you can find to see what the consensus is.

>>Wouldn't it be simpler to include a file bootstrap.required_progs

>Ready to write the patch?

I think I pretty much wrote it in the earlier message ;-p.

I don't have a current copyright waiver from my employer so I would need to get 
that sorted out.  It may be easier for you to just note the list of programs I 
mentioned and write the few lines of shell script yourself.  However, I will 
see if I can get the legal side fixed.

-- 
Ed Avis <[EMAIL PROTECTED]>



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Patch to check for required programs when building from source checkout

[Ed Avis]

Jim Meyering  meyering.net> writes:

[funky automake version numbers]

>When in doubt, use sort -V from the latest coreutils:
>
>$ printf 'automake-1.10%s\n' .1 a|sort -V
>automake-1.10.1
>automake-1.10a

That's not the result I get:

% printf 'automake-1.10%s\n' .1 a|sort -V
automake-1.10a
automake-1.10.1
% sort --version | head -n 1
sort (GNU coreutils) 7.0.11-5996-dirty

The code was pulled from git just now.

>I don't want to maintain yet another package-specific file/script,
>so I've been toying with the idea of adding generic code to
>bootstrap that would automatically determine more prerequisites
>like this.  E.g., if it sees that gperf will be used by this
>package, then it'd ensure it's usable.

Wouldn't it be simpler to include a file bootstrap.required_progs containing a 
list one per line and then have something like

if test -e bootstrap.required_progs; then
for p in `cat bootstrap.required_progs`; do
if ! $p --help >/dev/null; then
echo You must install $p
exit 1
fi
done
done

Autodetecting them seems a bit baroque, but I guess you could grep -r or 
something...

-- 
Ed Avis <[EMAIL PROTECTED]>



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

FAIL: df/total-awk.log

[Ed Avis]

With current coreutils source from git, one test fails on my machine.  It is a 
Fedora 9 box with a few Windows filesystems mounted.  Here is the tests/test-
suite.log.

===
   GNU coreutils 7.0.5-42df6-dirty: tests/test-suite.log   
===

1 of 353 tests failed.  (44 tests were not run).  

.. contents:: :depth: 2


FAIL: df/total-awk.log (exit: 1)


+ ls --version
ls (GNU coreutils) 7.0.5-42df6-dirty
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard M. Stallman and David MacKenzie.
+ . ./test-lib.sh
++ unset function_test
++ eval 'function_test() { return 11; }; function_test'
+++ function_test
+++ return 11
++ test 11 '!=' 11
+++ pwd
++ test_dir_=/home/eda/git_working/coreutils/tests
+++ this_test_
+++ echo ././df/total-awk
+++ sed 's,.*/,,'
++ this_test=total-awk
+++ /home/eda/git_working/coreutils/src/mktemp -d --
tmp=/home/eda/git_working/coreutils/tests cu-total-awk.XX
++ t_=/home/eda/git_working/coreutils/tests/cu-total-awk.gT1QMUWGvo
++ trap remove_tmp_ 0
++ trap 'Exit $?' 1 2 13 15
++ cd /home/eda/git_working/coreutils/tests/cu-total-awk.gT1QMUWGvo
++ diff --version
++ grep GNU
+ fail=0
+ umask 22
+ echo '
BEGIN {
  total = 0
  used  = 0
  available = 0
}
{
  if (NR==1 || $0==$1 || $0~/^total +(-?[0-9]+|-) +(-?[0-9]+|-) +(-?[0-9]+|-) 
+-?[0-9]+%$/)
next
  if ($1~/^[0-9]/)
{
  total += $1
  used  += $2
  available += $3
}
  else
{
  total += $2
  used  += $3
  available += $4
}
}
END {
  print total
  print used
  print available
}
'
+ echo '
/^total +(-?[0-9]+|-) +(-?[0-9]+|-) +(-?[0-9]+|-) +-?[0-9]+%$/ {
  print $2;
  print $3;
  print $4
}
'
+ df --block-size=512 --total
+ tee tmp
Filesystem 512B-blocks  Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
  30218224  20334128   8324344  71% /
/dev/sda1   202172 49990141744  27% /boot
tmpfs  207492096   2074824   1% /dev/shm
//wcl-fp1/users  384801112 288044832  96756280  75% /mnt/users
//wcl-fp1/shared 384801112 288044832  96756280  75% /mnt/shared
//wcl-fp1/systems384801112 288044832  96756280  75% /mnt/systems
//wcl-fp2/research   1146724760 1054703624  92021136  92% /mnt/research
//wcl-prod/wwwroot41950520  28946968  13003552  70% /mnt/prod_wwwroot
//wcl-cr/crdprodorderimport
 242670232  84690984 157979248  35% /mnt/crdprodorderimport
//wcl-prod/log41950520  28946968  13003552  70% /mnt/prod_log
//wcl-prod2/log  143289560  16162712 127126848  12% /mnt/prod2_log
//wcl-prod-dr/log 41950520  19097328  22853192  46% /mnt/prod-dr_log
//wcl-bt1/log145195400  45603352  99592048  32% /mnt/bt1_log
//wcl-ws13/log   139476264  25230736 114245528  19% /mnt/ws13_log
//wcl-ws44/log   156280256 133967288  22312968  86% /mnt/ws44_log
//wcl-trademanager/log
 156280256  16683232 139597024  11% /mnt/trademanager_log
//wcl-prod/C$ 41950520  28946968  13003552  70% /mnt/wcl-prod
//wcl-prod2/C$   143289560  16162712 127126848  12% /mnt/wcl-prod2
//wcl-prod-dr/C$  41950520  19097328  22853192  46% /mnt/wcl-prod-dr
//wcl-bt1/C$ 145195400  45603352  99592048  32% /mnt/wcl-bt1
//wcl-ws13/C$139476264  25230736 114245528  19% /mnt/wcl-ws13
//wcl-ws44/C$156280256 133967288  22312968  86% /mnt/wcl-ws44
total4110809460 2607560286 1501678984  64%
+ gawk -f compute_sum.awk tmp
+ gawk -f parse_total.awk tmp
+ compare out1 out2
+ diff -u out1 out2
--- out12008-10-10 20:22:10.0 +0100
+++ out22008-10-10 20:22:10.0 +0100
@@ -1,3 +1,3 @@
-4.11081e+09
-2.60756e+09
+4110809460
+2607560286
 1501678984
+ fail=1
+ df -i --block-size=512 --total
+ tee tmp
FilesystemInodes   IUsed   IFree IUse% Mounted on
/dev/mapper/VolGroup00-LogVol00
 3899392  390616 3508776   11% /
/dev/sda1  26104  44   260601% /boot
tmpfs 223850   2  2238481% /dev/shm
//wcl-fp1/users0   0   0-  /mnt/users
//wcl-fp1/shared   0   0   0-  /mnt/shared
//wcl-fp1/systems  0   0   0-  /mnt/systems
//wcl-fp2/research 0   0   0-  /mnt/research
//wcl-prod/wwwroot 0   0   0-  /mnt/prod_wwwroot
//wcl-cr/crdprodorderimport
   0   0   0-  /mnt/crdprodorderimport
//wcl-prod/log 0   0   0-  /mnt/prod_log
//wcl-prod2/log0   0   0-  /mnt/prod2_log
//wcl-prod-dr/log  0   0   

Re: Patch to check for required programs when building from source checkout

[Ed Avis]

Jim Meyering  meyering.net> writes:

>>A few tools are required to build coreutils from a git checkout, but
>>not checked in a friendly way.

>The newer automake-1.10a is actually required.

Ah, ok, it could do with a comment because at first it appears that 1.10.1 
should be newer than 1.10a.

[checks for autopoint, aclocal, and makeinfo]

>I like the idea of automating these checks, but can't use those changes
>as-is, since bootstrap is actually used more generally (it's home is in
>gnulib/build-aux/)

If you can't change the bootstrap script, then maybe include it as 
bootstrap.vanilla and then bootstrap is a small script that checks for the 
extra tools and then runs bootstrap.vanilla.

>Besides, this is the purpose of the README-hacking file.

Yes, well, guilty as charged I admit ;-p.  But it is nicer to have a more user-
friendly build process (failing earlier rather than later).  I am sure that the 
inclusion of a friendly 'configure' script has helped the popularity of GNU 
programs through the years, and now that git and other DVCSes are replacing 
tarballs as the normal means of getting source code, it would be good to 
preserve that property.

>>-for file in $gnulib_files; do
>>-  symlink_to_dir "$GNULIB_SRCDIR" $file || exit
>>-done
>>+if test "x$gnulib_files" != x; then
>>+  for file in $gnulib_files; do
>>+symlink_to_dir "$GNULIB_SRCDIR" $file || exit
>>+  done
>>+fi
> 
>What's the above for?
>When would $gnulib_files be empty?

It got empty when one of the dependencies above was missing, I don't remember 
which one.  If it is empty, then 'for file in ;do' is a shell syntax error.

>gperf should not be required when building from a tarball,
>so its absence shouldn't make configure fail.

OK, that's another thing better checked in the bootstrap script.

-- 
Ed Avis <[EMAIL PROTECTED]>



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Patch to check for required programs when building from source checkout

[Ed Avis]

A few tools are required to build coreutils from a git checkout, but 
not checked in a friendly way.  This patch adds checks to bootstrap 
and configure.


Oh, and updates automake to 1.10.1, which appears to work.

diff --git a/bootstrap b/bootstrap
index 438a145..0232ae9 100755
--- a/bootstrap
+++ b/bootstrap
@@ -22,6 +22,16 @@
 nl='
 '

+# These programs are needed by this script.
+if ! autopoint --help >/dev/null; then echo You must install autopoint from 
gettext; exit 1; fi
+if ! aclocal --help >/dev/null; then echo You must install aclocal from 
automake; exit 1; fi
+
+# This isn't needed by this script, but it is necessary for building
+# from a source checkout, and is not checked by configure because
+# normal building from a distributed tarball doesn't require it.
+#
+if ! makeinfo --help >/dev/null; then echo You must install makeinfo from 
Texinfo; exit 1; fi
+
 # Ensure file names are sorted consistently across platforms.
 LC_ALL=C
 export LC_ALL
@@ -558,9 +568,11 @@ echo "$0: $gnulib_tool $gnulib_tool_options --import ..."
 $gnulib_tool $gnulib_tool_options --import $gnulib_modules &&
 slurp $bt || exit

-for file in $gnulib_files; do
-  symlink_to_dir "$GNULIB_SRCDIR" $file || exit
-done
+if test "x$gnulib_files" != x; then
+  for file in $gnulib_files; do
+symlink_to_dir "$GNULIB_SRCDIR" $file || exit
+  done
+fi


 # Import from gettext.
diff --git a/configure.ac b/configure.ac
index 549c7ee..61b708c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -32,7 +32,7 @@ AC_CONFIG_SRCDIR(src/ls.c)
 AC_CONFIG_AUX_DIR(build-aux)
 AC_CONFIG_HEADERS([lib/config.h:lib/config.hin])

-AM_INIT_AUTOMAKE([1.10a dist-lzma])
+AM_INIT_AUTOMAKE([1.10.1 dist-lzma])

 AC_PROG_CC_STDC
 AM_PROG_CC_C_O
@@ -291,6 +291,12 @@ case $t in
   1) ;;
 esac

+AC_CHECK_PROG([GPERF], [gperf], [1])
+if test "x$GPERF" = x; then
+  AC_MSG_ERROR([You need to install gperf])
+  exit 1
+fi
+
 # Given the name of a variable containing a space-separated list of
 # install-by-default programs and the actual list do-not-install-by-default
 # programs, modify the former variable to reflect any "do-install" and

--
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

cp -u should skip copying a file to itself

[Ed Avis]

% touch foo foo
% cp -u foo foo && echo yes
cp: `foo' and `foo' are the same file

I expected that since -u says

   -u, --update
  copy only when the SOURCE file is newer than the
  destination file or when the destination file is missing

it would not attempt to copy the file in this case (since the file is 
not newer than itself) and cp would return a true exit status.


--
Ed Avis <[EMAIL PROTECTED]>



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

dircolors enhancement: warn on unknown TERM

[Ed Avis]

The .dir_colors input file for dircolors(1) has a list of terminal 
types that are colorizable.  It would be helpful to also have an 
explicit list in that config file of terminal types that should not be 
colorized.  Then if the value of $TERM is unknown dircolors can print 
a warning.


If you don't want to issue a warning in the general case then at least 
do so when stdout is a tty.  In this day and age all terminals are 
colour-capable and ls(1) assumes this.  Dircolors produces empty 
output on a tty that's not recognized.  But an empty LS_COLORS 
environment variable does not tell ls to avoid colorization, just to 
use the default colour scheme.


--
Ed Avis <[EMAIL PROTECTED]>



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

od -t a to warn for non-ASCII

[Ed Avis]

If you run 'od -t a' then the high bit is silently stripped out of the 
input.  This can cause a bit of confusion (especially when dealing 
with char 160 (non-breaking space) in ISO-8859-1 which strips down to 
a regular space...)


I suggest that when 'od -t a' encounters the first high-bit-set 
character in the input it should print a warning that the bit is being 
ignored, and that if you have input files that might not be pure ASCII 
then 'od -t c' might be a better choice.  This warning could be 
disabled when POSIXLY_CORRECT is set.


If you don't want to do that, please update the help text and info 
documentation to make it clear that the 'a' format maps high-bit-set 
characters onto the same output as ASCII, and so probably isn't what 
you want if you are trying to see what characters a byte stream 
contains.


--
Ed Avis <[EMAIL PROTECTED]>



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Unable to build current CVS: coreutils.pot not built

[Ed Avis]

On Mon, 10 May 2004, Paul Eggert wrote:

>>shouldn't the configure script have a 'checking for gettext' stage?
>
>When you check source out directly from CVS, you're assumed to be an
>expert, and to have the correct build tools even if they're not on
>the standard list of tools all users are assumed to have.  (The set
>of "expert" tools includes CVS itself.  :-) The "checking for" stuff
>is designed more for non-experts, who are assumed to have tarballs
>instead of checking things out directly from CVS.

That makes perfect sense.  So when I check out of CVS, am I getting a
slightly different code base from what goes into the tarballs?

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: Unable to build current CVS: coreutils.pot not built

[Ed Avis]

On Sun, 9 May 2004, Andreas Schwab wrote:

>>I got a clean checkout, configured with './configure' and tried to
>>build with 'make'.  The build fails with
>>
>>make coreutils.pot-update
>>make[4]: Entering directory `/home/ed/cvs_working/coreutils/po'
>>: --default-domain=coreutils --directory=.. \
>
>You need to install gettext.

OK, I'll try that.  But shouldn't the configure script have a
'checking for gettext' stage?

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: Unable to build current CVS: coreutils.pot not built

[Ed Avis]

On Sun, 9 May 2004, Andreas Schwab wrote:

>>>>I got a clean checkout, configured with './configure' and tried to
>>>>build with 'make'.  The build fails with
>>>>
>>>>make coreutils.pot-update

>>>You need to install gettext.

>>But shouldn't the configure script have a 'checking for gettext'
>>stage?
>
>It does, that's why xgettext is not called.

Is it a bug that coreutils would not build after configuring?  I
expected that if an important component such as gettext were missing,
it would report that and not write a makefile.

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Test failure tests/date/date-tests with current CVS

[Ed Avis]

I configured and built the current CVS HEAD of coreutils, but 'make
check' fails with

make  check-TESTS
make[3]: Entering directory
`/home/ed/cvs_working/coreutils/tests/date'
./date-tests: line 777: ./utc-1.I: No such file or directory
./date-tests: line 795: ./utc-1a.I: No such file or directory
FAIL: date-tests
==
1 of 1 tests failed
Please report to [EMAIL PROTECTED]
==
make[3]: *** [check-TESTS] Error 1

I am not sure what generates that file or why it is missing; it seems
to be Test.pm but how?

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Unable to build current CVS: coreutils.pot not built

[Ed Avis]

(I hope this list is the right place to report bugs in current CVS.)

I got a clean checkout, configured with './configure' and tried to
build with 'make'.  The build fails with

make coreutils.pot-update
make[4]: Entering directory `/home/ed/cvs_working/coreutils/po'
: --default-domain=coreutils --directory=.. \
  --add-comments=TRANSLATORS: --keyword=_ --keyword=N_
--from-code=UTF-8 \
  --files-from=./POTFILES.in \
  --copyright-holder='Free Software Foundation, Inc.' \
  --msgid-bugs-address='[EMAIL PROTECTED]'
test ! -f coreutils.po || { \
  if test -f ./coreutils.pot; then \
sed -f remove-potcdate.sed < ./coreutils.pot > coreutils.1po && \
sed -f remove-potcdate.sed < coreutils.po > coreutils.2po && \
if cmp coreutils.1po coreutils.2po >/dev/null 2>&1; then \
  rm -f coreutils.1po coreutils.2po coreutils.po; \
else \
  rm -f coreutils.1po coreutils.2po ./coreutils.pot && \
  mv coreutils.po ./coreutils.pot; \
fi; \
  else \
mv coreutils.po ./coreutils.pot; \
  fi; \
}
make[4]: Leaving directory `/home/ed/cvs_working/coreutils/po'
/usr/bin/msgmerge --update af.po coreutils.pot
/usr/bin/msgmerge: error while opening "coreutils.pot" for reading: No
such file or directory
make[3]: *** [af.po] Error 1
make[3]: Leaving directory `/home/ed/cvs_working/coreutils/po'
make[2]: *** [stamp-po] Error 2
make[2]: Leaving directory `/home/ed/cvs_working/coreutils/po'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ed/cvs_working/coreutils'
make: *** [all] Error 2


If you want I can send the whole build log, config.log and so on.  I
am running Red Hat Linux 9 but with some updated packages including
coreutils-5.2.0.

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: ls --color feature request: ordinary files uncoloured

[Ed Avis]

Here is an updated patch against coreutils-5.2.0, including changelog
and news entries.  All the 'make check' tests pass, at least for me.

diff -ru coreutils-5.2.0/ChangeLog coreutils-5.2.0-new/ChangeLog
--- coreutils-5.2.0/ChangeLog   2004-02-17 16:05:39.0 +
+++ coreutils-5.2.0-new/ChangeLog   2004-02-22 13:36:13.163611440 +
@@ -1,3 +1,11 @@
+2004-02-22  Ed Avis  <[EMAIL PROTECTED]>
+
+   * src/ls.c: ordinary files are written with no ANSI escape
+   sequences, even with --color.  The escape sequence to reset the
+   terminal is not output if no filenames were printed with color.
+   In particular this means nothing printed on stdout for 'ls --color
+   nonexistent-file'.
+
 2004-02-17  Jim Meyering  <[EMAIL PROTECTED]>
 
* Version 5.2.0.
diff -ru coreutils-5.2.0/NEWS coreutils-5.2.0-new/NEWS
--- coreutils-5.2.0/NEWS2004-02-19 18:04:27.0 +
+++ coreutils-5.2.0-new/NEWS2004-02-22 13:42:28.437561128 +
@@ -1,4 +1,11 @@
 GNU coreutils NEWS-*- outline -*-
+* Major changes since 5.2.0
+
+  ls --color now leaves ordinary files uncolored, unless you have
+  explicitly chosen a color for them in the LS_COLORS environment
+  variable.  And if it did not print any color escape sequences, it
+  will not print the escape sequence to reset the terminal afterwards.
+
 * Major changes in release 5.2.0 (2004-02-19) [stable]
 
 ** Bug fixes
diff -ru coreutils-5.2.0/src/ls.c coreutils-5.2.0-new/src/ls.c
--- coreutils-5.2.0/src/ls.c2004-02-01 19:31:00.0 +
+++ coreutils-5.2.0-new/src/ls.c2004-02-22 13:34:13.349825904 +
@@ -227,7 +227,7 @@
 static int file_interesting (const struct dirent *next);
 static uintmax_t gobble_file (const char *name, enum filetype type,
  int explicit_arg, const char *dirname);
-static void print_color_indicator (const char *name, mode_t mode, int linkok);
+static bool print_color_indicator (const char *name, mode_t mode, int linkok);
 static void put_indicator (const struct bin_str *ind);
 static int put_indicator_direct (const struct bin_str *ind);
 static void add_ignore_pattern (const char *pattern);
@@ -483,6 +483,13 @@
 
 static int print_with_color;
 
+/* Whether we used any colors in the output so far.  If so, we will
+   need to restore the default color later.  If not, we will need to
+   print some stuff (prep_non_filename_text ()) before using color for
+   the first time. */
+
+static bool used_color = false;
+
 enum color_type
   {
 color_never,   /* 0: default or --color=never */
@@ -501,13 +508,13 @@
 
 enum indicator_no
   {
-C_LEFT, C_RIGHT, C_END, C_NORM, C_FILE, C_DIR, C_LINK, C_FIFO, C_SOCK,
+C_LEFT, C_RIGHT, C_END, C_RESET, C_NORM, C_FILE, C_DIR, C_LINK, C_FIFO, C_SOCK,
 C_BLK, C_CHR, C_MISSING, C_ORPHAN, C_EXEC, C_DOOR
   };
 
 static const char *const indicator_name[]=
   {
-"lc", "rc", "ec", "no", "fi", "di", "ln", "pi", "so",
+"lc", "rc", "ec", "rs", "no", "fi", "di", "ln", "pi", "so",
 "bd", "cd", "mi", "or", "ex", "do", NULL
   };
 
@@ -523,8 +530,9 @@
 { LEN_STR_PAIR ("\033[") },/* lc: Left of color sequence */
 { LEN_STR_PAIR ("m") },/* rc: Right of color sequence */
 { 0, NULL },   /* ec: End color (replaces lc+no+rc) */
-{ LEN_STR_PAIR ("0") },/* no: Normal */
-{ LEN_STR_PAIR ("0") },/* fi: File: default */
+{ LEN_STR_PAIR ("0") },/* rs: Reset to ordinary colors */
+{ 0, NULL },   /* no: Normal */
+{ 0, NULL },   /* fi: File: default */
 { LEN_STR_PAIR ("01;34") },/* di: Directory: bright blue */
 { LEN_STR_PAIR ("01;36") },/* ln: Symlink: bright cyan */
 { LEN_STR_PAIR ("33") },   /* pi: Pipe: yellow/brown */
@@ -977,7 +985,8 @@
   signal (sig, SIG_IGN);
 #endif
 
-  restore_default_color ();
+  if (used_color)
+restore_default_color ();
 
   /* SIGTSTP is special, since the application can receive that signal more
  than once.  In this case, don't set the signal handler to the default.
@@ -1035,7 +1044,6 @@
  may have just reset it -- e.g., if LS_COLORS is invalid.  */
   if (print_with_color)
 {
-  prep_non_filename_text ();
   /* Avoid following symbolic links when possible.  */
   if (color_indicator[C_ORPHAN].string != NULL
  || (color_indicator[C_MISSING].string != NULL
@@ -1192,7 +1200,7 @@
 }
 
   /* Restore default color before exiting */
-  if 

Re: ls --color feature request: ordinary files uncoloured

[Ed Avis]

e = C_FILE;
@@ -3406,16 +3415,32 @@
}
}
 }
-
-  put_indicator (&color_indicator[C_LEFT]);
-  put_indicator (ext ? &(ext->seq) : &color_indicator[type]);
-  put_indicator (&color_indicator[C_RIGHT]);
+  
+  {
+const struct bin_str *const s
+  = ext ? &(ext->seq) : &color_indicator[type];
+if (s->string != NULL)
+  {
+   put_indicator (&color_indicator[C_LEFT]);
+   put_indicator (s);
+   put_indicator (&color_indicator[C_RIGHT]);
+   return true;
+  }
+else
+  return false;
+  }
 }
 
 /* Output a color indicator (which may contain nulls).  */
 static void
 put_indicator (const struct bin_str *ind)
 {
+  if (! used_color)
+{
+  used_color = true;
+  prep_non_filename_text ();
+}
+
   register int i;
   register const char *p;
 
@@ -3431,6 +3456,12 @@
 static int
 put_indicator_direct (const struct bin_str *ind)
 {
+  if (! used_color)
+{
+  used_color = true;
+  prep_non_filename_text ();
+}
+
   size_t len;
   if (ind->len <= 0)
 return 0;
diff -ru coreutils-5.0.91/tests/ls-2/tests coreutils-5.0.91.new/tests/ls-2/tests
--- coreutils-5.0.91/tests/ls-2/tests   2003-04-08 11:36:44.0 +0100
+++ coreutils-5.0.91.new/tests/ls-2/tests   2004-01-24 17:58:31.098548392 +
@@ -32,6 +32,7 @@
$ENV{LS_COLORS}='ln=01;36:di=01;34:or=40;31;01'
}};
 my $unlink_d = {POST => sub {unlink 'd' or die "d: $!\n"}};
+my $creat_d = {PRE => sub {local *FH; open(FH, '>d') or die "d: $!\n"}};
 
 sub make_j_d ()
 {
@@ -85,6 +86,9 @@
 {OUT => "\e[0m\e[01;[EMAIL PROTECTED]"},
  $slink_d, $unlink_d],
 
+ # A listing with only plain files should have no color sequences at all.
+ ['no-color', '--color=always d', {OUT => "d\n"}, $creat_d, $unlink_d],
+
  # Test for a bug that was introduced in coreutils-4.5.4; fixed in 4.5.5.
  # To demonstrate it, the file in question (with executable bit set)
  # must not be a command line argument.


-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: rm -f and unexecutable directories

[Ed Avis]

On Sat, 8 Nov 2003, Bob Proulx wrote:

[rm and unexecutable directories]

>>the other way is to chmod every file before doing anything with
>>it.

>But the directory containing the file would need the chmod, not the
>file itself.

Sorry - I meant to say chmod every directory before doing anything
with it, and by 'doing anything' I meant either removing it or
preparing to remove it.

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: rm -f and unexecutable directories

[Ed Avis]

On Sat, 8 Nov 2003, Bob Proulx wrote:

>>>>% mkdir -p fred/jim
>>>>% chmod a-x fred/jim
>>>>% rm -rf fred
>>>>rm: cannot chdir from `fred' to `jim': Permission denied
>>>
>>>But by the action of your chmod you have specifically requested that
>>>you do not want those files removed!
>>
>>But by specifying the -f option I (thought I had) specifically
>>requested that they _should_ be removed after all!
>
>Not quite.  You just pre-answered the questions to be asked as yes.

Yup.  I expected that -f would 'force' removal, but in fact it
doesn't.

>Here is what the info page says.
>
>`-f'
>`--force'
> Ignore nonexistent files and never prompt the user.  Ignore any
> previous `--interactive' (`-i') option.

I know that rm's behaviour is consistent with the info page and with
POSIX.  So I am not reporting a bug.  Instead I make two
observations: that the --force flag is perhaps misnamed, and that an
additional option to _really_ force things might be useful.

>Also, there really are multiple operations happening with the
>directory find'ing, chmod'ing and rm'ing.  These are not atomic
>operations.

True, but then neither is the normal action of rm -r.  It's possible
to have a race condition where you're removing files from a directory
at the same time someone else is creating them, and so the rm -r
fails.

>Here is what I was originally thinking about.  This one has been
>debated previously and can't be changed.
>
>  mkdir -p one/two/three
>  chmod -R a-w one
>  rm -rf one
>  rm: cannot remove directory `one/two/three': Permission denied
>  rm: cannot remove directory `one/two': Permission denied
>  rm: cannot remove directory `one': Directory not empty

Hmm.  Again this would be a candidate for a --really-force flag, if
one were added.  I know that the behaviour of -f cannot be changed.

>Of course all of the directories are removed in this case in spite of
>the inability to search the directory.  That is, the following works.
>
>  mkdir one
>  chmod a-x one
>  rmdir one
>
>So perhaps there is some room for change there.  Perhaps rm should
>attempt rmdir on the directory even though it can't look into it.

Hmm maybe, but not as a change to rm's current behaviour since as you
say that would break what people (and POSIX) expect.  It would have to
be part of some new option.  But if you were going to add such an
option, merely trying an rmdir() seems too weak to be worth bothering.

>>Yes - you could get the same effect by first doing 'chmod -R' and
>>then 'rm -rf', but by the same argument the -f flag to cp is
>>redundant because it just emulates rm followed by cp.
>
>Actually, no, not for the non-writable file case.  It just turns off
>the question.

According to cp(1):

   -f, --force
  if an existing destination file cannot  be  opened,
  remove it and try again

This is analogous to what I had in mind for rm: try some additional
operation (unlink, chmod, whatever) which will let the command
succeed.

In the case of cp, the -f flag does *not* simply stop a question being
asked.  It seems to do that, but also more importantly do an
additional step (unlink) if necessary.  For example:

% touch fred jim
% chmod a-w jim
% cp fred jim
cp: overwrite `jim', overriding mode 0444? y
cp: cannot create regular file `jim': Permission denied
% cp -f fred jim
[succeeds]

So the -f flag to cp is clearly not just a means to answer 'yes' to
some question.  For rm, as you say, it's different and -f is just
equivalent to lots of 'y' (plus ignoring files that don't exist).  But
the example of cp shows that adding a flag to 'do some extra stuff to
force the operation to happen' is not such a strange idea.

>The -f option does not perform any 'chmod' operations.  It just
>suppresses the artificially created message.  I say artificially
>created because the rm command as part of trying to be helpful goes
>out of its way to ask the user if they really want to remove the
>file solely based upon the clue that it is not writable.  I have
>always thought that behavior gratuitous.  It is trying to create a
>different model of the filesystem than the one that actually exists.

Agreed.  But it's too late to change now.

>>FWIW - what prompted me to suggest this feature was not that I had
>>chmodded files to deliberately stop them being removed.  It was
>>just a slightly odd tarball (not generated on a Unix system, I
>>expect) which created a directory lacking execute permission.  
>>Then I tried to use rm to clean up, and was surprised that even
>>with the --force option it wasn't able to do the job.
>
>At least that is not something that happens every day!  :-)

Nonetheless there should be some program which is able to delete files
even in cases like the above, and if not rm then what?

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: rm -f and unexecutable directories

[Ed Avis]

On Sat, 8 Nov 2003, Jim Meyering wrote:

>>>> -F, --really-force
>>>> As --force but also change permissions if necessary.

>I looked into it a little, and am now even less enthusiastic. Doing
>it right would mean changes that are way too invasive. They'd have
>to handle failed chdir, opendir, readdir and retry after a chmod.

Well - that's one way to do it, the other way is to chmod every file
before doing anything with it.  But that might be slow (I haven't
benchmarked).

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: rm -f and unexecutable directories

[Ed Avis]

On Sat, 8 Nov 2003, Bob Proulx wrote:

>>% mkdir -p fred/jim
>>% chmod a-x fred/jim
>>% rm -rf fred
>>rm: cannot chdir from `fred' to `jim': Permission denied
>
>But by the action of your chmod you have specifically requested that
>you do not want those files removed!

But by specifying the -f option I (thought I had) specifically
requested that they _should_ be removed after all!  Compare:

% touch foo
% chmod a-w foo  
% rm foo
rm: remove write-protected regular empty file `foo'?
[C-c]
% rm -f foo
[removes the file without question]

The -f flag or similar 'force' option is there to overrule any
permissions and _force_ the files to be removed.  Or so you'd think.

>Changing this behavior would break a lot of safety that has been
>built into scripts over the years.

The behaviour cannot be changed because it would conflict with POSIX,
according to earlier messages on this list.  So the question is then
about the usefulness of a new flag 'really force', to override
permissions and remove things for certain.

Yes - you could get the same effect by first doing 'chmod -R' and then
'rm -rf', but by the same argument the -f flag to cp is redundant
because it just emulates rm followed by cp.  I feel it makes sense to
have forcing options built into the rm and cp commands themselves; of
course you don't get that behaviour unless you explicitly ask for it.

FWIW - what prompted me to suggest this feature was not that I had
chmodded files to deliberately stop them being removed.  It was just a
slightly odd tarball (not generated on a Unix system, I expect) which
created a directory lacking execute permission.  Then I tried to use
rm to clean up, and was surprised that even with the --force option it
wasn't able to do the job.

-- 
Ed Avis <[EMAIL PROTECTED]>







___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: rm -f and unexecutable directories

[Ed Avis]

On Sat, 8 Nov 2003, Jim Meyering wrote:

>>-F, --really-force
>>As --force but also change permissions if necessary.
>
>It's feasible.
>I'm not enthusiastic about this, but not strongly opposed either.

A few years ago there was a project called 'The Dammit Patch' to add a
--dammit flag to ln mv and rm.  I never downloaded a copy and now it
has disappeared off the web.  But it might have done something like
chmodding directories to remove them.

>Bear in mind that even with such an option, rm may still be unable
>to remove a file you own due to e.g., an ACL, attributes a la
>chattr,

I expect that as such things are found they could be added to the -F
code, so it becomes a general 'do everything possible to remove the
file'.

>or being on file system that's mounted read-only.

Hmm, well I wouldn't expect rm to go so far as remounting the
filesystem ;-).

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: rm -f and unexecutable directories

[Ed Avis]

On Fri, 7 Nov 2003, Jim Meyering wrote:

>>But since I own the directory I could change the permissions and then
>>remove it.  Shouldn't rm do this if I gave the 'force' option?

>rm may not do that. POSIX prohibits it.

In that case could I make a feature request for a new flag

-F, --really-force
As --force but also change permissions if necessary.

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

rm -f and unexecutable directories

[Ed Avis]

% mkdir -p fred/jim 
% chmod a-x fred/jim 
% rm -rf fred 
rm: cannot chdir from `fred' to `jim': Permission denied   

But since I own the directory I could change the permissions and then
remove it.  Shouldn't rm do this if I gave the 'force' option?  I
thought that would take all measures necessary.

After all, rm -f doesn't care about permissions on files before
removing them, so shouldn't it work equally well with directories?  
Even if it does have to chmod u+rx them behind the scenes.

% rm --version | head -1
rm (coreutils) 5.0 

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Feature-beg: --dry-run

[Ed Avis]

I have submitted a bug (feature request) to savannah
(<https://savannah.gnu.org/bugs/?func=detailbug&bug_id=4771&group_id=2613>)
but I don't think that is set up to gateway to the mailing list so I
thought I would also send a message to the list in case people want to
discuss it.

It would be handy if some of the coreutils (particularly cp and
mv) had a --dry-run option that tries to do everything short of
actually copying or moving the files.  The output of --dry-run
--verbose would be the same as the output of --verbose, as far as
possible.

The suggested name of the option is chosen for consistency with GNU
patch.

Myself I would find such an option useful for a wrapper program I am
writing around mv, which looks at the files being moved and writes a
.htaccess file for Apache to set up http redirects.  I would like it
to check for redirection loops before trying to move any files, and
the simplest way to do that would be to ask mv: if I did run you, what
files would you move?

Of course if --dry-run succeeds it would not be guaranteed that a
following real run of mv or cp would produce the same results, but it
would be good enough.

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

date(1) treats TZ '' differently from unset

[Ed Avis]

On a system where local time is +0100:

% (unset TZ; date +%z)
+0100
% (TZ= date +%z)
+

Are you sure this is correct?  I would have expected the empty string
for TZ to act the same as having that variable unset, or otherwise to
produce a warning that TZ was set to a bad value.

% date --version
date (coreutils) 5.0
Written by David MacKenzie.

Copyright (C) 2003 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.

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: date(1) treats TZ '' differently from unset

[Ed Avis]

On 10 Aug 2003, Paul Eggert wrote:

>>% (unset TZ; date +%z)
>>+0100
>>% (TZ= date +%z)
>>+

>This is a C library issue, not a coreutils issue, since coreutils
>simply repeats what the C library tells it.

What does POSIX say about date(1) and the TZ variable?

-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Patch for head: --show-truncated

[Ed Avis]

 }
+  else
+/* Shouldn't happen. */
+return 1;
+
+  if (! eof_bool)
+{
+  if (newline)
+   putc('\n', stdout);
+  printf (_("==> truncated %s <==\n"), filename);
+}
+
+  return 0;
+}
+
 static int
 head_bytes (const char *filename, int fd, uintmax_t bytes_to_write)
 {
@@ -135,6 +218,7 @@
   /* Need BINARY I/O for the byte counts to be accurate.  */
   SET_BINARY2 (fd, fileno (stdout));
 
+  enum tristate eof_knowledge = maybe;
   while (bytes_to_write)
 {
   size_t bytes_read;
@@ -147,11 +231,20 @@
  return 1;
}
   if (bytes_read == 0)
-   break;
+   {
+ eof_knowledge = yes;
+ break;
+   }
   if (fwrite (buffer, 1, bytes_read, stdout) == 0)
error (EXIT_FAILURE, errno, _("write error"));
   bytes_to_write -= bytes_read;
 }
+  if (show_truncation)
+if (maybe_show_truncation (filename, fd, eof_knowledge, 1))
+  {
+   error (0, 0, _("don't know if %s was truncated or not"), filename);
+   return 1;
+  }
   return 0;
 }
 
@@ -163,6 +256,7 @@
   /* Need BINARY I/O for the byte counts to be accurate.  */
   SET_BINARY2 (fd, fileno (stdout));
 
+  enum tristate eof_knowledge = maybe;
   while (lines_to_write)
 {
   size_t bytes_read = safe_read (fd, buffer, BUFSIZE);
@@ -174,7 +268,10 @@
  return 1;
}
   if (bytes_read == 0)
-   break;
+   {
+ eof_knowledge = yes;
+ break;
+   }
   while (bytes_to_write < bytes_read)
if (buffer[bytes_to_write++] == '\n' && --lines_to_write == 0)
  {
@@ -194,7 +291,15 @@
  }
   if (fwrite (buffer, 1, bytes_to_write, stdout) == 0)
error (EXIT_FAILURE, errno, _("write error"));
+  if (bytes_to_write < bytes_read)
+   eof_knowledge = no;
 }
+  if (show_truncation)
+if (maybe_show_truncation (filename, fd, eof_knowledge, 0))
+  {
+   error (0, 0, _("don't know if %s was truncated or not"), filename);
+   return 1;
+  }
   return 0;
 }
 
@@ -292,6 +397,7 @@
   have_read_stdin = 0;
 
   print_headers = 0;
+  show_truncation = 0;
 
   if (1 < argc && argv[1][0] == '-' && ISDIGIT (argv[1][1]))
 {
@@ -370,7 +476,7 @@
 
 }
 
-  while ((c = getopt_long (argc, argv, "c:n:qv", long_options, NULL)) != -1)
+  while ((c = getopt_long (argc, argv, "c:n:qvV", long_options, NULL)) != -1)
 {
   switch (c)
{
@@ -395,6 +501,10 @@
  header_mode = always;
  break;
 
+   case 'V':
+ show_truncation = 1;
+ break;
+
case_GETOPT_HELP_CHAR;
 
case_GETOPT_VERSION_CHAR (PROGRAM_NAME, AUTHORS);
diff -ru coreutils-5.0/tests/head/Test.pm coreutils-5.0-new/tests/head/Test.pm
--- coreutils-5.0/tests/head/Test.pm2002-02-17 22:39:47.0 +
+++ coreutils-5.0-new/tests/head/Test.pm2003-07-06 12:37:42.0 +0100
@@ -50,6 +50,22 @@
 ['no-oct-2', '-010', "\n"x12, "\n"x10, 0],
 ['no-oct-3', '-n 08', "\n"x12, "\n"x8, 0],
 ['no-oct-4', '-c 08', "\n"x12, "\n"x8, 0],
+
+# Test -V option - head should notice whether it got to EOF.
+['eof-1', '-V', "1\n2\n3\n4\n5\n6\n7\n8\n9", "1\n2\n3\n4\n5\n6\n7\n8\n9", 0],
+['eof-2', '-V', "1\n2\n3\n4\n5\n6\n7\n8\n9\n", "1\n2\n3\n4\n5\n6\n7\n8\n9\n", 0],
+['eof-3', '-V', "1\n2\n3\n4\n5\n6\n7\n8\n9\n0", "1\n2\n3\n4\n5\n6\n7\n8\n9\n0", 0],
+['eof-4', '-V', "1\n2\n3\n4\n5\n6\n7\n8\n9\n0\n", "1\n2\n3\n4\n5\n6\n7\n8\n9\n0\n", 
0],
+# This requires the right locale - hope that's okay.
+['eof-5', '-V', "1\n2\n3\n4\n5\n6\n7\n8\n9\n0\n1",
+ "1\n2\n3\n4\n5\n6\n7\n8\n9\n0\n==> truncated ./eof-5.I <==\n", 0],
+['eof-6', '-V', "1\n2\n3\n4\n5\n6\n7\n8\n9\n0\n1\n",
+ "1\n2\n3\n4\n5\n6\n7\n8\n9\n0\n==> truncated ./eof-6.I <==\n", 0],
+# Test -V with --bytes.
+['eof-7', '-V --bytes 3', "12", "12", 0],
+['eof-8', '-V --bytes 3', "123", "123", 0],
+['eof-9', '-V --bytes 3', "1234", "123\n==> truncated ./eof-9.I <==\n", 0],
+['eof-10', '-V --bytes 3', "12345", "123\n==> truncated ./eof-10.I <==\n", 0],
 );
 
 sub test_vector


-- 
Ed Avis <[EMAIL PROTECTED]>




___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils