To get the script to run in terminal, I have to select the option to open in terminal and write sh script name.shIs there a way I can reduce that to a single step, i.e. a launcher that automatically opens the script in a terminal after logging as a root ? I've tried to look it up on Google, but I haven't found any useful advice (perhaps I'm not executing the search properly).
I think what you mean is running your script as start up script. In that case place the script you want to run in the /etc/init.d directory and make the script executable with command chmod 755 scriptname.sh.
See the below related threads for more information
https://askubuntu.com/questions/290099/how-to-run-a-script-during-boot-as-root
How to run a shell script at startup
EDIT:
if you want to run your script after your login is successful then you need to place your script in ~/.bash_profile. See this related post
How do you run a script on login in *nix?
Related
I have modified my rc.local script to run some python script at startup.
This python script seems to be started successfully.
As the script is running forever (intended) and I want to see what the script does, my question is:
Is there a way to access the shell that runs this script?
Yes, to see what is going on, I could log to some file, but what if that script needs to get input from the user via console?
Thanks for your help!
You will not be able to interact with the script run by rc.local. But you can see what it does by logging its output into dedicated files:
python myscript.py > /home/myhome/log/myscript.log 2> /home/myhome/log/myscript.err
where error messages go into a separate log file.
Note that your script will be executed by root, having permissions and ownership accordingly.
Here's a link to an earlier answer about this with a method to log all outputs of rc.local.
Now you can see in your log file, if the execution stops due to the script demanding input or indeed crashing, and then you can fix the script accordingly.
If you don't want to mess with rc.local for testing, you could also first run it through crontab on your or root's account (scheduled execution by user, see man crontab). This might be easier for debugging, and you can start it through rc.local once it works as you want.
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 want to execute some commands through terminal. I have on script for executing commands.Some commands are working but when trying to change directory its not changing. There is no error while executing that script.The script which i made is executable and is mention below:
make clean
make
cd /home/user
save this as script.sh and make it executable
Current working directory is a process property. Each process has independent value for its working directory. Your script works correctly: it changes the current working directory of the shell process that executes it.
If you want your interactive shell to change working directory you have to instruct it. You can do it by "sourcing" your script into your interactive shell. "Sourcing" means reading the script and executing the commands by the shell that sources it. This is opposed to "executing" the script, where a separate shell process is started and executes the script contents.
You can source a script using source or . commands. Like this:
source script.sh
or this:
. script.sh
I have to work on a project in Fedora Linux and I have to type the following very often:
player map1.cfg &
I figured out that I can create an executable .sh file and it contains this:
#!/bin/bash
player *.cfg &
However, when double click on the runmap.sh file it shows me 'Run in Terminal', 'Display', 'Cancel', and 'Run' and when I click 'Run in Terminal' a terminal window opens and closes immediately. If I just hit 'Run' then the .cfg opens but I need the Terminal window to run additional (Java) files.
How can I fix this problem?
Other information:
I use *.cfg because I want to copy and paste the .sh files into other folders that also contain .cfg files such as map2.cfg, map3.cfg, etc.
It's for a Player/Stage project.
When you run a script from the file manager, the shell that is started isn't interactive. The shell can only read the script file.
To open an interactive shell in addition to the files, you can exec the new shell at the end of the script, and use "Run in Terminal":
#!/bin/bash
player *.cfg &
exec /bin/bash
Well let's look at it this way.
When you run the command in a terminal, the command starts as a child process and is then sent to the background. Once the command finishes it terminates. During the time it is running in the background you can still issue commands because your parent process is the terminal window itself.
When you write a script that issues a command to run in the background it is started, spawns the command as a child to it and then closes because the script has finished.
These are a behavior of the OS and something that really shouldn't change. Essentially what you are therefore asking for is a way for it to run the command quickly for yourself yet still leave a command terminal for you to work with?
1) Why is typing the command such a hassle? Bash and other terminals have a history function for this very reason.
2) Why don't you just call the mini script you wrote from a terminal window whenever you need to call the commands. If you put the script in a folder on your $PATH variable it will be available to you in the terminal at any location.
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!