Re: stat vs. "-"
Eric Blake wrote: > Jim Meyering meyering.net> writes: >> > But how would you make it work *with* -f? You don't know the path of the >> > file used to create stdin (and in the case of a pipe, there is no path), >> >> There is no need for an actual file name, since fstatfs >> takes a file descriptor. Of course, there's the issue >> that some systems don't have a usable fstatfs... > > Or fstatvfs, if you go by POSIX. I stand corrected; it looks like we _can_ > try > to implement 'stat -f -', so I agree that we ought to do so for the > consistency > aspect. I'm okay with failing with ENOSYS or ENOTSUP on platforms that lack a > working fstat[v]fs. I don't have time to do that right now. If you feel like doing it, you're welcome to straighten it out. I've just pushed what I just posted.
Re: stat vs. "-"
Jim Meyering meyering.net> writes: > > But how would you make it work *with* -f? You don't know the path of the > > file used to create stdin (and in the case of a pipe, there is no path), > > There is no need for an actual file name, since fstatfs > takes a file descriptor. Of course, there's the issue > that some systems don't have a usable fstatfs... Or fstatvfs, if you go by POSIX. I stand corrected; it looks like we _can_ try to implement 'stat -f -', so I agree that we ought to do so for the consistency aspect. I'm okay with failing with ENOSYS or ENOTSUP on platforms that lack a working fstat[v]fs. -- Eric Blake
Re: stat vs. "-"
Eric Blake wrote: > According to Jim Meyering on 9/29/2009 6:44 AM: >> stat has two modes of operation: the default is to interpret each >> argument as a file on which to call stat or lstat. >> Then there's the --file-system (-f) option. >> >> The "-" == stdin approach makes sense for the first case. >> Since I couldn't think of a use case for the second, >> I was debating to implement it there regardless, >> for the sake of consistency. Otherwise, I'd have to >> document that it works only *without* -f. > > But how would you make it work *with* -f? You don't know the path of the > file used to create stdin (and in the case of a pipe, there is no path), There is no need for an actual file name, since fstatfs takes a file descriptor. Of course, there's the issue that some systems don't have a usable fstatfs... > so what would you pass to statvfs? I don't see any option other than to > go with documenting that -f and - do not work together; and we should make > attempts to mix them fail with an error.
Re: stat vs. "-"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/29/2009 6:44 AM: > stat has two modes of operation: the default is to interpret each > argument as a file on which to call stat or lstat. > Then there's the --file-system (-f) option. > > The "-" == stdin approach makes sense for the first case. > Since I couldn't think of a use case for the second, > I was debating to implement it there regardless, > for the sake of consistency. Otherwise, I'd have to > document that it works only *without* -f. But how would you make it work *with* -f? You don't know the path of the file used to create stdin (and in the case of a pipe, there is no path), so what would you pass to statvfs? I don't see any option other than to go with documenting that -f and - do not work together; and we should make attempts to mix them fail with an error. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -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/ iEYEARECAAYFAkrCBXQACgkQ84KuGfSFAYCbbQCeKyEgTeEFxvEKunG8ym81CzUm BEcAoJrOZnNTzhNyKtStgytphS2FJOlg =XTbm -END PGP SIGNATURE-
Re: stat vs. "-"
Eric Blake wrote: > According to Jim Meyering on 9/15/2009 5:49 AM: >> But couldn't, because stat didn't accept "-" as meaning standard input. >> Here's a patch to make it do that (and make the above print what's >> displayed): >> >> This is just FYI. >> Of course I'll add the usual NEWS, log and tests and post again later. > > Any progress on this? It sounded like a nice idea. Thanks for the reminder. Here's why I've put it off: stat has two modes of operation: the default is to interpret each argument as a file on which to call stat or lstat. Then there's the --file-system (-f) option. The "-" == stdin approach makes sense for the first case. Since I couldn't think of a use case for the second, I was debating to implement it there regardless, for the sake of consistency. Otherwise, I'd have to document that it works only *without* -f. As I write this, however, I'm inclined to be consistent, even a plausible use case for -f. Besides, before I encountered the need for "stat -", I might not have been able to come up with a good use case either.
Re: stat vs. "-"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/15/2009 5:49 AM: > But couldn't, because stat didn't accept "-" as meaning standard input. > Here's a patch to make it do that (and make the above print what's displayed): > > This is just FYI. > Of course I'll add the usual NEWS, log and tests and post again later. Any progress on this? It sounded like a nice idea. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -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/ iEYEARECAAYFAkrB/toACgkQ84KuGfSFAYDU2ACfVZp307iAUuJKUh6v0947FWWj gAIAniMXLHj9W6x6ZT+KQoEasOro4+3C =lKrI -END PGP SIGNATURE-
stat vs. "-"
In looking at Pádraig's report of a tail test failure with ksh,
I wanted to see how ksh pipes differed from bash/zsh ones,
by doing this:
for i in sh zsh bash ksh; do printf "$i: "; $i -c ':|./stat --format=%F -';done
sh: fifo
zsh: fifo
bash: fifo
ksh: socket
But couldn't, because stat didn't accept "-" as meaning standard input.
Here's a patch to make it do that (and make the above print what's displayed):
diff --git a/src/stat.c b/src/stat.c
index 3302270..56d25e6 100644
--- a/src/stat.c
+++ b/src/stat.c
@@ -857,7 +857,15 @@ do_stat (char const *filename, bool terse, char const
*format)
{
struct stat statbuf;
- if ((follow_links ? stat : lstat) (filename, &statbuf) != 0)
+ if (STREQ (filename, "-"))
+{
+ if (fstat (STDIN_FILENO, &statbuf) != 0)
+{
+ error (0, errno, _("cannot stat standard input"));
+ return false;
+}
+}
+ else if ((follow_links ? stat : lstat) (filename, &statbuf) != 0)
{
error (0, errno, _("cannot stat %s"), quote (filename));
return false;
This is just FYI.
Of course I'll add the usual NEWS, log and tests and post again later.
[PATCH] tests: ls/stat-vs-dirent: avoid spurious test failure
I noticed this test fail when run from this directory: /dev/shm/.j/coreutils-7.5.54-70ea Here's the fix: >From c392c4b8ef5de84d67d354bb2ecdd544466c50c8 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 5 Sep 2009 19:06:31 +0200 Subject: [PATCH] tests: ls/stat-vs-dirent: avoid spurious test failure * tests/ls/stat-vs-dirent: Avoid test failure when run from a directory whose name (or ancestor directory name) starts with ".". --- tests/ls/stat-vs-dirent |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/tests/ls/stat-vs-dirent b/tests/ls/stat-vs-dirent index 064ec12..9f2b149 100755 --- a/tests/ls/stat-vs-dirent +++ b/tests/ls/stat-vs-dirent @@ -43,7 +43,10 @@ while :; do # Make sure that they are the same. # We know from experience that there may be mismatches on some # buggy file systems, at mount points. -if test "$d_ino" != "$st_ino"; then +# Note that when a directory contains only entries whose names +# start with ".", d_ino and file will both be empty. In that case, +# skip the test. +if test -n "$d_ino" && test "$d_ino" != "$st_ino"; then echo "$0: test failed: $t/$file: d_ino($d_ino) != st_ino($st_ino) This may indicate a flaw in your kernel or file system implementation. The flaw isn't serious for coreutils, but it might break other tools, -- 1.6.4.2.409.g85dc3
fix diagnostic in tests/ls/stat-vs-dirent
Here are the symptoms: ./stat-vs-dirent: test failed: /export/duryea: d_ino(42214) != st_ino(2) ./stat-vs-dirent: This may indicate a flaw in your kernel or file system implem\ entation. ./stat-vs-dirent: This flaw won't impact coreutils, but it may well ./stat-vs-dirent: affect other tools,: not found ./stat-vs-dirent: so you should report it to your operating system vendor. PASS: stat-vs-dirent The 'not found' is the problem. Also, the message can be reworded to be a bit clearer and easy to read. I installed the following patch, which changes the symptoms to be as follows: ./stat-vs-dirent: test failed: /export/duryea: d_ino(42214) != st_ino(2) This may indicate a flaw in your kernel or file system implementation. The flaw isn't serious for coreutils, but it might break other tools, so you should report it to your operating system vendor. PASS: stat-vs-dirent 2006-09-18 Paul Eggert <[EMAIL PROTECTED]> * tests/ls/stat-vs-dirent: Fix quoting problem in diagnostic indicating flaw in kernel. Reword to say that the flaw isn't serious for coreutils, since the flaw does affect ls -i. --- stat-vs-dirent 17 Aug 2006 19:58:31 - 1.3 +++ stat-vs-dirent 18 Sep 2006 16:34:27 - 1.4 @@ -60,12 +60,10 @@ while :; do # We know from experience that there may be mismatches on some # buggy file systems, at mount points. if test "$d_ino" != "$st_ino"; then - echo "$0: test failed: $t/$file: d_ino($d_ino) != st_ino($st_ino)" 1>&2 - echo "$0: This may indicate a flaw in your kernel or" \ -"file system implementation." 1>&2 - echo "$0: This flaw won't impact coreutils, but it may well" -"affect other tools," - echo "$0: so you should report it to your operating system vendor." 1>&2 + echo "$0: test failed: $t/$file: d_ino($d_ino) != st_ino($st_ino) + This may indicate a flaw in your kernel or file system implementation. + The flaw isn't serious for coreutils, but it might break other tools, + so you should report it to your operating system vendor." 1>&2 # This test fails too often, and we don't want to be distracted # with reports, since the code that could be affected by the losing ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
