Re: whoami problem when two or more users have the same uid
Thanks for your explanation Bob. I will keep root above my other user in the passwd file, so that all the scripts out there will continue to work properly. Best regards. Flaviano 2008/8/10 Bob Proulx [EMAIL PROTECTED]: First, thank you for making this suggestion. However I do not believe this to be a deficency of the whoami command. This is expected behavior in the GNU and Unix systems. flaviano petrocchi wrote: I use an alternate root user with login capabilities, created with useradd -u 0 -o -g 0 -G 0 -m -s /bin/bash superuser. Note that you are simply creating a new way to log into the account. You are not creating a new account. You are simply enabling a new way to log into the existing root superuser account. I think that is a key point. It isn't a separate account. This isn't even a documented behavior as far as I know. It is simply the way the implementation has always worked. If I login with superuser, whoami returns root or superuser depending on which user comes before in the /etc/passwd file. Yes. That is because the password file defines the mapping from uid to name. The first one in the file defines the name. This is the way it has always worked. For decades. echo $USER instead always returns the correct user name. Caution here. The USER variable is sometimes overridden by the operating system. In particular Red Hat overrides USER and LOGNAME from their original settings in /etc/profile. Traditionally LOGNAME referred to the name the user used to log into the system. (This was also available with 'who am i' too.) RH breaks this by setting both LOGNAME and USER to the output of 'id -un'. Other systems that I am familiar with (Debian, Ubuntu, SuSE, HP-UX, Solaris) do not override the value. I think whoami should always report the correct name maybe The disagreement here is on the correct name. The correct name is the named defined for the current effective user id from the password database (not necessarily the /etc/passwd file for example if NIS/YP or LDAP is in use). The correct name is not the $USER nor $LOGNAME since those might be changed and invalid in the environment. retrieving the USER environment variable instead of parsing the passwd file. Those who use whoami to check if a user is root should instead use id -u and check if the uid is 0. The 'whoami' command must map the current user id to the associated name. Otherwise too much system breakage would occur. For example contemplate the following: $ USER=foo whoami foo That wouldn't be good. If a script desires to use $USER then the script should simply use $USER instead of calling 'whoami'. Also although I admit that while I usually use 'whoami' in my scripts the standard POSIX standard method would be to use 'id -un'. Note that 'whoami' is a BSD derived utility and isn't standardized by POSIX. BSD therefore is the reference for the behavior of this command. This has decades of legacy behavior and therefore it really isn't practical to try to change the behavior now. Instead new behavior should be part of a new command. But in this case what you wish is easily available simply by using the $USER value directly so there really isn't a need to put this in a command at all. See also the 'logname' and 'who am i' commands. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm opensolaris ntfs-3g problem
On Sun, 10 Aug 2008, Andras Barna wrote: on opensolaris (update 94) can't remove recursively directories. @osol /ntfs: /usr/gnu/bin/mkdir -p t/t/t/t/t/t/t/t/t/t//t/t///t//t/t/t/ @osol /ntfs: /usr/gnu/bin/rm --version|head -1 rm (GNU coreutils) 6.7 @osol /ntfs: rm -rf t rm: cannot remove directory `t': Directory not empty @osol /ntfs: rm -r t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example shows the default rm (PATH not shown) failing to remove a directory tree, but succeeding on the second attempt. @osol /ntfs: /usr/gnu/bin/mkdir -p t/t/t/t/t/t/t/t/t/t//t/t///t//t/t/t/ @osol /ntfs: /data/a/bin/rm --version|head -1 rm (GNU coreutils) 6.12 @osol /ntfs: /data/a/bin/rm -rf t @osol /ntfs: echo $? 0 @osol /ntfs: ls t t @osol /ntfs: /data/a/bin/rm -r t @osol /ntfs: ls t t @osol /ntfs: /data/a/bin/rm -r t @osol /ntfs: echo $? 0 @osol /ntfs: ls t t @osol /ntfs: /usr/bin/rm --version /usr/bin/rm: illegal option -- version usage: rm [-fiRr] file ... @osol /ntfs: /usr/bin/rm -r t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example show GNU coreutils rm v6.12 failing to remove a directory tree; even though the exit status is 0, not all files are deleted. This is a bug. @osol /ntfs: /usr/gnu/bin/mkdir -p t/t/t/t/t/t/t/t/t/t//t/t///t//t/t/t/ @osol /ntfs: /usr/bin/rm -rf t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example shows /usr/bin/rm successfully deleting a directory tree. To determine whether this is a bug with GNU rm or interactions between your kernel and the NTFS filesystem, it's necessary to trace the system calls and their return values - hopefully your solaris system has truss installed, in which case you could try to repeat the failing commands given above like so: $ truss -o rm-trace.txt /path/to/rm -r t If you are able to interpret the output of truss, please try to identify where GNU rm and solaris rm differ in their system calls, specifically which files are removed with unlink(2). If not, then please just attach the truss output, ideally compressed. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm opensolaris ntfs-3g problem
On Mon, Aug 11, 2008 at 11:39 AM, Philip Rowlands [EMAIL PROTECTED] wrote: On Sun, 10 Aug 2008, Andras Barna wrote: on opensolaris (update 94) can't remove recursively directories. @osol /ntfs: /usr/gnu/bin/mkdir -p t/t/t/t/t/t/t/t/t/t//t/t///t//t/t/t/ @osol /ntfs: /usr/gnu/bin/rm --version|head -1 rm (GNU coreutils) 6.7 @osol /ntfs: rm -rf t rm: cannot remove directory `t': Directory not empty @osol /ntfs: rm -r t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example shows the default rm (PATH not shown) failing to remove a directory tree, but succeeding on the second attempt. sorry for that that's /usr/gnu/bin/rm (/usr/gnu/bin is the first in PATH on opensolaris) @osol /ntfs: /usr/gnu/bin/mkdir -p t/t/t/t/t/t/t/t/t/t//t/t///t//t/t/t/ @osol /ntfs: /data/a/bin/rm --version|head -1 rm (GNU coreutils) 6.12 @osol /ntfs: /data/a/bin/rm -rf t @osol /ntfs: echo $? 0 @osol /ntfs: ls t t @osol /ntfs: /data/a/bin/rm -r t @osol /ntfs: ls t t @osol /ntfs: /data/a/bin/rm -r t @osol /ntfs: echo $? 0 @osol /ntfs: ls t t @osol /ntfs: /usr/bin/rm --version /usr/bin/rm: illegal option -- version usage: rm [-fiRr] file ... @osol /ntfs: /usr/bin/rm -r t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example show GNU coreutils rm v6.12 failing to remove a directory tree; even though the exit status is 0, not all files are deleted. This is a bug. @osol /ntfs: /usr/gnu/bin/mkdir -p t/t/t/t/t/t/t/t/t/t//t/t///t//t/t/t/ @osol /ntfs: /usr/bin/rm -rf t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example shows /usr/bin/rm successfully deleting a directory tree. To determine whether this is a bug with GNU rm or interactions between your kernel and the NTFS filesystem, it's necessary to trace the system calls and their return values - hopefully your solaris system has truss installed, in which case you could try to repeat the failing commands given above like so: $ truss -o rm-trace.txt /path/to/rm -r t If you are able to interpret the output of truss, please try to identify where GNU rm and solaris rm differ in their system calls, specifically which files are removed with unlink(2). If not, then please just attach the truss output, ideally compressed. attached thanks Cheers, Phil -- Andy http://blog.sartek.net trussrm.tar.gz Description: GNU Zip compressed data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
