bug#9250: acknowledged by developer (Re: bug#9250: Bug chmod)
Good morning, I apologize for not having responded at once: I have family problems kept away from the Internet. I reinstalled Backtrack: the problem is not replay. Thanks,cordially, Daniela Landi 2011/11/10 GNU bug Tracking System help-debb...@gnu.org This is an automatic notification regarding your bug report #9250: Bug chmod, which was filed against the coreutils package. Thank you for your report, which has now been closed. You can view the full report at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9250 If you require further information, please followup to 9...@debbugs.gnu.org. debbugs.gnu.org maintainers (administrator, GNU bugs database)
bug#9939: bug#10016: ls -lk is wrong
Paul Eggert wrote: On 11/11/11 13:10, Jim Meyering wrote: Do you feel like writing the patch? Sure. I wrote and pushed the following. The test case isn't elegant, but at least it catches the bug. That was quick. Thanks!
bug#10019: sort options -Mn are incompatible
On 11/11/11 9:43 PM, Paul Eggert wrote: On 11/11/2011 11:36 AM, Lars Noodén wrote: An additional line of clarification would go a long way in making this very useful capability more available. Hmm, what line would that be? We do have a tradeoff among clarity, completeness, and conciseness here. Maybe something like this? -k, --key=POS1[,POS2][ORD] start a key at POS1 (origin 1), end it at POS2 (default end of line) using ordering option(s) ORD (fghMnrR) By the way, the info page (which is the actual documentation for 'sort' -- the man page is a poor substitute) has a series of examples, one of which is how to sort Apache log files. This kind of detail is too long for sort --help, alas. http://www.gnu.org/s/coreutils/manual/html_node/sort-invocation.html Yes, that info page is quite complete. I wish more were like that. I've had the bad luck to run into many before that appear to be only place holders. /Lars
bug#10019: sort options -Mn are incompatible
On 11/12/2011 03:49 AM, Lars Noodén wrote: On 11/11/11 9:43 PM, Paul Eggert wrote: On 11/11/2011 11:36 AM, Lars Noodén wrote: An additional line of clarification would go a long way in making this very useful capability more available. Hmm, what line would that be? We do have a tradeoff among clarity, completeness, and conciseness here. Maybe something like this? -k, --key=POS1[,POS2][ORD] start a key at POS1 (origin 1), end it at POS2 (default end of line) using ordering option(s) ORD (fghMnrR) Except you missed out on at least b and V. Also, the current wording: -k, --key=POS1[,POS2] start a key at POS1 (origin 1), end it at POS2 (default end of line). See POS syntax below was nice in referring to the text at the bottom: POS is F[.C][OPTS], where F is the field number and C the character position in the field; both are origin 1. If neither -t nor -b is in effect, characters in a field are counted from the beginning of the preceding whitespace. OPTS is one or more single-letter ordering options, which override global ordering options for that key. If no key is given, use the entire line as the key. In particular, -k1b,1 is different than -k1,1b, but most other OPTS can occur in either position with no change in behavior. I like [OPTS] slightly better than [ORD], given that you can have more than one (as in -k1bn,1). I do agree that on the -k line, the use of POSn hides the [.C][OPTS] of the text below, and that it is too easy to think that POSn is a synonym for just the F. POSIX calls the same thing 'keydef', so maybe: -k --key=KEYDEF control where a key starts and ends, and give ordering specific to the key. See KEYDEF below. KEYDEF is F[.C][OPTS][,F[.C][OPTS]], where F is a field number and C a character position in the field; both are origin 1. If the second position is omitted, the key runs to the end of the line. If neither -t nor -b is in effect, characters in a field are counted from the beginning of the preceding whitespace. OPTS is one or more single-letter ordering options [bdfgiMhnRrV], which override global ordering options for that key. If no key is given, use the entire line as the key. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#9250: acknowledged by developer (Re: bug#9250: Bug chmod)
daniela landi wrote: I reinstalled Backtrack: the problem is not replay. Oh good! Good to hear that it is all working for you. Bob
bug#10019: sort options -Mn are incompatible
On 11/12/11 05:54, Eric Blake wrote: -k --key=KEYDEF control where a key starts and ends, and give ordering specific to the key. See KEYDEF below. KEYDEF is F[.C][OPTS][,F[.C][OPTS]], where F is a field number and C a character position in the field; both are origin 1. If the second position is omitted, the key runs to the end of the line. If neither -t nor -b is in effect, characters in a field are counted from the beginning of the preceding whitespace. OPTS is one or more single-letter ordering options [bdfgiMhnRrV], which override global ordering options for that key. If no key is given, use the entire line as the key. That's nicer, but a bit longer. How about this attempt to shorten its first two sentences? -k, --key=KEYDEF sort via a key; KEYDEF gives location and type ... KEYDEF is F[.C][OPTS][,F[.C][OPTS]], where F is a field number and C a character position in the field; both are origin 1, and the key's end defaults to the line's end. with the remainder as before.
bug#10021: [PATCH id] Add error-checking on GNU
Hi Jim,
Thanks for the quick review!
Jim Meyering j...@meyering.net skribis:
However, wouldn't that fail unnecessarily for a process without
one ID even though id is being asked to print some other(s)?
E.g., it'd fail for a process with no EUID even when id
is being asked to print only the real UID or GIDs.
Indeed.
Also, if you send another version, please indent only with spaces
and change each diagnostic to start with lower case letter.
Sure. (There’s one just above that doesn’t follow the rule.)
You may want to run make syntax-check to check for things like that.
OK.
Here’s an updated patch with a test case.
I don’t have a copyright assignment on file for Coreutils but I guess
it’s OK for this change?
Thanks,
Ludo’.
From b1e9324ea83a2df604256d7d41d25440e21dd2d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= l...@gnu.org
Date: Sat, 12 Nov 2011 01:25:45 +0100
Subject: [PATCH] id: error out for zero UIDs/GIDs on GNU/Hurd
* src/id.c (main)[__GNU__]: Check for EUID, RUID, EGID, or RGID = -1;
raise an error when appropriate.
* tests/Makefile.am (TESTS): Add `id/gnu-zero-uids'.
* tests/id/gnu-zero-uids: New file.
* tests/init.cfg (require_gnu_): New function.
---
src/id.c | 21 +
tests/Makefile.am |1 +
tests/id/gnu-zero-uids | 31 +++
tests/init.cfg |8
4 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 tests/id/gnu-zero-uids
diff --git a/src/id.c b/src/id.c
index f80fcd1..9325282 100644
--- a/src/id.c
+++ b/src/id.c
@@ -202,9 +202,30 @@ main (int argc, char **argv)
else
{
euid = geteuid ();
+#ifdef __GNU__
+ if (euid == -1 !use_real
+ !just_group !just_group_list !just_context)
+error (EXIT_FAILURE, errno, _(cannot get effective UID));
+#endif
+
ruid = getuid ();
+#ifdef __GNU__
+ if (ruid == -1 use_real
+ !just_group !just_group_list !just_context)
+error (EXIT_FAILURE, errno, _(cannot get real UID));
+#endif
+
egid = getegid ();
+#ifdef __GNU__
+ if (egid == -1 !use_real !just_user)
+error (EXIT_FAILURE, errno, _(cannot get effective GID));
+#endif
+
rgid = getgid ();
+#ifdef __GNU__
+ if (rgid == -1 use_real !just_user)
+error (EXIT_FAILURE, errno, _(cannot get real GID));
+#endif
}
if (just_user)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5021c18..80f95b1 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -399,6 +399,7 @@ TESTS = \
du/slink \
du/trailing-slash\
du/two-args \
+ id/gnu-zero-uids\
id/no-context \
install/basic-1\
install/create-leading \
diff --git a/tests/id/gnu-zero-uids b/tests/id/gnu-zero-uids
new file mode 100644
index 000..b4a7d5a
--- /dev/null
+++ b/tests/id/gnu-zero-uids
@@ -0,0 +1,31 @@
+#!/bin/sh
+# On GNU, `id' must fail for processes with zero UIDs.
+
+# Copyright (C) 2011 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+. ${srcdir=.}/init.sh; path_prepend_ ../src
+print_ver_ id
+
+require_gnu_
+
+if sush - true; then
+# Run `id' with zero UIDs. It should exit with a non-zero status.
+sush - id out fail=1
+else
+skip_ the \`sush' command does not work
+fi
+
+Exit $fail
diff --git a/tests/init.cfg b/tests/init.cfg
index 915f38a..f5f27dd 100644
--- a/tests/init.cfg
+++ b/tests/init.cfg
@@ -499,4 +499,12 @@ print_ver_()
fi
}
+# Are we running on GNU/Hurd?
+require_gnu_()
+{
+ if test `uname` != GNU; then
+ skip_ 'not running on GNU/Hurd'
+ fi
+}
+
sanitize_path_
--
1.7.6
pgpgmV9TWGefw.pgp
Description: PGP signature
bug#10021: [PATCH id] Add error-checking on GNU
On 11/12/11 13:48, Ludovic Courtès wrote: +#ifdef __GNU__ + if (euid == -1 !use_real + !just_group !just_group_list !just_context) +error (EXIT_FAILURE, errno, _(cannot get effective UID)); +#endif I suggest removing the #ifdef __GNU__ here and in its other three uses in the patch, as functions like as geteuid() can fail on a few non-GNU systems too. See: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Fapis%2Fgeteuid.htm For this particular application (the 'id' program) I doubt whether it's worth our time to configure this stuff at compile-time, and that it's fine to do a run-time check on all platforms.
bug#10030: grep: strange behavior with '-' in character class
Hello Coreutils Team, When I use the command: echo /lib64/ld-linux-x86-64.so.2 | grep -o '[a-zA-Z\/0-9\-\.]*' The result is that I get a tokenized string where - has been replaced with \n /lib64/ld linux x86 64.so.2 The expected result is: /lib64/ld-linux-x86-64.so.2 When the character class is modified so that the - is not next to the number 9: echo /lib64/ld-linux-x86-64.so.2 | grep -o '[a-zA-Z\/0-9\.\-]*' /lib64/ld-linux-x86-64.so.2 The expected result is obtained. I am aware - is used to specify a range, but it is escaped, should this be the proper behaviour? Thanks, Tom
bug#10030: grep: strange behavior with '-' in character class
I have since learned that you are not supposed to escape things within brackets at all and simply position them so they have relevant meaning, and that dot does not need to be escaped inside brackets. Not sure if my mail is still relevant. On 11/12/2011 02:05 PM, Thomas Dignan wrote: Hello Coreutils Team, When I use the command: echo /lib64/ld-linux-x86-64.so.2 | grep -o '[a-zA-Z\/0-9\-\.]*' The result is that I get a tokenized string where - has been replaced with \n /lib64/ld linux x86 64.so.2 The expected result is: /lib64/ld-linux-x86-64.so.2 When the character class is modified so that the - is not next to the number 9: echo /lib64/ld-linux-x86-64.so.2 | grep -o '[a-zA-Z\/0-9\.\-]*' /lib64/ld-linux-x86-64.so.2 The expected result is obtained. I am aware - is used to specify a range, but it is escaped, should this be the proper behaviour? Thanks, Tom
bug#10030: grep: strange behavior with '-' in character class
tags 10030 + notabug close 10030 thanks Thomas Dignan wrote: I have since learned that you are not supposed to escape things within brackets at all and simply position them so they have relevant meaning, and that dot does not need to be escaped inside brackets. That's right. You have it. Not sure if my mail is still relevant. Well... Not really. But mostly because you sent your bug report to bug-coreutils instead of bug-grep. Wrong bug list! Since you have it figured out and it is the wrong list I am going to go ahead and mark the bug as closed. You can follow up with bug-grep if you have another report. Bob
