I have a bash script with a series of whiptail menus that allows a user to setup their new system, which is Ubuntu server, with no GUI, just CLI (it's going to be a Virtual Machine image).
I'm already forcing a root login by editing /etc/default/grub and /etc/init/tty1.conf, so the user is dropped directly into the root command prompt. From there the user has to type in ./whiptail.sh to start the script and get the whiptail prompts to further setup their host.
Now, I'd like for my script to be what appears up after the the login occurs instead of the user being dropped to the command prompt. How can I do this?
All interactive sessions of bash will read the initialization file ~/.bashrc.
So you can just add the script at the end of the root's .bashrc i.e. /root/.bashrc, assuming the script is executable:
echo '/path/to/whiptail.sh' >>/root/.bashrc
Now the script will be always run when root opens a new interactive shell. If you only want to run while login only, not all all interactive sessions you should rather use ~/.bash_profile/~/.bash_login/~/.profile (the first one available following the order).
If you want it to be global, add you script to
/etc/profile
If you want it to be user-specific, add you script to
/home/$USER/.profile
Consider upvoting the original answer here: https://unix.stackexchange.com/a/56088/343022
Related
I have a lot of configuration for Kwin (the window manager) in another user's home folder (/home/B/.config and other folders).
Is there a way to run Kwin from my session, but make Kwin consider the other user's configuration and environment as well?
I can't copy the files over to my account because they're scattered around B's home folder, and I don't want to risk overwriting stuff.
I tried using sudo, but it doesn't run the command as if it was the B's session, and uses my own config files to run the program instead of those in /home/B/.
If the -H sudo parameter is not enough, maybe you also need something from shell resource files that -i would give you, so something like sudo -i -uusername command.
From sudo's man page:
-i, --login Run the shell specified by the target user's password
database entry as a login shell. This means that
login-specific resource files such as .profile or
.login will be read by the shell. If a command is
specified, it is passed to the shell for execution
via the shell's -c option. If no command is
specified, an interactive shell is executed. sudo
attempts to change to that user's home directory
before running the shell. The command is run with an
environment similar to the one a user would receive
at log in. The Command environment section in the
sudoers(5) manual documents how the -i option affects
the environment in which a command is run when the
sudoers policy is in use.
I couldnt find answer to this althougth there are many similar questions.I wanted to change colour of my linux command prompt based on the remote host i have ssh to.Since bash environment variables are not preserved over ssh,so how could i do this.There are hundreds of server i login everyday.So changing /.bashrc of each remote host is not possible.is there a way i can pullout a script which can be called each time ssh is done.Can someone please give in detail of which file and how it should be edited.gnome,openssh etc are not supprted.
during ssh execution,a new login shell was executed.
during shell login the *rc files are not executed,only *profile was executed.
so place your code in /etc/profile or ~/.bash_profile.
"Since bash environment variables are not preserved over ssh..."
man ssh
Additionally, ssh reads ~/.ssh/environment, and adds lines of the format
“VARNAME=value” to the environment if the file exists and users are
allowed to change their environment. For more information, see the
PermitUserEnvironment option in sshd_config(5).
When beginning to work, I have to run several commands:
source work/tools
cd work/tool
source tool
setup_tool
Off course, doing this a few times a day is really annonying, so I tried to make a bash script tool where I put these commands and put it in /user/bin to run it with command
tool
However, there is a problem. When i run the script and then try to work by typing some of the tool-based commands, it does not work.
I figured out, that it is fine, since if I make a script and then run it, the script seems to run in the same terminal window, but what it really does is, that it behaves as if it created a "hidden window" for its execution and after termination of the script, the "hidden window" terminates too. So I am asking - is there a way to automatize the source command?
I have tried using xterm -hold -e command, but it runs the programmed script in the new window. Obviously, I don't want that. How can I achieve running it in the current window?
Don't put files like that in /usr/bin. As a general rule you don't want to mess with the distribution owned locations like that. You can use /usr/local/bin if you need a system-wide location or you can create a directory in your home directory to hold things like this that are for your own usage (and add that to the $PATH).
What you've noticed is that when run as a script on its own (tool, /path/to/tool, etc.) that the script runs in its own shell session (nothing to do with terminal windows as-such) and you don't want that (as the changes the script makes don't persist to your current shell session).
What you want to do instead is "source"/run the script in your current session. Which you are already doing with that set of commands you listed (source work/tools is doing exactly that).
So instead of running tool or /path/to/tool instead use source /path/to/tool or . /path/to/tool.
As fedorqui correctly points out you don't even need a script for this anywhere as you can just make a shell function for this instead (in your normal shell startup files .bashrc, etc.) and then just run that function when you need to so that setup.
Be careful to use full paths for things when you do this though since you, presumably, want this to work no matter what directory you happen to be in when you run it.
It doesn't create a new hidden window, nor does it create a terminal. What happens is that if you're running a script, normally it runs on a new shell process. The script you're running is supposed to modify the shell environment, but if you're running the script in a new shell process, that shell process's environment is the one that gets modified, instead of your shell environment.
Scripts that needs to modify the current shell environments usually must be run with the source command. What you need to do is to run the script in the current shell. So you should do source /path/to/tool.
If you want to be able to source the script with just tool, put this in your alias file/shell startup (check your distro doc where the file is, but it's usually either .bash_aliases or .bashrc):
alias tool="source /path/to/tool"
I have a host on which I created a script .
The script is being executed whenever the user is logging in via ssh bashrc launches the script.
Now I'm trying to get the script to execute even if the user is not actually logging in , and just running a command .
For example I want the script to be executed if a user is running the following :
ssh user#host.com some_command
Is there a way to achieve the above?
A solution affecting all the users could be using pam-exec and launch a script on the user login event. Check the pam-exec manual page and an example on how to use it pam-exec scripting.
A simple solution for a single user should be add the script in the rc file of the ssh user, add your script to:
~/.ssh/rc
I've done some tests and the rc solution works fine in your case, it gets executed when the user launches a remote command via ssh.
If you don't have a rc file just create it.
you can edit authorized_keys file and add a COMMAND , something like :
command="/home/michale/bin/dothis.sh" ...public key...
for more details read ssh and authorized_keys documentations.
I'm trying to interactively test code before I put it into a script and was wondering if there are any things that behave differently in a script?
When you execute a script it has its own environment variables which are inherited from the parent process (the shell from which you executed the command). Only exported variables will be visible to the child script.
More information:
http://en.wikipedia.org/wiki/Environment_variable
http://www.kingcomputerservices.com/unix_101/understanding_unix_shells_and_environment_variables.htm
By the way, if you want your script to run in the same environment as the shell it is executed in, you can do it with the point command:
. script.sh
This will avoid creating a new process for you shell script.
A script runs in exactly the same way as if you typed the content in at a shell prompt. Even loops and if statements can be typed in at the shell prompt. The shell will keep asking for more until it has a complete statement to execute.
As David rightly pointed out, watch out for environment variables.
Depending on how you intend to launch your script, variables set in .profile and .bashrc may not be available. This is subject to whether the script is launched in interactive mode and whether it was a login shell. See Quick Startup File Reference.
A common problem I see is scripts that work when run from the shell but fail when run from another application (cron, nagios, buildbot, etc.) because $PATH was not set.
To test if a command/script would work in a clean session, you can login using:
ssh -t localhost "/bin/bash --noprofile --norc"
This ensures that we don't inherit any exported variables from the parent shell, and nothing from .profile or .rc.
If it works in a clean session and none of you're commands expect to be in interactive mode, then you're good to go!