$USER vs. $(whoami)
RolandRB
using $(whoami) instead to ensure my scripts work in most shells?
Stephane CHAZELAS
> Is the sys env variable $USER set in every shell? Would I be better off
> using $(whoami) instead to ensure my scripts work in most shells?
I actually don't know of any shell that sets that variable.
zsh sets $USERNAME and $LOGNAME. tcsh sets $user but I think
that's all. Now, login or xdm may set the LOGNAME or USER
variables, but those are modifiables.
So, depending on what you want, the POSIX ways would be:
Login name (as written in utmp, so only in login sessions, while
the shell still has a controlling terminal):
user=$(logname)
Real user name:
user=$(id -urn)
Effective user name:
user=$(id -un)
--
Stephane
Laurenz Albe
> Is the sys env variable $USER set in every shell? Would I be better off
> using $(whoami) instead to ensure my scripts work in most shells?
If you are paranoid about security, maybe "whoami" is better.
I think that `whoami` is supported on more shells than $(whoami).
If you are really paranoid, consider that somebody might put a fake
"whoami" somewhere in the path and better refer to the command by
absolute path :^)
Yours,
Laurenz Albe
Stephane CHAZELAS
And then, he may use LD_LIBRARY_PATH or LD_PRELOAD (or BASH_ENV
or ~/.zshenv). But he may as well edit and modify a copy of the
script, it's a bit pointless to restrict the usage of a script
(except if the script is setuid, but then you're already in big
trouble if you write setuid shell scripts).
--
Stephane
Stephane CHAZELAS
> 2005-01-16, 23:37(-08), RolandRB:
>> Is the sys env variable $USER set in every shell? Would I be better off
>> using $(whoami) instead to ensure my scripts work in most shells?
>
> I actually don't know of any shell that sets that variable.
>
> zsh sets $USERNAME and $LOGNAME. tcsh sets $user but I think
> that's all. Now, login or xdm may set the LOGNAME or USER
> variables, but those are modifiables.
Actually there are more applications setting $LOGNAME (at
least on debian) than $USER:
$USER $LOGNAME
xdm y y
gdm y y
login y y
in.telnetd (ssl) y y
cron n y
sshd n y # note login is called
# for interactive sessions
lshd y y
in.rshd (redone) y n
in.rlogind (redone) n n # but login then does
xterm n y
zsh n y
bash n n
pdksh n n
ksh93 n n
tcsh n n
csh n n
rc n n
es n n
--
Stephane
Michael Tosch
On Solaris and RH-Linux, I find that sh, bash, csh, tcsh do set $USER...
so almost all shells have $USER.
--
Michael Tosch @ hp : com
Stephane CHAZELAS
[...]
> On Solaris and RH-Linux, I find that sh, bash, csh, tcsh do set $USER...
> so almost all shells have $USER.
What test did you make that shows that?
$ env -i /bin/bash -c 'echo "$USER $LOGNAME"'
$
I'd bet $USER was already in the environment when you started
bash. (set by login when you logged in for instance).
--
Stephane
Michael Tosch
You are right, I had tested /bin/sh and /bin/bash via 'rsh host echo $USER' but
USER seems to be set from rshd.
But csh and tcsh really set $USER.
Stephane CHAZELAS
[...]
>> I'd bet $USER was already in the environment when you started
>> bash. (set by login when you logged in for instance).
>>
>
> You are right, I had tested /bin/sh and /bin/bash via 'rsh host echo $USER' but
> USER seems to be set from rshd.
$USER is expanded by the local shell, there, not the one
launched by rshd on the remote host.
>
> But csh and tcsh really set $USER.
[...]
You're half right, my affirmation was based on a test that is
only relevant on Bourne-like shells (and that I initially did to
find out which variables csh would provide with the user name):
env -u LOGNAME -u USER csh -c 'set | grep -a chazelas'
If tcsh sets $USER and $LOGNAME, csh (at least the one shipped
with debian) does not (I'd bet your csh is tcsh).
$ env -u LOGNAME -u USER tcsh -c 'env | grep -a chazelas'
[...]
LOGNAME=chazelas
USER=chazelas
GROUP=chazelas
$ env -u LOGNAME -u USER csh -c 'env | grep -a chazelas'
PWD=/home/chazelas
$
--
Stéphane
Chris Thompson
The csh(1) shipped with Solaris (9, if it's relevant) does set $USER,
but not $LOGNAME:
$ uname -srv
SunOS 5.9 Generic_117171-15
$ env -i csh -c 'env'
PWD=/home/cet1
USER=cet1
$ env -i tcsh -c 'env'
HOSTTYPE=sun4
VENDOR=sun
OSTYPE=solaris
MACHTYPE=sparc
SHLVL=1
PWD=/home/cet1
LOGNAME=cet1
USER=cet1
GROUP=cet1
HOST=*suppressed*.cam.ac.uk
and the Bourne-type shells (sh, ksh, bash) indeed set neither.
Chris Thompson
Email: cet1 [at] cam.ac.uk
Stephane CHAZELAS
[...]
> The csh(1) shipped with Solaris (9, if it's relevant) does set $USER,
> but not $LOGNAME:
>
> $ uname -srv
> SunOS 5.9 Generic_117171-15
>
> $ env -i csh -c 'env'
> PWD=/home/cet1
> USER=cet1
Are you sure it's not set in your ~/.cshrc (remember that even
non-interactive csh read ~/.cshrc unless you pass it the "-f"
option).
--
Stéphane
Bill Seivert
If a person su's to a different userid, they probably wouldn't take the
time to change
any environment variables. I could set an environment variable to
anything I wanted
if I thought it might get me more privileges (e.g., setenv USER root).
Bill Seivert
sei...@pcisys.net
RolandRB
Bill Seivert wrote:
> I would always use whoami or id in preference to an environment
variable.
>
> If a person su's to a different userid, they probably wouldn't take
the
> time to change
> any environment variables. I could set an environment variable to
> anything I wanted
> if I thought it might get me more privileges (e.g., setenv USER
root).
>
> Bill Seivert
> sei...@pcisys.net
In my final solution I opted to call whoami from /usr/ucb/whoami just
in case somebody had put a different whoami on the path.
Stephane CHAZELAS
[...]
> In my final solution I opted to call whoami from /usr/ucb/whoami just
> in case somebody had put a different whoami on the path.
And what prevents a user to make a copy of your script and
change that path or anything else?
--
Stéphane
Chris Thompson
Yup: no .cshrc in my home directory on that system (I don't usually use csh!).
But I repeated the experiment with -f just in case ... same results.
It seems Solaris /bin/csh only sets $USER if it's not already set:
$ env -i USER=foobar PWD=/ csh -f -c 'env'
USER=foobar
PWD=/home/cet1
eid...@gmail.com
Wayne
issue. For Fedora (for example), the settings for these are
found in /etc/profile (used by bash and ksh93 at least):
USER="`id -un`"
LOGNAME=$USER
Note that SUS/POSIX only requires LOGNAME to be set
(<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03>)
in the shell.
whoami is not a standard utility; use $(id -un) or
$(id -run) instead if you need a portable way to check
the user name, that can't be easily faked.
--
Wayne
Stephane Chazelas
> > 2005-01-17, 09:18(+00), Stephane CHAZELAS:
> > > that's all. Now, login or xdm may set the LOGNAME or USER
> > > variables, but those are modifiables.
[...]
[...]
> Bash actually does set $USER. This may be a more recent development.
impression from?
A recent development since that article from 2005 though is the
fish shell that seems to set $USER (and not $LOGNAME).
--
Stephane
Thomas 'PointedEars' Lahn
> 2015-11-13 14:02:36 -0800, eid...@gmail.com:
>> On Monday, January 17, 2005 at 8:45:51 AM UTC-5, Stephane CHAZELAS wrote:
>> > 2005-01-17, 09:18(+00), Stephane CHAZELAS:
> [...]
>> > > zsh sets $USERNAME and $LOGNAME. tcsh sets $user but I think
>> > > that's all. Now, login or xdm may set the LOGNAME or USER
>> > > variables, but those are modifiables.
> [...]
>> > bash n n
> [...]
>
>> Bash actually does set $USER. This may be a more recent development.
>
> AFAICT, bash still doesn't set $USER. Where do you get that
> impression from?
-/bin/bash
$ bash --version
GNU bash, version 4.3.42(1)-release (x86_64-pc-linux-gnu)
[…]
$ echo $USER
me
$ grep -I USER= ~/.bash* ~/.profile /etc/bash* /etc/profile 2>/dev/null
[empty]
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
David W. Hodgins
> Stephane Chazelas wrote:
>> AFAICT, bash still doesn't set $USER. Where do you get that
>> impression from?
> me
> $ grep -I USER= ~/.bash* ~/.profile /etc/bash* /etc/profile 2>/dev/null
> [empty]
$ grep USER= /etc/profile
USER=`id -un`
Which distribution is in use?
Regards, Dave Hodgins
--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.
Thomas 'PointedEars' Lahn
> […] Thomas 'PointedEars' Lahn […] wrote:
>> Stephane Chazelas wrote:
>>> AFAICT, bash still doesn't set $USER. Where do you get that
>>> impression from?
>>
>> $ echo $USER
>> me
>> $ grep -I USER= ~/.bash* ~/.profile /etc/bash* /etc/profile 2>/dev/null
>> [empty]
>
> In my Mageia 5 system ...
> $ grep USER= /etc/profile
> USER=`id -un`
>
> Which distribution is in use?
Description: Debian GNU/Linux unstable (sid)
Stephane Chazelas
[...]
> -/bin/bash
>
> $ bash --version
> GNU bash, version 4.3.42(1)-release (x86_64-pc-linux-gnu)
> […]
>
> $ echo $USER
> me
>
> $ grep -I USER= ~/.bash* ~/.profile /etc/bash* /etc/profile
2>/dev/null
> [empty]
And?
Does:
env -u USER bash --norc -c 'echo "$USER"'
shows "me"?
--
Stephane
Jim Diamond
> Stephane Chazelas wrote:
>
>> 2015-11-13 14:02:36 -0800, eid...@gmail.com:
>>> On Monday, January 17, 2005 at 8:45:51 AM UTC-5, Stephane CHAZELAS wrote:
>>> > 2005-01-17, 09:18(+00), Stephane CHAZELAS:
>> [...]
>>> > > zsh sets $USERNAME and $LOGNAME. tcsh sets $user but I think
>>> > > that's all. Now, login or xdm may set the LOGNAME or USER
>>> > > variables, but those are modifiables.
>> [...]
>>> > bash n n
>> [...]
>>
>>> Bash actually does set $USER. This may be a more recent development.
>>
>> AFAICT, bash still doesn't set $USER. Where do you get that
>> impression from?
>
> $ echo $0
> -/bin/bash
>
> $ bash --version
> GNU bash, version 4.3.42(1)-release (x86_64-pc-linux-gnu)
> […]
>
> $ echo $USER
> me
>
> $ grep -I USER= ~/.bash* ~/.profile /etc/bash* /etc/profile 2>/dev/null
> [empty]
system (Slackware64 14.1) a "ps uaxwe" reveals that the shell running
/etc/X11/xinit/xinitrc has the environment variable USER.
So if you are running under X, your interactive shell may well have
inherited USER, not set it.
Jim
Thomas 'PointedEars' Lahn
> […] Thomas 'PointedEars' Lahn […] wrote:
>> Stephane Chazelas wrote:
>>> impression from?
>>
>> $ echo $0
>> -/bin/bash
>>
>> $ bash --version
>> GNU bash, version 4.3.42(1)-release (x86_64-pc-linux-gnu)
>> […]
>>
>> $ echo $USER
>> me
>>
>> $ grep -I USER= ~/.bash* ~/.profile /etc/bash* /etc/profile 2>/dev/null
>> [empty]
>
> So perhaps your shell inherited USER from whatever started it.
>
> On my
> system (Slackware64 14.1) a "ps uaxwe" reveals that the shell running
> /etc/X11/xinit/xinitrc has the environment variable USER.
>
> So if you are running under X, your interactive shell may well have
> inherited USER, not set it.
$ ps uwwep $$
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
$me 8502 0.1 0.1 25172 7136 tty2 S 13:35 0:00 -bash
TERM=linux HOME=/home/$me SHELL=/bin/bash USER=$me LOGNAME=$me
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
LANG=de_CH.UTF-8 LC_MESSAGES=en_US.UTF-8 MAIL=/var/mail/$me
XDG_SESSION_COOKIE=$blubb HUSHLOGIN=FALSE
$ ps -fwwp 8502
UID PID PPID C STIME TTY TIME CMD
$me 8502 4481 0 13:35 tty2 00:00:00 -bash
$ ps uwwep 4481
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 4481 0.0 0.0 75956 3212 tty2 Ss Nov23 0:00 /bin/login
--
$ file /bin/login
/bin/login: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=30b3bdc8fc0648bc10be276902de97455d91e6fd, stripped
However, it is questionable if this confirms the original assertion that
bash would “still not set $USER”. Because “ps e” means:
| e Show the environment after the command.
| […]
| procps-ng July 2014 PS(1)
AIUI it does not mean that the shell was invoked with that environment in
place, so the shell still could have created that environment. It could not
have done that by sourcing the named script files, since none of those
contains a USER environment assignment.
There are three remaining possibilities:
1. /bin/login invokes the shell with the corresponding environment
(“-f” does not show that).
2. The shell creates the corresponding environment, and sets $USER.
3. At least one pertinent script file that is sourced by the shell
and sets $USER has been overlooked.
Wayne
> Jim Diamond wrote:
> ...
>
> 1. /bin/login invokes the shell with the corresponding environment
> (“-f” does not show that).
>
> 2. The shell creates the corresponding environment, and sets $USER.
>
> 3. At least one pertinent script file that is sourced by the shell
> and sets $USER has been overlooked.
>
On some systems, /etc/profile sources a bunch of files in /etc/profile.d/.
I would think you could try something like this to identify which file:
# find /etc ~me -type f -exec grep -l 'USER=' '{}' +
Or maybe:
# find /etc ~me -type f -exec grep -l 'export.*USER' '{}' +
--
Wayne