Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Jim Meyering [EMAIL PROTECTED] wrote: mwoehlke [EMAIL PROTECTED] wrote: Mike Frysinger wrote: On Thursday 24 August 2006 17:03, mwoehlke wrote: https://savannah.gnu.org/bugs/?func=detailitemitem_id=15043 Is this going to get fixed, or what? There is a trivial fix available, it just needs someone that knows how to make it 'Linux-only'. #if __linux__ foo #endif -mike Ok, thanks. I a: wasn't sure of a macro that would be defined on Linux (is there a list of these things anywhere? Preferably covering most major platforms?), and b: wasn't sure if people here appreciated such patches. If #ifdef is OK, this should do it (works for me with 5.97 and 6.1): Thanks for pursuing that. No #ifdef needed. Here's the patch I'll probably commit (destined for the trunk): I've checked this in on the trunk: 2006-08-26 Jim Meyering [EMAIL PROTECTED] ls --color would highlight other-writable and sticky directories no differently than regular directories on a file system with dirent.d_type support. * NEWS: Say the above. * src/ls.c (gobble_file): With --color, also stat the file when we know it is a directory. Derived from an anonymous one-line fix and bug report: https://savannah.gnu.org/bugs/?15043. * tests/ls/color-dtype-dir: New file. Test for the above fix. * tests/ls/Makefile.am (TESTS): Add color-dtype-dir. Index: NEWS === RCS file: /fetish/cu/NEWS,v retrieving revision 1.410 retrieving revision 1.411 diff -u -p -u -r1.410 -r1.411 --- NEWS23 Aug 2006 23:38:27 - 1.410 +++ NEWS26 Aug 2006 06:46:17 - 1.411 @@ -9,6 +9,13 @@ GNU coreutils NEWS in README-cvs. Although this represents a large change to the infrastructure, it should cause no change in the actual tools. +** Bug fixes + + ls --color would highlight other-writable and sticky directories + no differently than regular directories on a file system with + dirent.d_type support. + + * Major changes in release 6.1 (2006-08-19) [unstable] ** Changes in behavior Index: src/ls.c === RCS file: /fetish/cu/src/ls.c,v retrieving revision 1.438 retrieving revision 1.439 diff -u -p -u -r1.438 -r1.439 --- src/ls.c23 Aug 2006 19:19:02 - 1.438 +++ src/ls.c26 Aug 2006 06:46:17 - 1.439 @@ -2531,6 +2531,10 @@ gobble_file (char const *name, enum file if (command_line_arg || format_needs_stat + /* When coloring a directory (we may know the type from +direct.d_type), we have to stat it in order to indicate +sticky and/or other-writable attributes. */ + || (type == directory print_with_color) || (print_inode (inode == NOT_AN_INODE_NUMBER /* When dereferencing symlinks, the inode must come from Index: tests/ls/color-dtype-dir === RCS file: tests/ls/color-dtype-dir diff -N tests/ls/color-dtype-dir --- /dev/null 1 Jan 1970 00:00:00 - +++ tests/ls/color-dtype-dir26 Aug 2006 06:46:18 - 1.1 @@ -0,0 +1,70 @@ +#!/bin/sh +# Ensure ls --color properly colors other-writable and sticky directories. +# Before coreutils-6.2, this test would fail, coloring all three +# directories the same as the first one -- but only on a file system +# with dirent.d_type support. + +# Copyright (C) 2006 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 of the License, 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, Inc., 51 Franklin Street, Fifth Floor, Boston, MA +# 02110-1301, USA. + +if test $VERBOSE = yes; then + set -x + ls --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 +trap '(exit $?); exit $?' 1 2 13 15 + +framework_failure=0 +mkdir -p $tmp || framework_failure=1 +cd $tmp || framework_failure=1 + +mkdir d other-writable sticky || framework_failure=1 +chmod o+w other-writable || framework_failure=1 +chmod o+t sticky || framework_failure=1 + +if test $framework_failure = 1; then + echo $0: failure in testing framework 12 + (exit 1); exit 1 +fi + +fail=0 + +# Ensure that LS_COLORS is set to known values. +eval `dircolors -b` + +ls --color=always out || fail=1 +cat -A
omitting -DHAVE_CONFIG_H from coreutils
I installed the following to remove the -DHAVE_CONFIG_H clutter
from make output.
2006-08-25 Paul Eggert [EMAIL PROTECTED]
* .x-sc_no_if_have_config_h: Remove; no longer needed.
* .x-sc_prohibit_assert_without_use: Remove; it was empty.
* .x-sc_two_space_separator_in_usage: Likewise.
* Makefile.maint (sc_no_have_config_h): Renamed from
sc_no_if_have_config_h, since it now checks that HAVE_CONFIG_H
is absent everywhere.
* bootstrap.conf (gnulib_modules): Add config-h.
* src/shred.c: Include config.h unconditionally, since
we now assume config.h exists.
* src/dircolors.c: Likewise.
* lib/euidaccess-stat.c: Include config.h unconditionally, since
we now assume config.h exists.
* lib/fchmodat.c: Likewise.
* lib/fd-reopen.c: Likewise.
* lib/fdopendir-glibc.c: Likewise.
* lib/memxfrm.c: Likewise.
* lib/printf-parse.c: Likewise.
* lib/rand-isaac.c: Likewise.
* lib/randint.c: Likewise.
* lib/randperm.c: Likewise.
* lib/randread.c: Likewise.
* lib/root-dev-ino.c: Likewise.
* lib/sha256.c: Likewise.
* lib/sha512.c: Likewise.
* lib/stdopen.c: Likewise.
* lib/strintcmp.c: Likewise.
* lib/strnumcmp.c: Likewise.
* lib/t-chdir-long: Likewise.
* lib/tsearch.c: Likewise.
* lib/unicodeio.c: Likewise.
* lib/vasnprintf.c: Likewise.
* lib/xfts.c: Likewise.
* lib/xmemxfrm.c: Likewise.
Index: Makefile.maint
===
RCS file: /fetish/cu/Makefile.maint,v
retrieving revision 1.247
diff -p -u -r1.247 Makefile.maint
--- Makefile.maint 22 Aug 2006 19:36:23 - 1.247
+++ Makefile.maint 26 Aug 2006 06:54:47 -
@@ -140,9 +140,9 @@ sc_file_system:
'rewrite to use file system' 12;\
exit 1; } || :
-sc_no_if_have_config_h:
- @grep -n '^# *if HAVE_CONFIG_H' $$($(CVS_LIST_EXCEPT))\
- { echo '$(ME): found use of #if HAVE_CONFIG_H; use #ifdef'\
+sc_no_have_config_h:
+ @grep -n 'HAVE''_CONFIG_H' $$($(CVS_LIST_EXCEPT)) \
+ { echo '$(ME): found use of HAVE''_CONFIG_H; remove' \
12; exit 1; } || :
# Nearly all .c files must include config.h.
Index: bootstrap.conf
===
RCS file: /fetish/cu/bootstrap.conf,v
retrieving revision 1.4
diff -p -u -r1.4 bootstrap.conf
--- bootstrap.conf 25 Aug 2006 23:30:57 - 1.4
+++ bootstrap.conf 26 Aug 2006 06:54:47 -
@@ -38,7 +38,8 @@ gnulib_modules=
$avoided_gnulib_modules
$obsolete_gnulib_modules
acl alloca argmatch assert backupfile base64 c-strtod
- c-strtold calloc canon-host canonicalize chown cloexec configmake
+ c-strtold calloc canon-host canonicalize chown cloexec
+ config-h configmake
closeout cycle-check d-ino d-type diacrit dirfd dirname dup2
error euidaccess exclude exitfail fcntl-safer fdl file-type
fileblocks filemode filenamecat fnmatch-gnu fopen-safer
Index: lib/euidaccess-stat.c
===
RCS file: /fetish/cu/lib/euidaccess-stat.c,v
retrieving revision 1.1
diff -p -u -r1.1 euidaccess-stat.c
--- lib/euidaccess-stat.c 20 Nov 2005 08:51:10 - 1.1
+++ lib/euidaccess-stat.c 26 Aug 2006 06:54:48 -
@@ -2,7 +2,7 @@
This function is probably useful only for choosing whether to issue
a prompt in an implementation of POSIX-specified rm.
- Copyright (C) 2005 Free Software Foundation, Inc.
+ Copyright (C) 2005, 2006 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
@@ -20,9 +20,7 @@
/* Adapted for use in GNU remove.c by Jim Meyering. */
-#ifdef HAVE_CONFIG_H
-# include config.h
-#endif
+#include config.h
#include euidaccess-stat.h
Index: lib/fchmodat.c
===
RCS file: /fetish/cu/lib/fchmodat.c,v
retrieving revision 1.2
diff -p -u -r1.2 fchmodat.c
--- lib/fchmodat.c 15 Aug 2006 19:17:30 - 1.2
+++ lib/fchmodat.c 26 Aug 2006 06:54:48 -
@@ -17,9 +17,7 @@
/* written by Jim Meyering */
-#ifdef HAVE_CONFIG_H
-# include config.h
-#endif
+#include config.h
#include openat.h
#include dirname.h /* solely for definition of IS_ABSOLUTE_FILE_NAME */
Index: lib/fd-reopen.c
===
RCS file: /fetish/cu/lib/fd-reopen.c,v
retrieving revision 1.3
diff -p -u -r1.3 fd-reopen.c
--- lib/fd-reopen.c 30 Oct 2005 21:44:31 - 1.3
+++ lib/fd-reopen.c 26 Aug 2006 06:54:48 -
@@ -1,6 +1,6 @@
/* Invoke open, but return
[bug #15043] ls assigns colors inconsistently
Update of bug #15043 (project coreutils): Status:None = Fixed ___ Follow-up Comment #4: Thanks again. I've just checked in a fix for coreutils-6.2: http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/7917 ___ Reply to this item at: http://savannah.gnu.org/bugs/?15043 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #5477] mv --backup some_directory cannot overwrite directory
Update of bug #5477 (project coreutils): Status:None = Fixed ___ Follow-up Comment #1: Thanks for the report. This is fixed in coreutils-6.0. ___ Reply to this item at: http://savannah.gnu.org/bugs/?5477 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #15043] ls assigns colors inconsistently
Update of bug #15043 (project coreutils): Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?15043 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #5477] mv --backup some_directory cannot overwrite directory
Update of bug #5477 (project coreutils): Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?5477 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #12651] sort Feature request: random order
Update of bug #12651 (project coreutils): Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?12651 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #5971] RFE: a trashcan command
Update of bug #5971 (project coreutils): Status:None = Wont Fix Open/Closed:Open = Closed ___ Follow-up Comment #2: Thanks for the offer, but I don't see the need for a new program. You can do most of what you want by aliasing 'cn' to mv --backup=numbered /.../your-trash-directory. ___ Reply to this item at: http://savannah.gnu.org/bugs/?5971 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #5971] RFE: a trashcan command
Follow-up Comment #3, bug #5971 (project coreutils): Agreed - it's no longer required now that coreutils bug 5477 has been fixed. That said, might I suggest appending something like the following to the man page of rm, so that the hint is more widely available: -- Unthinking use of rm is dangerous, (especially on systems where it isn't aliased to rm -i, or without current backups). A trashCaN command, cn, may be implemented as a bash alias: alias cn=mv --backup=numbered -- ~/your-trash-directory [In recent KDE/GNOME, the trash directory is located in ~/.local/share/Trash/files/] -- ___ Reply to this item at: http://savannah.gnu.org/bugs/?5971 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
[EMAIL PROTECTED] (Bob Proulx) wrote: Jim Meyering wrote: I've checked this in on the trunk: * tests/ls/color-dtype-dir: New file. Test for the above fix. I am seeing this test failure. make[3]: Entering directory `/usr/local/build/coreutils/i686-gnu-linux-coreutils/build/tests/ls' out exp differ: char 5, line 1 1,4c1,4 ^[[0m^[[01;34md^[[0m$ ^[[34;42mother-writable^[[0m$ ^[[0mout^[[0m$ ^[[37;44msticky^[[0m$ --- ^[[00m^[[01;34md^[[00m$ ^[[34;42mother-writable^[[00m$ ^[[00mout^[[00m$ ^[[37;44msticky^[[00m$ FAIL: color-dtype-dir Hi Bob, Thanks for the quick report! I wonder why I can't reproduce it here... Anyhow, I think I know at least part of the reason for the difference. So this patch might fix it for you. Does it? 2006-08-26 Jim Meyering [EMAIL PROTECTED] This test was failing in some environments. * tests/ls/color-dtype-dir: Don't rely on eval `dircolors -b` to set LS_COLORS in the environment. * tests/envvar-check: Instead, ensure that LS_COLORS is not set. Reported by Bob Proulx. Index: tests/ls/color-dtype-dir === RCS file: /fetish/cu/tests/ls/color-dtype-dir,v retrieving revision 1.1 diff -u -r1.1 color-dtype-dir --- tests/ls/color-dtype-dir26 Aug 2006 06:46:18 - 1.1 +++ tests/ls/color-dtype-dir26 Aug 2006 18:24:56 - @@ -48,19 +48,16 @@ fail=0 -# Ensure that LS_COLORS is set to known values. -eval `dircolors -b` - ls --color=always out || fail=1 cat -A out o1 || fail=1 echo o1 || fail=1 mv o1 out || fail=1 cat \EOF exp || fail=1 -^[[00m^[[01;34md^[[00m$ -^[[34;42mother-writable^[[00m$ -^[[00mout^[[00m$ -^[[37;44msticky^[[00m$ +^[[0m^[[01;34md^[[0m$ +^[[34;42mother-writable^[[0m$ +^[[0mout^[[0m$ +^[[37;44msticky^[[0m$ ^[[m EOF Index: tests/envvar-check === RCS file: /fetish/cu/tests/envvar-check,v retrieving revision 1.8 diff -u -r1.8 envvar-check --- tests/envvar-check 17 Aug 2006 19:58:24 - 1.8 +++ tests/envvar-check 26 Aug 2006 18:24:21 - @@ -33,6 +33,7 @@ DF_BLOCK_SIZE DU_BLOCK_SIZE LS_BLOCK_SIZE + LS_COLORS POSIXLY_CORRECT SIMPLE_BACKUP_SUFFIX TIME_STYLE ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
bootstrap change to not require wget, for the buildbot
I observed the test failure due to the recent dircolors fix on
Solaris 10, so it's not just an HP-UX thing. Jim is the expert in
that area, though.
I also noticed that the buildbot was failing on ia64 hpux11.23 hpcc
32-bit and 64-bit due to a failed configure, because these platforms
lacked 'wget'. 'wget' is needed only for translations, and I think
it's better to keep going and build with zero translations if 'wget'
isn't working, so I installed the following patch to 'bootstrap':
2006-08-26 Paul Eggert [EMAIL PROTECTED]
* bootstrap (get_translations): Skip this if WGET_COMMAND is empty.
Fail if the first echo fails. Suppress diagnostics from ls po/*.po
since there might not be any .po files.
(WGET_COMMAND): Set to empty if wget doesn't
seem to be available. Don't export; shouldn't be needed.
--- bootstrap 23 Aug 2006 18:09:40 - 1.4
+++ bootstrap 26 Aug 2006 18:32:56 -
@@ -159,9 +159,13 @@ get_translations() {
subdir=$1
domain=$2
- echo $0: getting translations into $subdir for $domain...
- (cd $subdir rm -f dummy `ls | sed -n '/\.gmo$/p; /\.po/p'`)
+ case $WGET_COMMAND in
+ '')
+echo $0: wget not available; skipping translations;;
+ ?*)
+echo $0: getting translations into $subdir for $domain...
+(cd $subdir rm -f dummy `ls | sed -n '/\.gmo$/p; /\.po/p'`)
$WGET_COMMAND -O $subdir/$domain.html $TP_URL$domain
sed -n
's|.*http://[^]*/translation/teams/PO/\([^/]*\)/'$domain'-\([^/]*\)\.[^.]*\.po.*|\1.\2|p'
$subdir/$domain.html |
@@ -181,25 +185,26 @@ get_translations() {
printf rm -f %s/%s.po; }; } \n, subdir, lang
}
END { print : }
- ' | sh
- ls $subdir/*.po | sed 's|.*/||; s|\.po$||' $subdir/LINGUAS
- rm $subdir/$domain.html
+' | sh;;
+ esac
+ ls $subdir/*.po 2/dev/null |
+sed 's|.*/||; s|\.po$||' $subdir/LINGUAS
+ rm -f $subdir/$domain.html
}
case $SKIP_PO in
'')
case `wget --help` in
*'--no-cache'*)
-no_cache='--no-cache';;
+WGET_COMMAND='wget -nv --no-cache';;
*'--cache=on/off'*)
-no_cache='--cache=off';;
+WGET_COMMAND='wget -nv --cache=off';;
+ *'--non-verbose'*)
+WGET_COMMAND='wget -nv';;
*)
-no_cache='';;
+WGET_COMMAND='';;
esac
- WGET_COMMAND=wget -nv $no_cache
- export WGET_COMMAND
-
get_translations po $package || exit
if test -d runtime-po; then
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv: minor bug fix with --verbose --backup and directories
This fixes a minor inconsistency.
With --verbose, mv would report the backup file name
for a non-directory destination, but not for directories:
$ rm -rf a b; touch a b; mv --verbose --backup -T a b
`a' - `b' (backup: `b.~2~')
^
But for directories, no (backup: NAME) suffix:
$ rm -rf a b; mkdir a b; mv --verbose --backup -T a b
`a' - `b'
$ ls -d b*~
b.~1~
Note that although I mentioned mv's -T option below,
you can reproduce the problem without it:
mkdir -p A B/A; mv --verbose --backup A B
2006-08-26 Jim Meyering [EMAIL PROTECTED]
Fix mv --verbose --backup so its output includes the
(backup: foo.~1~) suffix also when backing up a directory.
* NEWS: Report this bug fix.
* src/copy.c (emit_verbose): New function, factored out of...
(copy_internal): ...here. Use the new function.
* tests/mv/backup-dir: Test for the above fix.
* tests/mv/Makefile.am (TESTS): Add backup-dir.
Index: NEWS
===
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.411
diff -u -r1.411 NEWS
--- NEWS26 Aug 2006 06:46:17 - 1.411
+++ NEWS26 Aug 2006 14:22:59 -
@@ -15,6 +15,9 @@
no differently than regular directories on a file system with
dirent.d_type support.
+ mv -T --verbose --backup=t A B now prints the (backup: B.~1~)
+ suffix when A and B are directories as well as when they are not.
+
* Major changes in release 6.1 (2006-08-19) [unstable]
Index: src/copy.c
===
RCS file: /fetish/cu/src/copy.c,v
retrieving revision 1.205
diff -u -r1.205 copy.c
--- src/copy.c 19 Aug 2006 14:01:30 - 1.205
+++ src/copy.c 26 Aug 2006 14:12:08 -
@@ -933,6 +933,18 @@
! yesno ()));
}
+/* Print --verbose output on standard output, e.g. `new' - `old'.
+ If BACKUP_DST_NAME is non-NULL, then also indicate that it is
+ the name of a backup file. */
+static void
+emit_verbose (char const *src, char const *dst, char const *backup_dst_name)
+{
+ printf (%s - %s, quote_n (0, src), quote_n (1, dst));
+ if (backup_dst_name)
+printf (_( (backup: %s)), quote (backup_dst_name));
+ putchar ('\n');
+}
+
/* Copy the file SRC_NAME to the file DST_NAME. The files may be of
any type. NEW_DST should be true if the file DST_NAME cannot
exist because its parent directory was just created; NEW_DST should
@@ -944,7 +956,6 @@
Set *COPY_INTO_SELF if SRC_NAME is a parent of (or the
same as) DST_NAME; otherwise, clear it.
Return true if successful. */
-
static bool
copy_internal (char const *src_name, char const *dst_name,
bool new_dst,
@@ -1169,9 +1180,7 @@
}
}
- bool backup_directories = true;
- if (x-backup_type != no_backups
- (!S_ISDIR (dst_sb.st_mode) || backup_directories))
+ if (x-backup_type != no_backups)
{
char *tmp_backup = find_backup_file_name (dst_name,
x-backup_type);
@@ -1242,12 +1251,7 @@
directory. So --verbose should not announce anything until we're
sure we'll create a directory. */
if (x-verbose !S_ISDIR (src_type))
-{
- printf (%s - %s, quote_n (0, src_name), quote_n (1, dst_name));
- if (backup_succeeded)
- printf (_( (backup: %s)), quote (dst_backup));
- putchar ('\n');
-}
+emit_verbose (src_name, dst_name, backup_succeeded ? dst_backup : NULL);
/* Associate the destination file name with the source device and inode
so that if we encounter a matching dev/ino pair in the source tree
@@ -1362,7 +1366,9 @@
if (rename (src_name, dst_name) == 0)
{
if (x-verbose S_ISDIR (src_type))
- printf (%s - %s\n, quote_n (0, src_name), quote_n (1, dst_name));
+ emit_verbose (src_name, dst_name,
+ backup_succeeded ? dst_backup : NULL);
+
if (rename_succeeded)
*rename_succeeded = true;
@@ -1526,7 +1532,7 @@
remember_copied (dst_name, dst_sb.st_ino, dst_sb.st_dev);
if (x-verbose)
- printf (%s - %s\n, quote_n (0, src_name), quote_n (1, dst_name));
+ emit_verbose (src_name, dst_name, NULL);
}
/* Are we crossing a file system boundary? */
Index: tests/mv/backup-dir
===
RCS file: tests/mv/backup-dir
diff -N tests/mv/backup-dir
--- /dev/null 1 Jan 1970 00:00:00 -
+++ tests/mv/backup-dir 26 Aug 2006 15:52:30 -
@@ -0,0 +1,57 @@
+#!/bin/sh
+# Ensure mv --verbose --backup works the same for dirs and non-dirs.
+
+# Copyright (C) 2006 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
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Jim Meyering [EMAIL PROTECTED] wrote: ... 2006-08-26 Jim Meyering [EMAIL PROTECTED] This test was failing in some environments. * tests/ls/color-dtype-dir: Don't rely on eval `dircolors -b` to set LS_COLORS in the environment. * tests/envvar-check: Instead, ensure that LS_COLORS is not set. Reported by Bob Proulx. FYI: I've gone ahead and checked that in. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Jim Meyering wrote: Thanks for the quick report! I wonder why I can't reproduce it here... I think you identified the problem as being associated with the LS_COLORS variable. I am running with 'env -i ...stuff...' and so LS_COLORS is not set in my build environment prior to building and testing. The value is affecting the behavior. Anyhow, I think I know at least part of the reason for the difference. So this patch might fix it for you. Does it? 2006-08-26 Jim Meyering [EMAIL PROTECTED] This test was failing in some environments. * tests/ls/color-dtype-dir: Don't rely on eval `dircolors -b` to set LS_COLORS in the environment. * tests/envvar-check: Instead, ensure that LS_COLORS is not set. Reported by Bob Proulx. Yes. That solves the problem. Thanks! Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bootstrap change to not require wget, for the buildbot
Paul Eggert wrote: I observed the test failure due to the recent dircolors fix on Solaris 10, so it's not just an HP-UX thing. Jim is the expert in that area, though. I actually observed it on all platforms and reported the results from my Debian amd64 desktop. (shrug) In any case the fix to unset LS_COLORS in envvar-check to prevent environment leakage seems like a good answer. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
[EMAIL PROTECTED] (Bob Proulx) wrote: Jim Meyering wrote: Thanks for the quick report! I wonder why I can't reproduce it here... I think you identified the problem as being associated with the LS_COLORS variable. I am running with 'env -i ...stuff...' and so Ah ha! With env -i, there would be no TERM setting, so dircolors -b would output this: LS_COLORS=''; export LS_COLORS So another fix would have been to set e.g., TERM=xterm in the environment. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #17540] cp: cannot backup `./.': Device or resource busy
URL: http://savannah.gnu.org/bugs/?17540 Summary: cp: cannot backup `./.': Device or resource busy Project: GNU Core Utilities Submitted by: schwab Submitted on: Samstag 26.08.2006 um 23:11 Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: $ cp --version | head -1 cp (GNU coreutils) 6.2-cvs $ mkdir x y $ cd y $ cp -ab ../x/. . cp: cannot backup `./.': Device or resource busy ___ Reply to this item at: http://savannah.gnu.org/bugs/?17540 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.1: needs 'ls' patch (bug #15043)
Jim Meyering wrote: Bob Proulx wrote: I think you identified the problem as being associated with the LS_COLORS variable. I am running with 'env -i ...stuff...' and so Ah ha! With env -i, there would be no TERM setting, so dircolors -b would output this: LS_COLORS=''; export LS_COLORS Yes. That looks like it. So another fix would have been to set e.g., TERM=xterm in the environment. Does the test require a TERM setting to obtain the desired coverage? Automated builds for things like buildbots, and automated distro builds of debs and rpms won't normally have a terminal associated with them. Should I try to test both with and with a terminal? Using something like 'screen' or 'expect' it should be possible to create a terminal environment in the background fairly easily. But I don't think it should be required for the main build and test. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [EMAIL PROTECTED]: Re: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039)]
Martin Pitt [EMAIL PROTECTED] writes: I do not see the issue for mkfifo -- what can possibly go wrong with open()ing and fchmod()ing a freshly created FIFO? If mkfifo opens the FIFO for reading, and some other process then opens the FIFO for writing without O_NONBLOCK, the other process will assume that the FIFO is ready for business and has a reader, even though it doesn't really. Anyway, this issue is no longer relevant for mkfifo or mknod. coreutils 6.1 mkfifo does not use chmod (or fchmod or lchmod or whatever). So its mkfifo is safe (in the sense described in the original bug report), and the patch is irrelevant for it. Likewise for mknod. Only mkdir is still unsafe. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
bootstrap typo fix
I installed this to fix a think-o in my previous change:
--- bootstrap 26 Aug 2006 18:33:08 - 1.5
+++ bootstrap 27 Aug 2006 03:33:25 -
@@ -185,7 +185,7 @@ get_translations() {
printf rm -f %s/%s.po; }; } \n, subdir, lang
}
END { print : }
-' | sh;;
+' | WGET_COMMAND=$WGET_COMMAND sh;;
esac
ls $subdir/*.po 2/dev/null |
sed 's|.*/||; s|\.po$||' $subdir/LINGUAS
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
