[PATCH] Add expand test for lines starting with both spaces and tabs
This issue is still present on fedora 9 at least,
which you can confirm with this command:
printf \tif\n | expand --initial -t4 |
grep -qF $(printf '\t') echo buggy
So it's worth adding a test I think.
cheers,
Pádraig.
From b36ea40fc24c6d3aca6094de90657e067fa80ff6 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= [EMAIL PROTECTED]
Date: Thu, 10 Jul 2008 09:36:49 +0100
Subject: [PATCH] Add expand test for lines starting with both spaces and tabs.
The expand released in current distributions (Fedora Core 4 - Fedora 9
at least), doesn't expand --initial tabs if spaces are present.
tests/misc/expand: Add test to verify --initial works correctly
with lines starting with both spaces and tabs.
---
tests/misc/expand |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/tests/misc/expand b/tests/misc/expand
index b386737..468fdee 100755
--- a/tests/misc/expand
+++ b/tests/misc/expand
@@ -28,6 +28,7 @@ my @Tests =
['t1', '--tabs=3', {IN=a\tb}, {OUT=a b}],
['t2', '--tabs=3,6,9', {IN=a\tb\tc\td\te}, {OUT=a b c d e}],
['i1', '--tabs=3 -i', {IN=\ta\tb}, {OUT= a\tb}],
+ ['i2', '--tabs=3 -i', {IN= \ta\tb}, {OUT= a\tb}],
);
my $save_temps = $ENV{DEBUG};
--
1.5.3.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
cp -v doesn't work correctly under file system mounted through FUSE
Hi all, I found a very strange problem with cp. Normally, cp -rv files log should list all the files copied in the file 'log'. However, when cp -rv a directory under file system mounted via FUSE, redirect of I/O doesn't work. The verbose output is gone and the log file contains nothing. Also, if I try to read the verbose output of cp command with another program via pipe, it works with local file systems, but not with remote file systems mounted via FUSE, such as sshfs and curlftpfs. However, if I use forkpty in the program, it seems to partially work. Shouldn't --verbose always give output whether the stdout is a tty or not? p.s. I redirect the verbose output to pipe read by another program to show the progress of copying, then I found this really strange bug. Thank you ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cd command issue
Hi GNU coreutils, Today I just tried cd ~tabspace . After entering this in the terminal it became unable to delete the ~ symbol meaning the backspace key, enter key , right arrow marks are not detected and the user have to use the ctrl-c to come out of that, to enter other commands. Using a 2.6 Kinux kernel (RH 4) Update me whether you see this in you setup / this is a valid issue or not. Yours Truely, GNU user. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: making GNU ls -i (--inode) work around the linux readdir bug
Phillip Susi [EMAIL PROTECTED] wrote: Jim Meyering wrote: From what I've read, POSIX does not specify this. If you know of wording that is more precise, please post a quote. That was my point the standard does not specify that this behavior is an error, and since every unix system since the dawn of time has behaved this way, it is NOT an error as you claim. As far as I've heard, only one application would be affected adversely by this change (extra stat calls would hurt performance), and that application, magicmirror is not widely used -- since I found no reference to it in the first few pages of search results. EVERY application that invokes ls -i is effected. Please name one. If you know of other applications that run ls -i and depend on the post-coreutils-6.0 behavior of not stat'ing some files, please let me know. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] avoid -Wsign-compare warnings
Pádraig Brady [EMAIL PROTECTED] writes:
I don't see why gcc is giving this warning, as
there is no comparison between signed and unsigned here.
For example in the following program compiled
with -Wsign-compare why does the second assignment
give a warning, while the first doesn't?
#include stdio.h
#include limits.h
int main(void)
{
int i=0;
unsigned u=UINT_MAX;
if (u) i = u; /* no warning */
i = u ? u : i; /* warning with -Wsign-compare */
GCC is warning about the difference in signedness between the two
alternatives of the conditional operator. That can lead to subtle bugs,
since the expressions needs to be converted to a common type, the
signedness of which can change depending of the involved types. The
first case is just an assignment, where the right operand is always
converted to the left operand, thus no surprising behaviour (but
-Wsign-conversion still warns for this case).
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Add expand test for lines starting with both spaces and tabs
Pádraig Brady [EMAIL PROTECTED] wrote: This issue is still present on fedora 9 at least, which you can confirm with this command: printf \tif\n | expand --initial -t4 | grep -qF $(printf '\t') echo buggy So it's worth adding a test I think. Better coverage is always good. Thanks! Applied. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cd command issue
On Thu, 10 Jul 2008, Janarthanan Palanichamy wrote: Hi GNU coreutils, Today I just tried cd ~tabspace . After entering this in the terminal it became unable to delete the ~ symbol meaning the backspace key, enter key , right arrow marks are not detected and the user have to use the ctrl-c to come out of that, to enter other commands. Using a 2.6 Kinux kernel (RH 4) This is not an issue with GNU coreutils; shell tab-completion is the responsibility of the shell, but you don't say which shell you're using so it's difficult to suggest an alternative mailing list / help forum. http://www.catb.org/~esr/faqs/smart-questions.html Perhaps try waiting a minute for the requested username completion. I suspect the shell is blocking while performing a network lookup for all valid usernames on your system. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: is hard-coding the group name, tty, portable enough for who -a?
Jim Meyering [EMAIL PROTECTED] writes: It's starting to look like the cost/benefit ratio is too high, so I don't expect to spend time on this. However, if someone can propose a portable and reliable test for that attribute, I'll be happy to consider it. How about adding a configure option to set the expected group? The default could just be tty since it's the right one for the vast majority of systems, but allows to override it if necessary. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: is hard-coding the group name, tty, portable enough for who -a?
Andreas Schwab [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: It's starting to look like the cost/benefit ratio is too high, so I don't expect to spend time on this. However, if someone can propose a portable and reliable test for that attribute, I'll be happy to consider it. How about adding a configure option to set the expected group? The default could just be tty since it's the right one for the vast majority of systems, but allows to override it if necessary. That would work on systems with a designated TTY group name. What about those older SYSV-derived systems where stat --format %G $(tty) prints the primary group of the user running who? I don't know enough about how write/who/mesg work on those systems (maybe write is set-*U*ID, not set-GID?), but patches are always welcome. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: making GNU ls -i (--inode) work around the linux readdir bug
Jim Meyering writes (Re: making GNU ls -i (--inode) work around the linux readdir bug): Phillip Susi [EMAIL PROTECTED] wrote: EVERY application that invokes ls -i is effected. Please name one. magicmirror Ian. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: making GNU ls -i (--inode) work around the linux readdir bug
EVERY application that invokes ls -i is effected. Please name one. magicmirror Which nobody uses. Try again; and this time a program that is in common use. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: is hard-coding the group name, tty, portable enough for who -a?
Jim Meyering [EMAIL PROTECTED] writes: What about those older SYSV-derived systems where stat --format %G $(tty) prints the primary group of the user running who? I wonder how they get the functionaly of write. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -v doesn't work correctly under file system mounted through FUSE
(apologies if my mailreader mangles your name - I can't easily write
in BIG-5)
On Thu, 10 Jul 2008, ¬x¥ô¿Ù wrote:
Normally, cp -rv files log should list all the files copied in the file 'log'.
However, when cp -rv a directory under file system mounted via FUSE,
redirect of I/O doesn't work. The verbose output is gone and the log file
contains nothing. Also, if I try to read the verbose output of cp command
with another program via pipe, it works with local file systems, but not
with remote file systems mounted via FUSE, such as sshfs and curlftpfs.
However, if I use forkpty in the program, it seems to partially work.
Shouldn't --verbose always give output whether the stdout is a tty or not?
Yes, it should. I suspect the filesystem emulation in your FUSE mounts
is somehow misbehaving. Perhaps you could perform the following tests
both on local disk and FUSE mount, and spot the difference in system
calls and responses?
$ mkdir a
$ touch a/{x,y,z}
$ strace -o /tmp/cp.trace -e trace=desc cp -rv a b
Hopefully it should be obvious where copying on a FUSE filesystem
differs.
Cheers,
Phil
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: making GNU ls -i (--inode) work around the linux readdir bug
Jim Meyering wrote: EVERY application that invokes ls -i is effected. Please name one. I'm not sure why this isn't getting through to you. ANY and EVERY invoker of ls -i that does or possibly could exist is effected by a degradation of its performance. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Translation failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [re-adding the list - by sending a private mail, you managed to catch me at the start of a vacation, hence the delay in replying] According to JackDesBwa on 6/23/2008 2:00 PM: | Can you repeat with 'LC_ALL=C rmdir ...' and see what the English | | translation was? | | | The translation is correct : | rmdir: failed to remove `/media/win/System Volume Information/': File exists | | | My guess is that the translation is correct, and that | the reason the message is less than stellar is because the errno value | being reported is not very applicable to the situation. All right - my guess was confirmed - the error is not in the translation, but either in the kernel's rmdir(2) behavior or in coreutils reaction to the kernel's behavior. | You may | also want | to use strace to determine what errno the kernel was returning. | | | $ strace -c rmdir /media/win/System\ Volume\ Information/ | | rmdir: échec de suppression de `/media/win/System Volume Information/': | Le fichier existe | Process 18932 detached | % time seconds usecs/call callserrors syscall | -- --- --- - - |nan0.00 0 3 read |nan0.00 0 4 write |nan0.00 05435 open |nan0.00 021 close |nan0.00 019 fstat |nan0.00 024 mmap |nan0.00 0 2 mprotect |nan0.00 0 2 munmap |nan0.00 0 3 brk |nan0.00 0 3 3 access |nan0.00 0 1 execve |nan0.00 0 1 1 rmdir |nan0.00 0 1 arch_prctl | -- --- --- - - | 100.000.00 13839 total Hmm, this output isn't from Linux strace. What OS are you using? Do you have ktrace or truss or some other syscall tracer instead? And is the NTFS drive local or is it being accessed over a network? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkh3xWUACgkQ84KuGfSFAYBHOwCYtHrfJAAuUwmhMKum4M3y8Y8c AQCeIAQhEoj43tSJyGRFIOWZ3jgEQXc= =MY0U -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: making GNU ls -i (--inode) work around the linux readdir bug
Phillip Susi [EMAIL PROTECTED] wrote: Jim Meyering wrote: EVERY application that invokes ls -i is effected. Please name one. I'm not sure why this isn't getting through to you. ANY and EVERY invoker of ls -i that does or possibly could exist is effected by a degradation of its performance. Here are two reasons: - lack of convincing arguments: any program that runs ls -i non-directory ... is not affected at all. - lack of evidence that users would be adversely affected: the only program alleged to be impacted is one that (so far) I've found no reference to, so I suspect very few people use it. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: making GNU ls -i (--inode) work around the linux readdir bug
Jim Meyering wrote: Here are two reasons: - lack of convincing arguments: any program that runs ls -i non-directory ... is not affected at all. Of course it is effected -- it takes much longer to run. - lack of evidence that users would be adversely affected: the only program alleged to be impacted is one that (so far) I've found no reference to, so I suspect very few people use it. Every single time that ls -i is run, by anyone, or anything, anywhere, EVER, it will be slower with this change. That's adversely effecting every user, which is a lot more than one. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: making GNU ls -i (--inode) work around the linux readdir bug
Phillip Susi [EMAIL PROTECTED] wrote: Jim Meyering wrote: Here are two reasons: - lack of convincing arguments: any program that runs ls -i non-directory ... is not affected at all. Of course it is effected -- it takes much longer to run. When I say not affected I mean it. Turning off the readdir optimization affects ls -i only when it reads directory entries. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
