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
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.
*
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:
Update of bug #5477 (project coreutils):
Status:None = Fixed
___
Follow-up Comment #1:
Thanks for the report.
This is fixed in coreutils-6.0.
Update of bug #15043 (project coreutils):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?15043
___
Update of bug #5477 (project coreutils):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?5477
___
Update of bug #12651 (project coreutils):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?12651
___
Update of bug #5971 (project coreutils):
Status:None = Wont Fix
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Thanks for the
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
[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
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
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:
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
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
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
[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
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
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
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
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;;
+
20 matches
Mail list logo
