Re: avoid mkdir/selinux failure when mknod is a shell built-in
Hello! On Wed, Apr 16, 2008 at 02:30:57PM +0200, Jim Meyering wrote: Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 4/16/2008 2:33 AM: | This test would fail not only because the built-in mknod | doesn't support -Z, but because it doesn't know about 'p' pipes. | | tests: avoid mkdir/selinux failure when mknod is a shell built-in | * tests/mkdir/selinux: Skip the mknod test if it's a built-in. Couldn't you try to defeat the shell builtin by using a subshell and exec to force the PATH lookup? For example, on bash: $ printf --version | head -n1 bash: printf: --: invalid option printf: usage: printf [-v var] format [arguments] $ (exec printf --version) | head -n1 printf (GNU coreutils) 6.10 My first reaction was great! that looks much better. Unfortunately, the technique doesn't work with that shell: openbsd$ ./mknod --version|head -1 mknod (GNU coreutils) 6.10.188-7cb24 openbsd$ PATH=. /bin/sh -c 'mknod --version'|head -1 ^ exec? Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Wrong behavior of ``readlink -f''?
Hello! On Wed, Feb 13, 2008 at 08:53:01AM +0100, Jim Meyering wrote: Thomas Schwinge [EMAIL PROTECTED] wrote: $ readlink -f a/../a/f $ echo $? 1 ... readlink (GNU coreutils) 5.97 Why doesn't it resolve the latter case just as the previous ones? Because there are two symbolic links involved? Or two times the same one? Strange. Thanks for the report. That's because the code concluded it had encountered a cycle. The bug was fixed for coreutils-6.9.90 via a change to gnulib's canonicalize module. For posterity. I need this functionality in a somewhat portable build environment, so this is what I'm using in `configure.ac' now: #v+ [...] [# Test for a readlink bug, see # http://lists.gnu.org/archive/html/bug-coreutils/2008-02/msg00126.html.] AC_MSG_CHECKING([for a suitable ``readlink -f'' program]) [mkdir readlink-test mkdir readlink-test/a-long : readlink-test/a-long/f ln -s a-long readlink-test/a for READLINK_F in \ 'readlink -f' \ realpath \ false do if $READLINK_F /dev/null 21 \ readlink-test/a/../a/f then break fi done rm -rf readlink-test if [ $READLINK_F = false ] then] AC_MSG_RESULT([none found, using own replacement]) [READLINK_F='perl -e '\''use Cwd qw(abs_path); print abs_path $$ARGV[0];'\' else] AC_MSG_RESULT([$READLINK_F]) [fi] AC_SUBST([READLINK_F]) [...] #v- Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Wrong behavior of ``readlink -f''?
Hello! I'm a bit stumped with this behavior of ``readlink -f'', as it doesn't match what I had expected. #v+ [EMAIL PROTECTED]:~/tmp $ mkdir a-long [EMAIL PROTECTED]:~/tmp $ touch a-long/f [EMAIL PROTECTED]:~/tmp $ ln -s a-long a [EMAIL PROTECTED]:~/tmp $ readlink -f a/f /home/thomas/tmp/a-long/f [EMAIL PROTECTED]:~/tmp $ readlink -f a-long/../a/f /home/thomas/tmp/a-long/f [EMAIL PROTECTED]:~/tmp $ readlink -f a/../a-long/f /home/thomas/tmp/a-long/f [EMAIL PROTECTED]:~/tmp $ readlink -f a/../a/f [EMAIL PROTECTED]:~/tmp $ echo $? 1 #v- Why doesn't it resolve the latter case just as the previous ones? Because there are two symbolic links involved? Or two times the same one? Strange. #v+ [EMAIL PROTECTED]:~/tmp $ readlink --version | head -n 2 readlink (GNU coreutils) 5.97 Copyright (C) 2006 Free Software Foundation, Inc. [EMAIL PROTECTED]:~/tmp $ apt-cache policy coreutils | grep Installed Installed: 5.97-5.3ubuntu3 #v- I even decided to give the git master branch an try, but: ``configure.ac:35: require Automake 1.10.1, but have 1.10''. There I decided to stop and not begin upgrading my whole toolchain. Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: /bin/cat : argument list is too long
Hello!
On Wed, Nov 21, 2007 at 06:06:29AM -0700, Eric Blake wrote:
According to Manickam Muthuraman on 11/21/2007 4:47 AM:
[EMAIL PROTECTED]:~/HHpred/scop_hmm cat *.hhm scop70_1.72.hhm
{ echo *.hhm | xargs cat; } scop70_1.72.hhm.tmp
I was looking at these two command lines and wondered why you think that
``cat *.hhm'' would produce a longer command line than ``echo *.hhm''
does.
But I think I just found the answer why this might indeed work: `echo'
usually (?) is a shell built-in function and thus doesn't have this
limitation (?). Correct?
Otherwise, wouldn't some construct like the following one be even better?
(Save the discussion about the portability of using the null chararcter
separator, of course.)
find ./ -name \*.hhm -print0 | sort -z | xargs -0 cat ...
Regards,
Thomas
signature.asc
Description: Digital signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [FAQ] ARG_MAX and POSIX
Hello!
On Tue, Sep 04, 2007 at 03:06:53PM -0600, Bob Proulx wrote:
Isn't the Hurd also one of the systems that does not have an ARG_MAX
limit?
Correct.
#v+
$ uname -a
GNU flubber 0.3 GNU-Mach 1.3.99/Hurd-0.3 i686-AT386 GNU
$ getconf ARG_MAX
undefined
#v-
[glibc]/manual/process.texi
#v+
[...]
@item E2BIG
The combined size of the new program's argument list and environment
list is larger than @code{ARG_MAX} bytes. The GNU system has no
specific limit on the argument list size, so this error code cannot
result, but you may get @code{ENOMEM} instead if the arguments are too
big for available memory.
[...]
#v-
Regards,
Thomas
signature.asc
Description: Digital signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: a coreutils release is imminent
[Cced to bug-hurd@gnu.org.] Hello! On Tue, Mar 20, 2007 at 10:41:42PM +0100, Jim Meyering wrote: http://meyering.net/cu/coreutils-6.8+.tar.gz http://meyering.net/cu/coreutils-6.8+.tar.gz.sig Please build it and run make -k check on a few unusual systems today or tomorrow and report any problems. That might save someone (yourself, even) some trouble down the road. Here we go. So far, I didn't run the tests marked as ``root-only'' or ``very expensive''. #v+ $ uname -a GNU flubber 0.3 GNU-Mach 1.3.99/Hurd-0.3 i686-AT386 GNU #v- | ** | ../../../tests/cp/acl: This test requires getfacl and setfacl. | ** | SKIP: acl Correct, not supported so far. | ../../../tests/du/long-from-unreadable: Skipping this test. | It would fail, since your system lacks /proc support. | SKIP: long-from-unreadable Correct, no `/proc/' support by default so far. | ../../../tests/du/8gb: cannot create a file large enough for this test; possibly | ../../../tests/du/8gb: because file offsets are only 32 bits on this file system | SKIP: 8gb Would have to check what's up with that one. (As well as for the others further down the list, the ones where I didn't put specific comments.) | df: Warning: cannot read table of mounted file systems | df: Warning: cannot read table of mounted file systems | ../../../tests/du/slink: skipping this test, since `.' is on an XFS file system | SKIP: slink It's for sure not an xfs file system, but an ext2 one. We don't maintain something like `/proc/mounts' or `/etc/mtab', so running `df' without explicitly specifying a directory to work on won't work: #v+ $ df df: cannot read table of mounted file systems $ echo $? 1 $ fsysopts ./ /hurd/ext2fs --writable --no-inherit-dir-group /dev/hd0s6 $ df ./ df: Warning: cannot read table of mounted file systems Filesystem 1K-blocks Used Available Use% Mounted on - 3831468 2875780764116 80% /devel3 $ echo $? 0 #v- | ../../../tests/ls/stat-dtype: '.' is not on a suitable file system for this test | ../../../tests/ls/stat-dtype: skipping this test | SKIP: stat-dtype | df: Warning: cannot read table of mounted file systems | df: Warning: cannot read table of mounted file systems | PASS: df-P | ../../../tests/misc/pwd-unreadable-parent: vendor getcwd may be inadequate; skipping this test | SKIP: pwd-unreadable-parent | ../../../tests/misc/cat-proc: no /proc/cpuinfo skipping this test | SKIP: cat-proc | df: Warning: cannot read table of mounted file systems | PASS: df | FAIL: nice Known problem. | nohup: ignoring input and redirecting stderr to stdout | PASS: nohup | ../../../tests/misc/tac-continue: FULL_PARTITION_TMPDIR not defined; skipping this test | SKIP: tac-continue | tty-eof: this script requires Perl's Expect package =1.11 | SKIP: tty-eof | ../../../tests/mv/atomic: no strace program, so skipping this test | SKIP: atomic Correct, we don't have `strace', but instead could offer `rpctrace' to ``Trace Mach Remote Procedure Calls'', which roughly is `strace''s equivalent. | ** | ../../../tests/mv/acl: This test requires getfacl and setfacl. | ** | SKIP: acl | ../../../tests/rm/inaccessible: no openat support, so skipping this test | SKIP: inaccessible Correct, not implemented so far. | ../../../tests/tail-2/tail-n0f:/proc/2186/status: missing or 'different': skipping this test | SKIP: tail-n0f | make check-TESTS | make[3]: Entering directory `/devel3/tschwinge/tmp/coreutils/coreutils-6.8+/build/tests' | 0+1 records in | 0+1 records out | ../../src/df: Warning: cannot read table of mounted file systems | ../../tests/help-version: line 198: 6207 Terminated sleep 10m | PASS: help-version Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: LC_ALL=C bug
Hallo! On Sun, Jan 07, 2007 at 01:16:22PM +0100, Michael Heinzinger wrote: sorry dont can write in english hope i can help I will translate to English once we figured out what the actual issue is. Aufruf: uname [OPTION]... Bestimmte Systeminformationen ausgeben. Ohne OPTION dasselbe wie -s. -a, --allalle Informationen ausgeben, in der folgenden Reihenfolge (au??er -p und -i wenn nicht bekannt): -s, --kernel-nameNamen des Kernels ausgeben -n, --nodename Netzwerknamen der Maschine ausgeben -r, --kernel-release Release-Nummer des Kernels ausgeben -v, --kernel-version Version des Kernels ausgeben -m, --machineMaschinentyp (Hardware) ausgeben -p, --processor Typ des Prozessors ausgeben (oder ???unknown???) -i, --hardware-platform Hardwareplattform ausgeben (oder ???unknown???) -o, --operating-system Namen des Betriebssystems ausgeben --help diese Hilfe anzeigen und beenden --version Versionsinformation anzeigen und beenden Melden Sie Fehler (auf Englisch, mit LC_ALL=C) an bug-coreutils@gnu.org. [EMAIL PROTECTED]:~ uname -m i686 Ich verstehe noch nicht, was eigentlich dein Anliegen ist. Kannst du das bitte noch erl??utern? Gru??, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ``install -C'' / unnecessarily updating time stamps
[I added the patch's author, Akim Demaille, to the cc list, as it was not
sure if he's still reading the list.]
Hello!
On Sun, Dec 24, 2006 at 04:21:50PM -0800, Paul Eggert wrote:
Benoit Sigoure [EMAIL PROTECTED] writes:
http://lists.gnu.org/archive/html/automake-patches/2006-10/msg00070.html
Sorry, I missed that one. The idea looks reasonable, but that solves
the problem for install-sh only, right? GNU 'install' still wouldn't
support -C.
This brings up the following question: if `-C' shall be used a) by
default in Autoconf's `AC_PROG_INSTALL' if available or b) if requested
by the programmer through setting some flag, and `install-sh' supports
`-C', but the system's `install' executable doesn't (which will, as far
as I can tell, be the case on most systems as after this quoted patch has
been applied to `install-sh'), which of the two installation programs
shall be chosen: the native `install' for speed or `install-sh' for
feature completeness and to accommodate the programmer's request?
Also, the updated patch proposed in
http://lists.gnu.org/archive/html/automake-patches/2006-10/msg00077.html
has some coding-style components along with the substance components.
I plan to split it into two and apply the two pieces.
| +# Maybe we don't need to install the file. Use diff, not cmp,
| +# to be robust to end-of-line encoding.
| +{ if $copy_on_change
| + $diffprog $dsttmp $dst /dev/null 21
| + new=`ls -l $dsttmp | awk '{print $1 : $3 : $4}'`
| + old=`ls -l $dst| awk '{print $1 : $3 : $4}'`
| + test x$new = x$old
| + then
| + # No need to copy, that's the same file.
| + continue
| + else :; fi; }
Is this ``ls -l [...] | awk [...]'' portable enough and is it really
needed?
| http://www.freebsd.org/cgi/man.cgi?query=install
| #v+
| [...]
| -C Copy the file. If the target file already exists and the files
| are the same, then do not change the modification time of the
| target. If the target's file flags and mode need not to be
| changed, the target's inode change time is also unchanged.
| [...]
| #v-
Regards,
Thomas
signature.asc
Description: Digital signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
``install -C'' / unnecessarily updating time stamps
Hello! Please tell me if that has been discussed before -- I couldn't come up with good search terms to check myself. Automake section. I was thinking about the following: when in a package P1 (using Automake) e.g. C header files are installed via ``make install'', they are installed unconditionally. This has the effect that in a package P2, that `#include's such C header files, a lot of files will have to be rebuilt each time P1's ``make install'' has been run. Why not have P1's build system (i.e. Automake) overwrite files on installation only if their content actually changed? Coreutils section. E.g. FreeBSD's `install' program is described to offer the following functionality, which is currently not supported by GNU coreutils's. http://www.freebsd.org/cgi/man.cgi?query=install #v+ [...] -C Copy the file. If the target file already exists and the files are the same, then do not change the modification time of the target. If the target's file flags and mode need not to be changed, the target's inode change time is also unchanged. [...] #v- I found the following patch, http://cvs.pld.org.pl/SOURCES/coreutils-install-C.patch?rev=1.4 to add such functionality. What about adding that or something equivalent? Automake section. What about enhancing the `install-sh' shell script to also provide this functionality? (I could add that.) Autoconf section. What about having Autoconf's `AC_PROG_INSTALL' automatically use this functionality if available? Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: FYI: new test for a hard-to-detect race fix, using gdb(!)
Hello! On Thu, Dec 14, 2006 at 05:21:34PM +0100, Jim Meyering wrote: [...] +( gdb --version ) gdb.out 21 +if test ! -s gdb.out; then + echo $0: can't run gdb. Skipping this test. 12 + (exit 77); exit 77 +fi #v+ $ ( nonexistent ) out 21 $ test ! -s out echo can\'t run || echo continuing continuing #v- (Similar case again later, I think.) Also, why do you need to run the `gdb' commands from subshells? Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: logical paths (was: (no subject))
Hello! Not an answer to the question, but it might be interesting nevertheless. On Sat, Sep 09, 2006 at 12:48:11PM -0600, Bob Proulx wrote: Kartik K. Agaram wrote: Does POSIX require that coreutils commands use only physical path rather than pwd to resolve relative paths? When pwd contains symlinks and we try to operate upon relative paths that take us outside the symlink, the effect is often jarring and non-intuitive. Symlinks violate some principles of least surprise. Therefore it is no surprise that it is impossible to make all uses of symlinks unsurprising. ... at least when using the commonly used implementation / interpretation of `..'. http://plan9.bell-labs.com/sys/doc/lexnames.html, http://plan9.bell-labs.com/sys/doc/lexnames.pdf, http://plan9.bell-labs.com/sys/doc/lexnames.ps describes another one: ``Lexical File Names in Plan 9 --- or --- Getting Dot-Dot Right by Rob Pike''. Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug - report
Hello! On Thu, Sep 07, 2006 at 07:28:28PM +0530, [EMAIL PROTECTED] wrote: The command, who when used with any two arguments like who am am... displays the result of who am i. #v+ $ who --help Usage: who [OPTION]... [ FILE | ARG1 ARG2 ] [...] -monly hostname and user associated with stdin [...] If ARG1 ARG2 given, -m presumed: `am i' or `mom likes' are usual. [...] #v- Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Getting a file_t from a file descriptor
Hello!
On Thu, Jul 20, 2006 at 04:08:44PM -0700, Paul Eggert wrote:
Thomas Schwinge [EMAIL PROTECTED] writes:
Please tell if you (or anyone else, of course) need access to a GNU/Hurd
system.
I'm afraid it's a lot to learn all at once;
That was meant to be a general offer (i.e. in case someone is interested)
and it still holds. :-)
I was hoping you could help with the minor porting problems.
Sure.
--- copy.c2006-07-05 02:08:42.0 -0700
+++ /home/eggert/junk/copy.c 2006-07-20 16:06:57.0 -0700
@@ -213,12 +213,17 @@ set_owner (const struct cp_options *x, c
static void
set_author (const char *dst_name, int dest_desc, const struct stat *src_sb)
{
- /* FIXME: Preserve the st_author field via the file descriptor dest_desc.
*/
#if HAVE_STRUCT_STAT_ST_AUTHOR
/* Preserve the st_author field. */
- file_t file = file_name_lookup (dst_name, 0, 0);
+ file_t file = (dest_desc 0
+ ? file_name_lookup (dst_name, 0, 0)
+ : getdport (dest_desc));
I finally got around to verify that this (which got installed in the mean
time) works. Thanks!
Regards,
Thomas
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Tiny error w.r.t. change from 2005-12-05
Hello!
#v+
2005-12-05 Andreas Gruenbacher
* src/copy.c [!HAVE_FCHOWN]: Define fchown(...) to -1.
(set_owner, preserve_author): New functions, factored out of copy_reg.
(copy_reg): Use them.
(copy_internal): Use them here, too.
#v-
There was a tiny transformation error; please apply the attached patch.
Regards,
Thomas
2006-07-20 Thomas Schwinge [EMAIL PROTECTED]
* src/copy.c (set_author): Correctly access SRC_SB's element ST_AUTHOR.
Index: src/copy.c
===
RCS file: /sources/coreutils/coreutils/src/copy.c,v
retrieving revision 1.201
diff -u -p -r1.201 copy.c
--- src/copy.c 5 Jul 2006 09:08:42 - 1.201
+++ src/copy.c 20 Jul 2006 12:46:12 -
@@ -221,7 +221,7 @@ set_author (const char *dst_name, int de
error (0, errno, _(failed to lookup file %s), quote (dst_name));
else
{
- error_t err = file_chauthor (file, src_sb.st_author);
+ error_t err = file_chauthor (file, src_sb-st_author);
if (err)
error (0, err, _(failed to preserve authorship for %s),
quote (dst_name));
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Tiny error w.r.t. change from 2005-12-05
Hello!
On Thu, Jul 20, 2006 at 02:58:55PM +0200, Thomas Schwinge wrote:
[...]
Immediatelly (i.e. especiall that there was no ``long failure period''
like said in the bounce message) after sending the mail I received the
attached bounce. I'm ccing this very email to another email address of
Andreas Gruenbacher (which I found in coreutils's `THANKS'). Need to
contact computer.org?
Regards,
Thomas
---BeginMessage---
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[EMAIL PROTECTED]
retry time not reached for any host after a long failure period
-- This is a copy of the message, including all the headers. --
Return-path: [EMAIL PROTECTED]
Received: from tschwinge by fencepost.gnu.org with local (Exim 4.34)
id 1G3Y7D-00020G-GE; Thu, 20 Jul 2006 08:58:55 -0400
Date: Thu, 20 Jul 2006 14:58:55 +0200
From: Thomas Schwinge [EMAIL PROTECTED]
To: bug-coreutils@gnu.org, [EMAIL PROTECTED]
Subject: Tiny error w.r.t. change from 2005-12-05
Message-ID: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=qlTNgmc+xy1dBmNv
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040907i
--qlTNgmc+xy1dBmNv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hello!
#v+
2005-12-05 Andreas Gruenbacher
* src/copy.c [!HAVE_FCHOWN]: Define fchown(...) to -1.
(set_owner, preserve_author): New functions, factored out of copy_reg.
(copy_reg): Use them.
(copy_internal): Use them here, too.
#v-
There was a tiny transformation error; please apply the attached patch.
Regards,
Thomas
--qlTNgmc+xy1dBmNv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=coreutils-src_copy.c.patch
2006-07-20 Thomas Schwinge [EMAIL PROTECTED]
* src/copy.c (set_author): Correctly access SRC_SB's element ST_AUTHOR.
Index: src/copy.c
===
RCS file: /sources/coreutils/coreutils/src/copy.c,v
retrieving revision 1.201
diff -u -p -r1.201 copy.c
--- src/copy.c 5 Jul 2006 09:08:42 - 1.201
+++ src/copy.c 20 Jul 2006 12:46:12 -
@@ -221,7 +221,7 @@ set_author (const char *dst_name, int de
error (0, errno, _(failed to lookup file %s), quote (dst_name));
else
{
- error_t err = file_chauthor (file, src_sb.st_author);
+ error_t err = file_chauthor (file, src_sb-st_author);
if (err)
error (0, err, _(failed to preserve authorship for %s),
quote (dst_name));
--qlTNgmc+xy1dBmNv--
---End Message---
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
`touch' broken on GNU
Hello! Before I start digging deeper: can someone imaging offhand why `touch' broke? #v+ [EMAIL PROTECTED]:/var/tmp/coreutils/build $ src/touch foo [EMAIL PROTECTED]:/var/tmp/coreutils/build $ ls -l foo -rw-r--r-- 1 thomas users 0 Jan 1 1970 foo [EMAIL PROTECTED]:/var/tmp/coreutils/build $ uname -a GNU leibniz 0.3 GNU-Mach 1.3/Hurd-0.3 i686-AT386 GNU [EMAIL PROTECTED]:/var/tmp/coreutils/build $ dpkg -l gnumach hurd libc0.3 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== hi gnumach 20060408.dfsg.1-1 The GNU version of the Mach microkernel hi hurd 20050513-6The GNU Hurd hi libc0.3 2.3.6-13 GNU C Library: Shared libraries #v- Older versions of coreutils work as expected. Regards, Thomas ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Tiny error w.r.t. change from 2005-12-05
Hello! On Thu, Jul 20, 2006 at 03:24:19PM +0200, Jim Meyering wrote: Thomas Schwinge [EMAIL PROTECTED] wrote: #v+ 2005-12-05 Andreas Gruenbacher * src/copy.c [!HAVE_FCHOWN]: Define fchown(...) to -1. (set_owner, preserve_author): New functions, factored out of copy_reg. (copy_reg): Use them. (copy_internal): Use them here, too. #v- There was a tiny transformation error; please apply the attached patch. Did you actually compile on a system that has stat.st_author? Yes: #v+ [EMAIL PROTECTED]:/var/tmp/coreutils/build $ src/ls --author -l foo -rw-r--r-- 1 thomas users thomas 0 Jul 20 13:27 foo [EMAIL PROTECTED]:/var/tmp/coreutils/build $ src/cp /hurd/init foo [EMAIL PROTECTED]:/var/tmp/coreutils/build $ src/ls --author -l foo -rw-r--r-- 1 thomas users root 32240 Jul 20 13:28 foo #v- Regards, Thomas ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: `touch' broken on GNU
On Thu, Jul 20, 2006 at 08:41:02AM -0700, Paul Eggert wrote: Thomas Schwinge [EMAIL PROTECTED] writes: Before I start digging deeper: can someone imaging offhand why `touch' broke? Thanks for the report. Which version of 'touch'? The email didn't say. Is this CVS coreutils or some other version? Sorry, yes, that's cvs's HEAD, but has also been seen with 5.9x. [EMAIL PROTECTED]:/var/tmp/coreutils/build $ src/touch foo [EMAIL PROTECTED]:/var/tmp/coreutils/build $ ls -l foo -rw-r--r-- 1 thomas users 0 Jan 1 1970 foo It may be a problem in the Hurd's implementation of futimesat and/or futimes. That may indeed very well be. People are currently looking into this issue. Perhaps you can strace or truss or do whatever the Hurd equivalent is rpctrace. Regards, Thomas ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature-request: add banner to coreutils as a standard GNU/Linux utility
On Tue, Apr 11, 2006 at 03:22:36PM -0600, Bob Proulx wrote: I don't find the BSD one very useful, who has continuous tractor feed paper printers these days? :-) A... Bzzzzrzzrzrzrzzrzz zrzzrzzrrzzr. Week. Bzzzrzzrzzr rzzr zrrzrrrzzrzrrzrzrzz. Weeek. Bzrzrzrzrrrzr zrzzrzrrrzzz. Weeek. Bzzzzrrrzzrrrz. Week. Brrrzrzzzrzzrzzrrr. Wek. [...] ;-) Regards, Thomas ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: a suggestion for rm
On Fri, Oct 28, 2005 at 10:00:40AM +0300, M Atakan G?rkan wrote: Would it not make more sense for rm to fail completely if one of the files on the command line is not found? For example if I intend to delete the file foo1 and type rm foo 1 and by chance have a file named foo, it will be gone; even though rm can tell that something is wrong since it will fail on trying to unlink 1. That can't work reliably due to race conditions. You can surely make up an example for yourself. ;-) Regards, Thomas ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: loss of ascii-betizing?
On Thu, Jun 24, 2004 at 04:13:58PM -0500, Paul Garrett wrote: Dear GNU.org, In the new RedHat/Fedora, ls no longer ASCII-betizes, but alphabetizes, and even ignores leading dots, so dotfiles are mixed in among other files. Is this a feature? Yes it is. You can control ls' (and other programs') behaviour setting LC_COLLATE. Have a look at your libc's documentation for further information. You most probably want to use #v+ $ LC_COLLATE=C $ export LC_COLLATE #v- Regards, Thomas ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
