How to obtain a consolidated system wide history irrespective of users or powers?

Question

If I am a normal user and I type

history

I get a set of commands typed by me in the terminal.

Now I make myself the sudo su (su stands for super-user here and not substitute user)

sudo su

I am typing again the history from the same terminal

history

I get a different set of commands which I had typed early.

I am working in a personal workstation.No one else handles the workstation. There are no users enrolled in the workstation other than me. Even if I obtain su (super-user) privileges, i am going to be using with those privileges also.

Hence I would like to obtain a consolidated system-wide same history irrespective of superuser or normal user.

How to achieve this?

type whoami as your user, and then compare after you sudo su ... (I think of sudo as super-user-do, however su can also mean switch-user~) — guiverc, May 12 '20 at 03:53
Though I understand your need, I would seriously reconsider merging user and root into one. For one-off commands use sudo, and should you ever need to work as root for a while, do so in a separate terminal reserved just for this, with some obvious indication that it is root, like a red background etc. (The # or $ prompt is not enough). This sort of modal hygiene will help stop the odd major disaster when you forget you are root. — meuh, May 12 '20 at 06:44
@meuh thanks for the warning. I am trying only to merge the history of sudo and user. I am not trying to merge the powers. Is merging history equivalent to merging powers? — Praveen Kumar-M, May 12 '20 at 06:54
No, but I find that there is little in common between what I type as root (installing software, mounting files, chown, admin etc), and what I type as a user. I do perhaps the opposite of you, and keep a separate history not just for root, but for every separate terminal. This allows me to change context easily, without a mix of disparate commands I have to search back through to find what I was doing 2 days ago. I also try to collect a group of commands I just did into a very basic incomplete shell script, so that it becomes my history. It helps avoids typing errors. — meuh, May 12 '20 at 07:05
@meuh Figured out about the manual history. From this link. [https://askubuntu.com/questions/209445/manually-edit-terminal-command-history] Thanks for the useful suggestion. — Praveen Kumar-M, May 12 '20 at 09:23

score 1 · Answer 1 · answered May 12 '20 at 04:12

history is handled by your $SHELL, through the $HISTFILE and $HISTFILESIZE environment variables. Read man $SHELL.

Both sudo and su control the environment of the executed commands. read man su;for i in sudo sudo.conf sudo_root sudoers ; do man $i; done

You can take control of your shell history, see my answer to Bash history handling with multiple terminals .

If you avoid sudo su, and just use sudo , your root commands will also be logged. You'll have to retype your login password if more than 5 minutes (by default) elapses between sudo commands. This is the more modern approach to system administration, IMHO.

you dont need to loop the manpages just put them as arguments — , May 12 '20 at 04:34

score 0 · Answer 2 · answered May 12 '20 at 05:52

The majority of POSIX-compatible shells use the value of the environment variable $HISTFILE to determine from where to direct read/write activities regarding command history. As I consider it, I see multiple options for accomplishing the unified shell history that you desire. The four most straightforward of them are:

Alter the shell configuration for the root user only

Add a definition for the HISTFILE variable to the root user's shell startup files (.bashrc for BaSH, .zshrc for Z Shell, .tcshrc for TENEX C Shell, etc.; found at the end of the command below)

systemctl --user show-environment | grep HISTFILE | sudo tee -a /root/.bashrc

Alter the global (system-wide, affects all users) configuration

Change the behavior of only a single shell (e.g. bash but not tcsh)

Add a definition for HISTFILE to the global/system configuration file for your shell of choice (/etc/bash.bashrc for BaSH, /etc/zsh/zshrc for Z Shell, etc.) which will affect all users on the system, provided they don't explicitly set a value for HISTFILE in their user shell files. If you choose this method and results are no forthcoming, you probably need to delete the line with HISTFILE in it from /root/.{bash,zsh,tcsh}rc.

systemctl --user show-environment | grep HISTFILE | sudo tee -a /etc/bash.bashrc

Change the behavior of sudo so that all shells are affected (bash, zsh, ksh, etc.)

The sudo command unsets all but a handful of environment variables to maximize consistency in the behavior of the commands it subsequently executes. You can use the configuration key "env_keep" in the /etc/sudoers file to instruct it to add HISTFILE to the list of those variables it retains. This has the effect of giving access to this unified shell history not just to the root user, but any user you "sudo into" using sudo -u <someone_else>.

sudo sed --in-place '/^Defaults\s+env_keep=/s/"$/ HISTFILE"/' /etc/sudoers

Change your system's default environment variables

By defining the HISTFILE variable in /etc/environment, you can have a unified shell history more often than when you use sudo or su. For instance, this method will also apply to TTYs such as those encountered with the Ctrl+Alt+F2...F6 global shortcuts or the one you are taken to by selecting GRUB's recovery mode option.

systemctl --user show-environment | grep HISTFILE | sudo tee -a /etc/environment

Access your user shell history only when desired

An extemporaneous solution to the problem, should you prefer to activate this behavior only on a case-by-case basis rather than permanently altering any configuration is to preface those particular sudo invocations with HISTFILE=$HISTFILE.

HISTFILE=$(printenv HISTFILE) sudo su

Note: The above examples assume the presence of systemd on your installation. In its absence it is almost always possible to substitute printenv or env for systemctl --user show-environment. The systemctl method was chosen for demonstration purposes, to minimize the possibility of propagating a non-default value for HISTFILE from the shell instance currently in use.