Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to use Bash scripts to identify users in linux. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

First of all, let's talk about the following experience: from the performance point of view, the permission execution of the command line can be divided into the following five situations:

Admin-manual: ordinary users type commands by hand

Sudo-manual: hand command plus sudo

Admin-bash: execute bash scripts as normal users

Sudo-bash: execute bash scripts with sudo

Root-any: log in as root user

Many variables, environmental variables in these 4 cases, there will often be confusion! (chaos refers to ourselves, not computers)

Besides, tell me a little trick.

We all know that the ~ variable points to the current user directory. In fact, the variable in ~ abc format can point to the specified user's user directory, for example, ~ pi points to / home/pi, or ~ ubuntu points to / home/ubuntu.

Sort out your thoughts:

There is no problem with the normal execution of scripts such as. / test.sh, even if there is a sudo such as sudo apt-get update in the script.

In other words, serious problems will occur only when sudo is executed on the entire script, such as sudo. / test.sh!

So suppose my real user is pi and the HOME directory is in / home/pi, and now I'm going to find the right solution in the way sudo. / test.sh is executed.

The following are the various statements and variables in the script and the results displayed:

# (not recommended! ) $whoami > root# differs from whoami in that it can indicate which users are currently logged on to the computer, including local login and ssh login owner $whoami > some machines show empty > Mac shows: pi ttys001 Nov 26 16 whoami 5 is the same as whoami (not recommended! ) $echo $USER > root# user home directory location (unreliable and not recommended! ) echo $HOME > / root$ user home directory location, which is equivalent to $HOME (not recommended! ) $echo ~ > / root# directly uses the environment variable LOGNAME$ echo $LOGNAME > root# explicitly calls the environment variable LOGNAME$ printenv LOGNAME > root# SUDO_USER is the environment variable in root's ENV, # at the same time, the env of ordinary users is not available, and only root users can display $sudo echo $SUDO_USER > pi# to show the calling environment variable SUDO_USER (not recommended! ) # as you can see from the results, even if the script is executed as sudo, whether or not sudo is added to the script will be different! $printenv SUDO_USER > > pi$ sudo printenv SUDO_USER > root

As you can see from the above tests, if we are executing bash scripts with sudo, many variables are "unreliable".

In Stackoverflow, the tendency to be consistent is to use the environment variable $SUDO_USER. And in the test, it is indeed the most "stable", that is, it can be consistent under different permissions and OS systems (only systems with sudo).

So now that we have a user name, we can get the home directory / home/pi with a command like ~ pi, but!

At this time, the problem arises again: when we knock by hand, we can get the correct address of ~ pi, but the script does not recognize what ~ pi is. At best, it is a string and cannot be like a variable.

Well, since this is the case, we cannot use the abc method. Instead, we will use an old-fashioned but absolutely unconfusing method:

Look directly from / etc/passwd.

Manually, you can directly open passwd for viewing. It is troublesome in the script. The most convenient thing is to use the system command getent, that is, the Get Entries command, to obtain the information of the specified user:

$getent passwd pi > > pi:x:1000:1000:,:/home/pi:/bin/bash

So, the rest of the / home/pi has been taken out, and we can easily take it out with cut.

So the whole process is as follows:

Me=$SUDO_USERmyhome= `getent passwd $me | cut-d:-f 6`

Get / home/pi smoothly!

Further, what if the script doesn't run in sudo? At this time, there is no SUDO_USER variable under the environment variables of root users and ordinary users. Then you need to add one more step of judgment:

Me=$ {SUDO_USER:-$LOGNAME} myhome= `getent passwd $me | cut-d:-f 6`

That is, if SUDO_USER is empty, $LOGNAME is normally used to get the current user. Why not use $USER but use $LOGNAME? Because USER is not available on every system, but LOGNAME is available on * nix systems.

Update

Since some OS cannot get LOGNAME correctly, uid is used to obtain the user path:

HOUSE= `getent passwd ${SUDO_UID:-$ (id-u)} | cut-d:-f 6`

Update again

MacOS does not have / etc/passwd, nor does it support getent passwd to obtain user information, but the contents of the $USER and $HOME variables can be kept unchanged under sudo.

So change to the following:

HOUSE=$ {$(`getent passwd ${SUDO_UID:-$ (id-u)} | cut-d:-f 6`):-$HOME}

That is, if the content cannot be obtained by getent, the value of $HOME will be taken directly.

And then update.

Because bash does not support the above nested ternary expression, you need to take it apart:

HOUSE= "`cat / etc/passwd | grep ${SUDO_UID:-$ (id-u)} | cut-d:-f 6`" HOUSE=$ {HOUSE:-$HOME}

And then update again.

If it is root, grep uid will match all lines with zeros in passwd, so improve to the following:

HOUSE= "`cat / etc/passwd | grep ^ ${SUDO_USER:-$ (id-un)}: | cut-d:-f 6`" HOUSE=$ {HOUSE:-$HOME} so much about how to use Bash script to identify users in linux. I hope the above content can be helpful to you and learn more. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.