bug#5826: [feature] chmod +S to setgid directories alike +X
Hello, I would really appreciate if chmod supported setting setgid permissions on directories (and files already having such) recursively, much like '+X' does set executable permission. To match the '+X' one, I suggest using '+S' for that. -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru
bug#5826: [feature] chmod +S to setgid directories alike +X
Michał Górny gen...@mgorny.alt.pl writes: I would really appreciate if chmod supported setting setgid permissions on directories (and files already having such) recursively, much like '+X' does set executable permission. To match the '+X' one, I suggest using '+S' for that. Since there is only a single setgid bit (unlike the exec bits) I don't see the point of +S (it looks like a no-op). Moreover, anything more complex than what chmod already provides can easily be accomplished with find. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
bug#5827: [PATCH] tail: include sys/vfs.h
Hello, the latest coreutils release 8.4 and current git master fail during the (cross-) compilation of tail. The used components are: gcc-4.3.2 glibc-2.8 binutils-2.18 The following patch fixes the commit. It's against git master, but should apply on 8.4, too. Please review and consider inclusion. Cheers, Marc From ebf1ab5bcba6f6b82bb8f0a62c949858e2a9d5cc Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde m...@pengutronix.de Date: Sat, 3 Apr 2010 14:42:29 +0200 Subject: [PATCH] tail: include sys/vfs.h This patch fixes the following error: tail.c: In function 'fremote': tail.c:882: error: storage size of 'buf' isn't known tail.c:883: warning: implicit declaration of function 'fstatfs' Signed-off-by: Marc Kleine-Budde m...@pengutronix.de --- src/tail.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/tail.c b/src/tail.c index 02c4a1a..d0bc957 100644 --- a/src/tail.c +++ b/src/tail.c @@ -57,6 +57,9 @@ # if HAVE_SYS_STATFS_H # include sys/statfs.h # endif +# if HAVE_SYS_VFS_H +# include sys/vfs.h +# endif #endif /* The official name of this program (e.g., no `g' prefix). */ -- 1.7.0.3
bug#5826: [feature] chmod +S to setgid directories alike +X
Michał Górny wrote:
I would really appreciate if chmod supported setting setgid permissions
on directories (and files already having such) recursively, much like
'+X' does set executable permission. To match the '+X' one, I suggest
using '+S' for that.
I suggest using 'find' for this. And there is an advantage to using a
standard command. It works anywhere.
$ find . -type d -exec chmod g+s {} +
Also the setgid bit isn't like the execute bit. They can't be directly
compared. There are three execute bits. The +X implements a not
completely trivial control flow. If the file is a directory OR if the
file already had the user execute bit or the group execute bit or the
other execute bit set. It is the three execute bits that makes it
non-trivial and the usefulness of the +X mode. But by contrast
setting the setgid bit is very simple. Just set it. It is only one
bit.
Plus there are security ramifications to think about when setting the
setgid bit on files. And the decisions are operating system
dependent. On most systems scripts should never be suid/sgid. And
even on systems where it is safe to do so I don't think setting the
suid/sgid bit on normal executables is something that should be done
lightly.
Bob
bug#5820: user switching
lea...@aol.com wrote: Hi, I have a copy of suse sles9 with the images provided from novell for training. When I am logged in as a user and in Konsole, I can not su to root, it asks for a password and will not take any input from the keyboard. I am not familiar with SuSE but if they are similar to others then they will not have set a default password set for the root user. That may explain the 'su' command behavior that you are seeing. Because you will need to set the root password before it can be used. But again, I don't know about SuSE in particular and I am talking about many distros in general do this. What many distros do is to set up 'sudo' so that you use your user password. This is often more convenient. You only need to know your own password and not two passwords. Try sudo. Here is an example with output showing that I have become root for that one command. Again, I don't know if this is the case for you but it likely is. $ sudo id uid=0(root) gid=0(root) groups=0(root) See the 'sudo' docs for how to use sudo. But in summary it executes the command on the command line as root. You can always use sudo to get a full shell. $ sudo bash # (Although 'sudo -s' is preferred by some.) Be careful when running commands as root. With great power comes great responsibility. When I went to the help files it said to write to you for issues, so I am writing to you. I will also be contacting Novell and see if there is an answer on their side. The GNU Coreutils are the basic utilities of the GNU Operating System. You can learn more about GNU Coreutils here: http://www.gnu.org/software/coreutils/ The GNU Coreutils are part of the GNU Operating System. You can learn more about the GNU Project here: http://www.gnu.org/ SuSE is a software distribution of these and other software projects. When you looked at the 'su' man page you were looking at the GNU man page and it referred you to report bugs in the su command here. Thank you for doing that. However this isn't a bug in 'su' but is just a specific configuration being distributed by Novell. And I am sure that it is a working one but just one that you don't have all of the details about yet. In order to get past your block you will need to get help from the vendor, or in this case since it is a lab project from other people in your lab who have already figured this out. (Although I am pretty sure, not certain, but pretty sure, that it is set up for sudo instead.) This little problem makes it impossible for me to complete on of the exercises for my lab in school. Good luck! Bob
bug#5832: Feature request: uniq -k
Please excuse the cross-post but I have been told this is the
appropriate place to place a feature request.
Is it possible to make a feature request for uniq to add the -k
option to specify
fields? Interestingly uniq already has such things as
-f, --skip-fields=N
avoid comparing the first N fields
and
-s, --skip-chars=N
avoid comparing the first N characters
but no explicit option to specify which fields should be considered
when doing the comparison. This would be very useful, for example,
when removing duplicates from time series data (where you are only
worried about consecutive duplicates on certain fields). The awk
equivalent would be something like
awk '$2$3$4$5 != p; {p=$2$3$4$5}'
for using fields 2 to 5 as comparators.
Raphael
P.S. http://www.opengroup.org/onlinepubs/9699919799/utilities/uniq.html
is the posix specification for uniq if that is of any interest.
Curiously it says nothing about which duplicate line to keep when you
don't consider all fields in the comparison.
bug#5817: false core util
tags 5817 + moreinfo unreproducible thanks phoenix wrote: I've found a serious error in the program false: If I pipe some text to it (e.g. echo i lost the game | false), it does not fail but rather returns a success. Any suggestions? As others noted the 'false' command is a builtin to most shells. Therefore if you execute the following you are not getting the coreutils version of false but are instead getting your shell builtin version of false. In this case I am running bash and bash detects the error. $ echo foo | false -bash: echo: write error: Broken pipe $ echo $? 1 $ type false false is a shell builtin $ help false false: false Return an unsuccessful result. In order to get the coreutils version you would need to specify a path to it. But the shell should still detect this error. $ echo foo | /bin/false -bash: echo: write error: Broken pipe $ echo $? 1 The main reason for a standalone executable is for legacy compatibility and also on those occations when a program that isn't a shell needs to exec a program. I need this program very much for completing my thesis on Pseudo-Riemannian manifolds. Nice! And on April 1st too! It would very kind of you if you'd inform me when the error has been fixed. (Remark: I am using Ubuntu 9.10.) I do not presently have an Ubuntu system available to test this upon but I believe it to be a problem specific to either your shell or to your environment. Coreutils false doesn't have this problem. Neither does Debian which as you know is the basis for Ubuntu. Humorous Side Note: It has been remarked that false is actually more portable than true. Because if it doesn't exist the shell's exit status is still failure. Bob
bug#5812: expr: Difference in behavior of match and :
tags 5812 + moreinfo unreproducible thanks Adil Mujeeb wrote: I have tried following snippet in a bash script: -bash-3.1$userid=`expr uid=11008(ADILM) gid=1200(cvs),1400(build) : .*uid=[0-9]*(\(.[0-9a-z]*\)) .*` -bash-3.1$echo $userid ADILM -bash-3.1$ To my knowledge it should not able to extract ADILM as the regex does not include uppercase letters (A-Z). Thank you for the bug report. It stands out as being exceptionally well written and covering the needed information. However I believe what you are seeing is intended behavior. It is an effect of the character collation sequence chosen by your locale setting. What is your locale? $ locale Your sort order depends upon your locale. You didn't say what your locale was and therefore I assume that you were not aware that it had an effect. If your locale is set to a dictionary collation sequence such as en_US.UTF-8 then this is the expected (not necessarily desired but expected) behavior. You probably expected a US-ASCII sort ordering but the powers that be (in the system, in libc, not in coreutils) have decided that the collation ordering (sort ordering) for data should be dictionary sort ordering. In dictionary ordering case is folded together and punctuation is ignored. By having LANG set to any of the en* locales the system is instructed to use dictionary sort ordering. This affects almost everything on the system that sorts. This includes commands such as 'ls' and also your shell (e.g. 'echo *') too. Plus things like 'expr'. The collation sequence of [a-z] in dictionary ordering is really aAbBcC...xXyYzZ and not abc...z. So when you say [a-z] you are getting aAbBcC...xXyYz without 'Z' and when you say [A-Z] you are really getting AbBcC...xXyYzZ with 'A'! Here is what I see with your case example: $ LC_ALL=C expr uid=11008(ADILM) gid=1200(cvs),1400(build) : .*uid=[0-9]*(\(.[0-9a-z]*\)) .* ...no output... $ LC_ALL=en_US.UTF-8 expr uid=11008(ADILM) gid=1200(cvs),1400(build) : .*uid=[0-9]*(\(.[0-9a-z]*\)) .* ADILM In the expr man page it is mentioned that: -8-- match STRING REGEXP same as STRING : REGEXP -8-- So i tried following snippet:- -bash-3.1$ userid=`expr match uid=11008(ADILM) gid=1200(cvs),1400(build) .*uid=[0-9]*(\(.[0-9a-z]*\)) .*` -bash-3.1$ echo $userid -bash-3.1$ I changed the regex and added uppercase letters:- -bash-3.1$ userid=`expr match uid=11008(ADILM) gid=1200(cvs),1400(build) .*uid=[0-9]*(\(.[0-9A-Za-z]*\)) .*` -bash-3.1$ echo $userid ADILM -bash-3.1$ So it means that match is not same as :. As per observation : uses case-insensitive matching while match is strict case sensitive matching. I cannot reproduce this behavior. But I am impressed that you went looking for it. :-) Was this perhaps tested on different machines? Or on any different login account where different locale settings may have been in effect? $ LC_ALL=C expr match uid=11008(ADILM) gid=1200(cvs),1400(build) .*uid=[0-9]*(\(.[0-9a-z]*\)) ...no output... $ LC_ALL=en_US.UTF-8 expr match uid=11008(ADILM) gid=1200(cvs),1400(build) .*uid=[0-9]*(\(.[0-9a-z]*\)) ADILM In addition to setting LC_ALL=C in scripts that need standard behavior you may want to use POSIX character classes here. They may help with situations such as yours. $ LC_ALL=C expr match uid=11008(ADILM) gid=1200(cvs),1400(build) .*uid=[[:digit:]]*(\(.[[:digit:][:upper:]]*\)) ADILM $ LC_ALL=en_US.UTF-8 expr match uid=11008(ADILM) gid=1200(cvs),1400(build) .*uid=[[:digit:]]*(\(.[[:digit:][:upper:]]*\)) ADILM $ LC_ALL=C expr match uid=11008(ADILM) gid=1200(cvs),1400(build) .*uid=[[:digit:]]*(\(.[[:digit:][:lower:]]*\)) ...no output... $ LC_ALL=en_US.UTF-8 expr match uid=11008(ADILM) gid=1200(cvs),1400(build) .*uid=[[:digit:]]*(\(.[[:digit:][:lower:]]*\)) ...no output... Can you update the man page OR let me know if i am doing anything wrong? This is something that has such global behavior that the problem comes in where do you document it? It shouldn't be documented everywhere. It is a libc behavior and everything that uses libc (everything!) will get the same behavior. But 'sort' has taken the full force of it and so you might look there for the best explanations. The sort documentation says: Unless otherwise specified, all comparisons use the character collating sequence specified by the `LC_COLLATE' locale.(1) ... (1) If you use a non-POSIX locale (e.g., by setting `LC_ALL' to `en_US'), then `sort' may produce output that is sorted differently than you're accustomed to. In that case, set the `LC_ALL' environment variable to `C'. Note that setting only `LC_COLLATE' has two problems. First, it is ineffective if `LC_ALL' is also set. Second, it has undefined behavior if `LC_CTYPE' (or `LANG', if `LC_CTYPE' is unset) is set to an incompatible value. For example, you get undefined behavior if `LC_CTYPE' is `ja_JP.PCK' but `LC_COLLATE' is
bug#5820: user switching
Craig Leach wrote: Hi Bob, The images provided did have passwords set up. There must have been an issue with the initial loading of the image that didn't become apparent until this point. I have since done a repair install on VMWare and reinstalled the images and all is working fine now. I thank you for your timely and informative response. Oh good! I am closing this bug report then. Bob
