[patch] coreutils-5.97: tests/rm/fail-eperm fix
Hi, I discovered that the rm/fail-eperm test can fail if a temporary file owned by another user gets selected for attempted deletion when that filename contains a space. Here is a simple fix. Tim. */ --- coreutils-5.97/tests/rm/fail-eperm.test 2006-09-28 13:22:34.0 +0100 +++ coreutils-5.97/tests/rm/fail-eperm 2006-09-28 13:24:22.0 +0100 @@ -65,6 +65,9 @@ -l $target_file || -o _ || -d _ || -w _ and next; + # Skip files with spaces in their names. + next if $target_file =~ / /; + $found_file = 1; # Invoke rm on this file and ensure that we get the signature.asc Description: This is a digitally signed message part ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch] cifs and 'df -l'
Hi, Here is a patch that adds a check for 'cifs' filesystem types, so they can be omitted from 'df -l' output. Tim. */ --- coreutils-5.97/lib/mountlist.c.df-cifs 2006-09-12 11:19:18.0 +0100 +++ coreutils-5.97/lib/mountlist.c 2006-09-12 11:20:28.0 +0100 @@ -152,12 +152,13 @@ #ifndef ME_REMOTE /* A file system is `remote' if its Fs_name contains a `:' - or if (it is of type smbfs and its Fs_name starts with `//'). */ + or if (it is of type smbfs or cifs and its Fs_name starts with `//'). */ # define ME_REMOTE(Fs_name, Fs_type) \ (strchr (Fs_name, ':') != 0 \ || ((Fs_name)[0] == '/' \ (Fs_name)[1] == '/' \ - strcmp (Fs_type, smbfs) == 0)) + (strcmp (Fs_type, smbfs) == 0 \ + || strcmp (Fs_type, cifs) == 0))) #endif #if MOUNTED_GETMNTINFO signature.asc Description: This is a digitally signed message part ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
seq increment '1' even when first last?
Hi, I'm trying to work out what prompted this change: 2003-09-04 Paul Eggert [EMAIL PROTECTED] * src/seq.c (step): Default to 1. (print_numbers): Allow the output to be empty. (main): The default step is 1, even if LAST FIRST; as per documentation. The original behaviour, of automatically defaulting to -1 when appropriate, seems on the face of it to be quite useful. I wonder why the code was changed to match the documentation, rather than the other way around. Tim. */ signature.asc Description: This is a digitally signed message part ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch] 5.95: getgrouplist
Hi,
Here is a patch that makes use of getgrouplist() if it is available,
for better efficiency.
Tim.
*/
--- coreutils-5.92/m4/jm-macros.m4.getgrouplist 2005-09-25 06:57:46.0
+0100
+++ coreutils-5.92/m4/jm-macros.m4 2005-10-25 14:28:45.0 +0100
@@ -105,6 +105,7 @@
fchmod \
fchown \
ftruncate \
+getgrouplist \
hasmntopt \
isascii \
iswspace \
--- coreutils-5.92/lib/getugroups.c.getgrouplist2005-09-22
07:47:18.0 +0100
+++ coreutils-5.92/lib/getugroups.c 2005-10-25 14:28:02.0 +0100
@@ -23,6 +23,9 @@
# include config.h
#endif
+/* We do not need this code if getgrouplist(3) is available. */
+#ifndef HAVE_GETGROUPLIST
+
#include sys/types.h
#include stdio.h /* grp.h on alpha OSF1 V2.0 uses FILE *. */
#include grp.h
@@ -105,3 +108,4 @@
return count;
}
+#endif /* have getgrouplist */
--- coreutils-5.92/src/id.c.getgrouplist2005-08-11 22:02:57.0
+0100
+++ coreutils-5.92/src/id.c 2005-10-25 14:30:41.0 +0100
@@ -253,7 +253,14 @@
if (!username)
max_n_groups = getgroups (0, NULL);
else
-max_n_groups = getugroups (0, NULL, username, gid);
+{
+#ifdef HAVE_GETGROUPLIST
+ max_n_groups = 0;
+ getgrouplist (username, gid, NULL, max_n_groups);
+#else
+ max_n_groups = getugroups (0, NULL, username, gid);
+#endif
+}
if (max_n_groups 0)
ng = -1;
@@ -263,7 +270,22 @@
if (!username)
ng = getgroups (max_n_groups, g);
else
- ng = getugroups (max_n_groups, g, username, gid);
+ {
+#ifdef HAVE_GETGROUPLIST
+ int e;
+ ng = max_n_groups;
+ while ((e = getgrouplist (username, gid, g, ng)) == -1
+ ng max_n_groups)
+ {
+ max_n_groups = ng;
+ g = xrealloc (g, max_n_groups * sizeof (GETGROUPS_T));
+ }
+ if (e == -1)
+ ng = -1;
+#else
+ ng = getugroups (max_n_groups, g, username, gid);
+#endif
+ }
}
if (ng 0)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort 5.93 on Fedora Core 5 exits if intermediate file reaches 2 GB
On Wed, Apr 12, 2006 at 01:29:07AM -0700, Paul Eggert wrote: Keith Stanley [EMAIL PROTECTED] writes: Under Fedora Core 5 (and probably other versions), the program sort (version 5.93) exits (without cleaning up temporary files) in any of the temporary files reach the size of 2 GB. This sounds like you (or your installer) has built coreutils in small-file mode, which supports files only up to 2 GiB. The coreutils default is to build in large-file mode, which doesn't have that limit. If you built coreutils, please check the build and see why it was done in small-file mode. You can look in config.h and check that it has a #define _FILE_OFFSET_BITS 64. If it doesn't, find out why it doesn't. If someone else built coreutils for you, please forward this message to them. Another remote possibility is that a ulimit came into play, of course. For what it's worth, Fedora Core 5's coreutils package has this in the build log for i386: checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGE_FILES value needed for large files... no If the original reporter is having problems with the Fedora Core 5 RPM, it would greatly help for them to file a bug in Bugzilla: https://bugzilla.redhat.com/ Tim. */ pgps4tgt1I9Bh.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv a b/ when b does not exist
This: rm -rf a b mkdir a mv a b/ fails on Linux with coreutils-5.93: mv: target `b/' is not a directory: No such file or directory In previous releases (such as 5.2.1) it has worked. The rename() call is also happy with the trailing slash. Is this a regression, or an intentional change? Original bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174253 Tim. */ pgpQllXudinPP.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: multi-character tab
On Wed, Oct 26, 2005 at 11:17:38PM -0600, Bob Proulx wrote: the upstream sources. If you wish to pursue this further you will need to file a bug with your distribution. Or compile your own version from the GNU sources. FWIW, this seems to have broken in an attempt to get sort(1) to support multi-byte character tabs. Please file a bug if you'd like to see it fixed in an update. (It'll be fixed for future releases anyway.) Tim. */ pgpdhYk04maU6.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Deprecating mv's --reply={yes,no,query} option
On Thu, Jun 30, 2005 at 09:37:35AM +0200, Jim Meyering wrote: [EMAIL PROTECTED] (Bob Proulx) wrote: The second option that I recommend is to deprecate this option entirely and remove it from the code base. The longer it remains the harder it will be to change to better behavior later. It is not really useful as it stands today. (I am happy to see challenges to that last statement.) Hi Bob, I'm leaning toward deprecating (undocument and emit a warning) --reply=ANYTHING. Does anyone find the --reply=no option to be useful? The other two are equivalent to -i and -f. Some Linux distributions have alias rm=rm -i for root, and the way to avoid the prompt then is --reply=yes. It's useful to have an option that undoes the effect of '-i', IMHO. Tim. */ pgphSj13wDXvV.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Deprecating mv's --reply={yes,no,query} option
On Thu, Jun 30, 2005 at 11:16:19AM +0200, Jim Meyering wrote: [ Presuming you meant `mv -i'. ] Just use mv's -f option -- it's equivalent to --reply=yes. If you really did mean `rm -i', then I admit that rm's -f option isn't precisely the same as `turn off -i', but it's pretty close. People (especially superuser) who don't like the vendor-supplied aliases are always free to use `unalias' or to define a new alias that invokes rm with no options. No, you're right, I got confused -- it was cp I was thinking of, where -f has no effect on prompting. Tim. */ pgplmBfl6ebHl.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch] 5.2.1 (hostid): don't display sign-extended part
Hi, The gethostid() function returns a long int, and on 64-bit platforms this can mean that the 32-bit value becomes sign-extended. Here is a patch to only display the 32-bit value in hostid(). Original bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160078 Tim. */ --- coreutils-5.2.1/src/hostid.c.no-sign-extend 2005-06-16 11:33:54.0 +0100 +++ coreutils-5.2.1/src/hostid.c2005-06-16 11:34:18.0 +0100 @@ -80,7 +80,7 @@ } id = gethostid (); - printf (%lx\n, id); + printf (%8x\n, id); exit (EXIT_SUCCESS); } ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I need a bi-directional FIFO
On Mon, Apr 11, 2005 at 03:07:13PM -0500, Alan Grimes wrote: before I disconnect my modem and install a serial loop-back cable, do I have any software alternatives to this problem? Sounds like you want a PF_LOCAL socket. See 'man unix' for information about them. (This isn't really a coreutils question though.) Tim. */ pgpMlYXcDilZZ.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [patch] who and stale utmp entries
On Thu, Mar 24, 2005 at 10:47:52AM -0800, Paul Eggert wrote: OK, thanks for explaining it. Can you please try the following patch instead? It tries to do the right thing in that case. It also checks for bogus signal numbers (i.e., nonpositive ones). I don't have a bad utmp file to test with, so I'd appreciate it if you'd try it out on your bad file before I document and install this change. Yes, this works very well. Thanks! Tim. */ pgphAjZFZs7Bx.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: install(1) man page
On Thu, Mar 24, 2005 at 08:21:15AM -0700, Bob Proulx wrote: Could you make a bug report to Red Hat about this? Neither Debian nor SuSE have patched for that option. I did not check any others. Never mind, I've removed this patch from the development RPM package now. It was added in 1999: * Thu Nov 18 1999 Bernhard Rosenkraenzer [EMAIL PROTECTED] - Add the -C option to install for compatibility with *BSD Tim. */ pgpPTcQMnaP3f.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
'cp -lL' behaviour conflicts with documentation
coreutils-5.2.1: $ mkdir /tmp/foo $ cp -lL /lib/libc.so.6 /tmp/foo $ ls -l /tmp/foo total 4 lrwxrwxrwx 2 root root 13 Mar 8 10:59 libc.so.6 - libc-2.3.4.so The man page says that -L always dereferences symbolic links, but when used in conjuction with -l (link files instead of copying) this is not honoured. (Originally RH bug #150951.) Tim. */ pgpPAmO9Geguc.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'cp: .snapshot/xxx and xxx are identical'
On Mon, Mar 07, 2005 at 01:36:20PM +0100, Andreas Schwab wrote: http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html If source_file references the same file as dest_file, cp may write a diagnostic message to standard error; it shall do nothing more with source_file and shall go on to any remaining files. (Not sure whether that allows exiting with non-zero status.) Well, whether source_file references the same file as dest_file is not quite clear. They have the same inode, yes, but different content. Tim. */ pgpegKjljS5CR.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort 5.2.1 is VERY slow
On Tue, Mar 01, 2005 at 09:27:18PM +0100, Andreas Schwab wrote: It cannot do the former. There are encodings where bytes that look like plain ASCII are in fact part of a multibyte sequence. But it may be worthwhile to special case UTF-8 which does not have this problem. I have patched for grep to make it lots faster with UTF-8, and have been trying to get them submitted upstream for ages. Also, the glibc regex implementation does perform the above optimisation (more or less) anyway, I believe. Tim. */ pgpKzjQEY7No3.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in sort?
On Tue, Mar 01, 2005 at 02:44:09PM +0100, Bernd Klein wrote: But it means on the other hand, that I can't sort international results (with . instead of ,) in a German locale, execept with using sed or awk as a filter. You can use 'LC_NUMERIC=C sort ...' I think. Tim. */ pgpmwtXfkVmTZ.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
tr doesn't work for multibyte encodings
Hi, In 5.2.1, tr doesn't work for multibyte encodings such as UTF-8. Are there any plans to fix this? Tim. */ pgpYpEofvOHMO.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-grep] [patch] getting '--devices=skip' to work
On Tue, Nov 23, 2004 at 11:53:13AM -0800, Paul Eggert wrote: None of these uses would run afoul of the bug that you mentioned, as far as I can tell. Agreed. Tim. */ pgpQ7wXF3K170.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch] 5.2.1: prevent compiler warning
The fold_text() function doesn't ever return anything and its return
code is never checked.
Original bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136090
--- coreutils-5.2.1/src/fold.c.void 2004-10-18 13:42:18.119712001 +0100
+++ coreutils-5.2.1/src/fold.c 2004-10-18 13:42:28.346757280 +0100
@@ -157,7 +157,7 @@
return column;
}
-static int
+static void
fold_text (FILE *istream, int width, int *saved_errno)
{
register int c;
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bad cp -a behaviour
On Wed, Aug 11, 2004 at 02:53:11AM +0100, Philip Rowlands wrote: On Tue, 10 Aug 2004, Tim Waugh wrote: How odd. Is that a patched 5.2.1? Possibly; it's from an unadulterated Fedora Core 2. Yes, that's patched. :-) But I also see the problem in Fedora Core 2. I tried building from source, but I get the same as before (i.e. no problem, no output from diff). Bizarre. Let's keep digging: $ src/cp -afv 2/d 1 `2/d/4' - `1/d/4' `2/d/2' - `1/d/2' `2/d/1' - `1/d/1' `2/d/3' - `1/d/3' $ ls -U1 2/d 4 2 1 3 [ this is running on an ext3 filesystem ] The bug might be order-specific; does your test produce the same output as the above with -v? Thinking about it, it must be order-specific. But here's the output I get: `2/d/3' - `1/d/3' `2/d/2' - `1/d/2' `2/d/1' - `1/d/1' `2/d/4' - `1/d/4' strace output shows that the only unlink is 1/d/2, here: write(1, `2/d/2\' - `1/d/2\'\n, 19) = 19 link(1/d/3, 1/d/2) = -1 EEXIST (File exists) unlink(1/d/2) = 0 link(1/d/3, 1/d/2) = 0 Tim. */ pgp4UqzgV22rF.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bad cp -a behaviour
On Wed, Aug 11, 2004 at 11:36:54AM +0100, Philip Rowlands wrote: OK, so this is a filesystem-dependent issue when using --recursive on source and destination directories which both contain hard links. For what it's worth, I'm using ext3 as well. Tim. */ pgphJncezsYeh.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df spools up hard drive
On Sun, Aug 08, 2004 at 05:51:13AM -0700, Aaron Peterson wrote: whenever I'm curious how much diskspace I have left, I run df... well, The drives spin up, and I'd rather not wait, and I'd rather not wear out my drives, and I'd rather not have the large power suck all at once... Try 'df --no-sync'. It's probably a kernel issue... but I found this email address first... If --no-sync doesn't help, then yes. Tim. */ pgppqa4ueGhZo.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Bad cp -a behaviour
When using 'cp -a' to copy a directory structure, it has some unexpected behaviour. See the attached Makefile, which compares the behaviour between tar, cpio, and cp. The problem seems to be that when a destination file is written it is done so by opening the file without removing it first. If it is a hardlink to a previous destination file from the same command it will be overwritten. The original bug report is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128874 Tim. */ CP=cp CPIO=cpio TAR=tar all: $(MAKE) cpio $(MAKE) tar $(MAKE) cp cpio: prep (cd 2; find -type f | $(CPIO) -pdm ../1) diff -upr 2 1 tar: prep (cd 2; $(TAR) cf - . | $(TAR) -C ../1 -xf -) diff -upr 2 1 cp: prep $(CP) -af 2/d 1 diff -upr 2 1 prep: rm -fr 1 2 mkdir -p 1/d 2/d echo foo 1/d/1 ln 1/d/1 1/d/2 ln 1/d/1 1/d/3 sleep 1 echo foo 2/d/1 echo bar 2/d/2 ln 2/d/2 2/d/3 ln 2/d/2 2/d/4 pgpUxk0kvGRiz.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: printf cleanup for POSIX and Bash compatibility
On Wed, Jul 07, 2004 at 12:00:23AM -0700, Paul Eggert wrote: I looked at the Fedora Core 2 patches for coreutils, Sorry there are so many, by the way -- I did try to make them fewer in number with the move to 4.5.x a while back. Tim. */ pgpN4iRiAU0TG.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls bug?
On Mon, Jul 05, 2004 at 10:48:18AM +0200, Jim Meyering wrote: Good. I'm letting the list know, too. David Favro [EMAIL PROTECTED] wrote: On Mon, 05 Jul 2004 00:19:12 +0200, Jim Meyering [EMAIL PROTECTED] wrote: Thanks for the report. BTW, Tim, here's a link to it: http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/2459 Yes, this was spotted last month: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125238 and the current Fedora development package has the fix. Tim. */ pgp3aDG42JFaj.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bugs #9185] rm calls access() but it shouldn't
On Wed, Jun 02, 2004 at 06:53:33PM +0200, Jim Meyering wrote: Thanks for forwarding that report! I'm considering applying the patch below. Unfortunately, rm (without -f) must call access (via euidaccess) to determine whether it needs to issue a prompt. With this patch, rm now calls both lstat and access for each non-symlink it might unlink. Another good reason to use -f. Thanks. Works for me. Tim. */ pgpaBXimGPVaC.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
po/ja.po update for 5.2.1
Please see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124862 This bug report has an attachment containing a patch to fix this problem in po/ja.po: Description of problem: 'ls -l' lacks '#26085;'(day) char in Japanese environment. Steps to Reproduce: 1. ls -l with LANG=ja_JP.UTF-8 (I won't attach it in case it gets mangled.) Tim. */ pgp8DfWMM3hvc.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Bug reports: savannah?
Should we be reporting bugs using the savannah interface now, or still by posting to this mailing list? I just filed: https://savannah.gnu.org/bugs/index.php?func=detailitemitem_id=9185 Tim. */ pgpMtQwAaxt2i.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv -i --reply=no ... acts like --reply=yes
With coreutils-5.2.1, I see unexpected behaviour with mv -i --reply=no: $ rm -rf x $ mkdir -p x/a x/b $ cd x $ echo a a/foo $ echo b b/foo $ mv -i --reply=no a/foo b/foo $ cat b/foo a First reported at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120742 Tim. */ pgp0.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: mv -i --reply=no ... acts like --reply=yes
On Thu, Apr 15, 2004 at 11:41:33AM -0400, Paul Jarc wrote: I think that's what Tim expected. But b/foo was replaced with a/foo, in spite of --reply=no. The same thing happens for me with 5.2.1. Well, I didn't expect --reply=no to override the -i; I had thought (without reading the documentation) that --reply applied to the questions that -i prompted. Now I see that for this specific case what I was doing was equivalent to 'mv a/foo b/foo' since b/foo is writable. It would have been nice if '-i --reply=no' did what '-u' does -- but now that I have read the documentation I can see why that isn't so. So the next question I have is: why does 'mv -i -u' prompt me? :-) Tim. */ pgp0.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
[patch] coreutils-5.2.0: fix du/deref-args test
See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117556 With SELinux enabled, the file security context labels take up filesystem room, and I needed to make this change to get 'make check' to pass: --- coreutils-5.2.0/tests/du/deref-args.selinux 2004-03-05 12:20:01.0 + +++ coreutils-5.2.0/tests/du/deref-args 2004-03-05 12:21:04.0 + @@ -34,7 +34,7 @@ # Ensure that -D makes du dereference even symlinks to non-directories. # The sed command maps the 68 I get on an ext3 file system to the 64 I expected. # On tmpfs, I get 64. -du -kD slink-to-64k | sed 's/^6[0-9]/64/' out +du -kD slink-to-64k | sed 's/^6[0-9]\|72/64/' out cat \EOF exp slink/a slink Tim. */ ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: chown xxx.yyy, POSIX, and LSB
On Mon, Feb 23, 2004 at 06:49:55PM +0100, Jim Meyering wrote:
Let's hope the LSB is flexible on this, if they haven't
already corrected things for the next version.
Version 1.3 says that '.' is supported, while the current 2.0 draft
says that it is deprecated (but still supported). On the off-chance
that it can be removed altogether I filed this bug report:
http://bugs.linuxbase.org/show_bug.cgi?id=98
Is there any chance of making this new rejection behaviour dependent
on POSIXLY_CORRECT (i.e. having the old behaviour remain the default
in its absence), rather than only providing the old behaviour with
_POSIX2_VERSION=199209?
It wouldn't make sense to tie chown's accepting `.' in place of `:'
to POSIXLY_CORRECT, since it would make chown interpret a.b as username
`a' and group `b' while POSIX requires that it be interpreted
as username `a.b'.
So I guess it'd be more like POSIXLY_INCORRECT :)
Just to be clear about what I mean, here is the patch I intend to
apply for the Fedora Core coreutils package:
--- coreutils-5.2.0/lib/userspec.c.allow_old_options2004-02-23 16:51:00.0
+
+++ coreutils-5.2.0/lib/userspec.c 2004-02-23 17:04:41.0 +
@@ -171,7 +171,8 @@
separator = strchr (spec, ':');
/* If there is no colon, then see if there's a `.'. */
- if (separator == NULL posix2_version () 200112)
+ if (separator == NULL (posix2_version () 200112 ||
+ !getenv (POSIXLY_CORRECT)))
{
dot = strchr (spec, '.');
/* If there's no colon but there is a `.', then first look up the
Tim.
*/
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: chown xxx.yyy, POSIX, and LSB
On Mon, Feb 23, 2004 at 02:42:58PM -0500, Paul Jarc wrote: Jim Meyering [EMAIL PROTECTED] wrote: /* If there is no colon, then see if there's a `.'. */ - if (separator == NULL posix2_version () 200112) + if (separator == NULL (posix2_version () 200112 || + !getenv (POSIXLY_CORRECT))) Please consider using a different environment variable. Setting POSIXLY_CORRECT should not make an otherwise-POSIX-conforming program like GNU chown *non*conforming. Setting the variable would mean that . *wouldn't* be recognized, AFAICT. If it's *not* set, then . is considered as a separator. Precisely -- this is what I tried to say in words, and then with the code. :-) The intent is to make 'POSIXLY_CORRECT=1 chown ...' behave as in unpatched coreutils-5.2.0. Tim. */ pgp0.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: RFC: cp -if a b: should it prompt? POSIX says `yes', most don't
On Wed, Feb 18, 2004 at 01:23:12PM +0200, [EMAIL PROTECTED] wrote: Maybe this could be done with the wc -l behavior for when the last line doesn't have a newline? Maybe I'm weird but I think the POSIX behavior is clearly counterintuitive. Unless there are wc programs out there that behave differently (are there?), I don't think this is really the same sort of situation. Tim. */ pgp0.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: df and multiple-mounted mountpoints
On Mon, Jul 07, 2003 at 09:04:49PM -0700, Paul Eggert wrote: Why is it misleading? I don't understand the situation, but from what you write only the last mounted fs is visible, i.e., is accessible to any application. It's misleading because it shows each mounted device on that mount point as having the same size and usage, even the ones which are not at the top of the stack. Tim. */ pgp0.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
df and multiple-mounted mountpoints
With Linux it is possible to have a single mountpoint mounted several times; the last mounted fs is the one whose stats are visible, and they are stacked. What should df do in this case? Currently it shows the stats for the last mounted fs for each fs mounted on the mount point, which is misleading. Thanks, Tim. */ pgp0.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
[patch] zh_CN 'ls -l' alignment
Hi, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88346 The filename field of the command 'ls -l' is not properly aligned under the locale zh_CN.GB18030. Here is a patch that fixes it. Tim. */ --- coreutils-5.0/po/zh_CN.po.datealign 2003-05-28 10:04:27.0 +0100 +++ coreutils-5.0/po/zh_CN.po 2003-05-28 10:04:28.0 +0100 @@ -3065,7 +3065,7 @@ #: src/ls.c:673 msgid %b %e %Y -msgstr %Y-%m-%d +msgstr %b %e %Y #: src/ls.c:681 msgid %b %e %H:%M ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
