who(1) exit status
Hi, who(1) exit status is always 0. $ who --v who (coreutils) 5.2.1 ... ... $ who $echo $? 0 I think all commands should fail with exit status 1, which is usefull in processing with other commands. Thanks Shal ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: who(1) exit status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Shal-Linux-Ind on 6/23/2008 4:05 AM: | Hi, | | who(1) exit status is always 0. | | $ who --v | who (coreutils) 5.2.1 Thanks for the report. Consider upgrading - that is several years old, and the latest stable version is 6.12. But I have confirmed that the issue still exists in git beyond 6.12: $ who /nosuch/file; echo $? 0 $ who --version | head -n1 who (GNU coreutils) 6.12.66-c1aab - -- 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 iEYEARECAAYFAkhflDwACgkQ84KuGfSFAYD+KgCgkKz6cXvzBs12ibmEhFPk7Y6R B0QAmgJ5nTY4wmqyvSOx2Y7zP3aWC82a =esgg -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: who(1) exit status
Eric Blake <[EMAIL PROTECTED]> writes: > According to Shal-Linux-Ind on 6/23/2008 4:05 AM: > | Hi, > | > | who(1) exit status is always 0. > | > | $ who --v > | who (coreutils) 5.2.1 > > Thanks for the report. Consider upgrading - that is several years old, > and the latest stable version is 6.12. But I have confirmed that the > issue still exists in git beyond 6.12: > > $ who /nosuch/file; echo $? > 0 See the comment in read_utmp: /* Ignore the return value for now. Solaris' utmpname returns 1 upon success -- which is contrary to what the GNU libc version does. In addition, older GNU libc versions are actually void. */ UTMP_NAME_FUNCTION (file); When using the utmpname/setutent/getutmp family of functions there really is no way to check for errors reading the file, since utmpname does not actually try to open it, and setutent has no return value. 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
[PATCH]: Replace echo AUTHORS FIXME unknown by bash builtin echo authors
Hello,
according to bash sources(AUTHORS file), authors of bash built-in echo
are Brian Fox, Chet Ramey. As coreutils echo is derived from bash
builtin echo, I guess those authors should be used instead of FIXME
unknown. Patch fixing echo authors is attached. This problem has been
reported at
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/175111 .
Anyway - there is still one file with FIXME unknown author - basename.
I tried to find out the author, but I think I don't have enough
informations to google it. Any idea? It would be good to get rid off
those FIXME unknown authors.
Greetings,
Ondrej Vasik
From 8295e6b94d18940065adfbf19b6fbbc1137a28e5 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ond=C5=99ej=20Va=C5=A1=C3=ADk?= <[EMAIL PROTECTED]>
Date: Mon, 23 Jun 2008 14:00:26 +0200
Subject: [PATCH] Add echo author (used author from bash echo)
* AUTHORS,src/echo.c: Use bash builtin echo authors instead of FIXME unknown
Signed-off-by: Ondřej Vašík <[EMAIL PROTECTED]>
---
AUTHORS|2 +-
src/echo.c |4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/AUTHORS b/AUTHORS
index 404cf70..666edc1 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -22,7 +22,7 @@ dir: Richard M. Stallman, David MacKenzie
dircolors: H. Peter Anvin
dirname: David MacKenzie, Jim Meyering
du: Torbjörn Granlund, David MacKenzie, Paul Eggert, Jim Meyering
-echo: FIXME unknown
+echo: Brian Fox, Chet Ramey
env: Richard Mlynarik, David MacKenzie
expand: David MacKenzie
expr: Mike Parker
diff --git a/src/echo.c b/src/echo.c
index ebbf5b8..11e648e 100644
--- a/src/echo.c
+++ b/src/echo.c
@@ -24,7 +24,9 @@
/* The official name of this program (e.g., no `g' prefix). */
#define PROGRAM_NAME "echo"
-#define AUTHORS proper_name ("FIXME unknown")
+#define AUTHORS \
+ proper_name ("Brian Fox"), \
+ proper_name ("Chet Ramey")
/* echo [-neE] [arg ...]
Output the ARGs. If -n is specified, the trailing newline is
--
1.5.2.2
signature.asc
Description: Toto je digitálně podepsaná část zprávy
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: Replace echo AUTHORS FIXME unknown by bash builtin echo authors
Ondřej Vašík <[EMAIL PROTECTED]> wrote: > according to bash sources(AUTHORS file), authors of bash built-in echo > are Brian Fox, Chet Ramey. As coreutils echo is derived from bash > builtin echo, I guess those authors should be used instead of FIXME > unknown. Patch fixing echo authors is attached. This problem has been > reported at > https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/175111 . Thanks. Applied. > Anyway - there is still one file with FIXME unknown author - basename. > I tried to find out the author, but I think I don't have enough > informations to google it. Any idea? It would be good to get rid off > those FIXME unknown authors. Good point. I'll list David J. MacKenzie, since odds are very good he's the one who added most of the initial code, regardless. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: who(1) exit status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bo Borgerson on 6/23/2008 6:59 AM: | So it sounds like there's no portable way to distinguish between: | | 1. an error trying to look up information | 2. no information to be found | | Would it make sense, though, to return a nonzero exit code when output | is empty in either case? POSIX requires an error message to stderr explaining the non-zero status. ~ What would we report? On the other hand, it seems like we should always expect at least the current user to be logged in (otherwise, how is who being invoked?), so the idea of an error on no output seems reasonable to me. - -- 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 iEYEARECAAYFAkhfn5MACgkQ84KuGfSFAYAnrgCeJ0WOSnhrnod/CkUKtvl9iFVP JIQAoNYTI9uSejXynBindVCIOD8rLFgr =j4OM -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: who(1) exit status
Eric Blake <[EMAIL PROTECTED]> writes: > POSIX requires an error message to stderr explaining the non-zero status. > ~ What would we report? On the other hand, it seems like we should always > expect at least the current user to be logged in (otherwise, how is who > being invoked?), so the idea of an error on no output seems reasonable to me. You don't have to be logged in to be able to (remotely) execute commands. 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: who(1) exit status
Andreas Schwab wrote: > Eric Blake <[EMAIL PROTECTED]> writes: > >> According to Shal-Linux-Ind on 6/23/2008 4:05 AM: >> | Hi, >> | >> | who(1) exit status is always 0. >> | >> | $ who --v >> | who (coreutils) 5.2.1 >> >> Thanks for the report. Consider upgrading - that is several years old, >> and the latest stable version is 6.12. But I have confirmed that the >> issue still exists in git beyond 6.12: >> >> $ who /nosuch/file; echo $? >> 0 > > See the comment in read_utmp: > > /* Ignore the return value for now. > Solaris' utmpname returns 1 upon success -- which is contrary > to what the GNU libc version does. In addition, older GNU libc > versions are actually void. */ > UTMP_NAME_FUNCTION (file); > > When using the utmpname/setutent/getutmp family of functions there > really is no way to check for errors reading the file, since utmpname > does not actually try to open it, and setutent has no return value. Hi, So it sounds like there's no portable way to distinguish between: 1. an error trying to look up information 2. no information to be found Would it make sense, though, to return a nonzero exit code when output is empty in either case? Thanks, Bo ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: check-AUTHORS fails because of non ansi characters
On Sat, Jun 21, 2008 at 06:10:28PM +0200, Bruno Haible wrote: > Michael must be using a locale in ASCII encoding; if it were a Latin1 > encoding, > the output would have contained a cedilla, not a question mark. I did not have the en_US.UTF8 locale installed. After installing it the problem disappeared. Thanks, Michael ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Translation failure
Hello, I think there is a failure in the french translation of "rmdir". This morning I tried to remove a non empty directory and rmdir said it can't delete because the file exists. Probably it wanted to say that there were files in this directory. The exact message was : "rmdir: échec de suppression de `/media/win/System Volume Information/': Le fichier existe". It was on a NTFS filesystem. ___ 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 According to JackDesBwa on 6/23/2008 12:50 PM: | Hello, | | I think there is a failure in the french translation of "rmdir". | | This morning I tried to remove a non empty directory and rmdir said it can't | delete because the file exists. Can you repeat with 'LC_ALL=C rmdir ...' and see what the English translation was? 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. You may also want to use strace to determine what errno the kernel was returning. Actually pasting in the sequence of what you typed at your console, rather than describing just the resulting error message, would be helpful as well. - -- 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 iEYEARECAAYFAkhf9CEACgkQ84KuGfSFAYA26gCcCD4q0wJh9JIYjQwZgEI6ToZp tO0AmgKcZyufW22+kpTdUndoAjOA3mHO =Sr32 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -up forever
Fellas, in http://bugs.debian.org/276500 m> There is a new syscall in 2.6.22, utimensat. It gets a "struct timespec" m> which allows nanosecond resolution. That means you can now fix the difference in $ touch m; touch -r m n; stat -c %y m n 2008-06-24 06:13:24.106160298 +0800 2008-06-24 06:13:24.10616 +0800 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -up forever
jidanni.org> writes: > > Fellas, in http://bugs.debian.org/276500 > m> There is a new syscall in 2.6.22, utimensat. It gets a "struct timespec" > m> which allows nanosecond resolution. > That means you can now fix the difference in > $ touch m; touch -r m n; stat -c %y m n > 2008-06-24 06:13:24.106160298 +0800 > 2008-06-24 06:13:24.10616 +0800 > You're behind the times (pardon the pun). Coreutils was already fixed to use utimensat (when it works) as of 6.12. However, after the release, there was a utimensat bug discovered for some kernel versions, so it may take current git sources (or wait for 6.13) to work around those bugs. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: who(1) exit status
On 6/23/08, Andreas Schwab <[EMAIL PROTECTED]> wrote: > > Eric Blake <[EMAIL PROTECTED]> writes: > > > According to Shal-Linux-Ind on 6/23/2008 4:05 AM: > > | Hi, > > | > > | who(1) exit status is always 0. > > | > > | $ who --v > > | who (coreutils) 5.2.1 > > > > Thanks for the report. Consider upgrading - that is several years old, > > and the latest stable version is 6.12. But I have confirmed that the > > issue still exists in git beyond 6.12: > > > > $ who /nosuch/file; echo $? > > 0 > > > See the comment in read_utmp: > > /* Ignore the return value for now. > Solaris' utmpname returns 1 upon success -- which is contrary > to what the GNU libc version does. In addition, older GNU libc > versions are actually void. */ > UTMP_NAME_FUNCTION (file); > > When using the utmpname/setutent/getutmp family of functions there > really is no way to check for errors reading the file, since utmpname > does not actually try to open it, and setutent has no return value. > > **utmpname() returns integer, only when failure on allocating memory its > returning -1, its best to include the file existance checking before memory > allocation, and returning -1 if no such file exists. > > **Need to check the compitibilty breaking, I think there is no > compitibility breaking. > > **Thanks,Halesh > > 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
