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
Related
I've just created a script, let's say, "helloworld.sh".
The script doesn't yet have execution permissons: -rw-rw-r--
If I try to execute that script with: "./helloword.sh", I'll get an error message, as expected. But, if I try to execute that same script as: . helloword, it will execute with no problems.
How? Why does that happen?
This happens because on Linux the "." (dot) alone is a built-in command that execute the script within your current session with your current shell. This is the same as calling the script with source command (the BSD default method). It's almost the same than execute with bash helloworld.sh.
When you call the script with ./helloworld.sh or /root/helloworld.sh the shell will try to figure out how to execute it, if the file is a binary, it will simply run, if it is a script, the shell will read the first line looking for the interpreter. To do this, you'll need execution permission.
To simplify:
One is a command;
The other one is a path.
You can even run:
. --help
About . against bash:
This is why we use . or source to load variables from a file in our session, for example, when we change ~/.bashrc and reload it without login again.
You can see this happens when you execute:
. /etc/os-release
All variables defined inside this file will be loaded and available in your current shell session.
The same will not happen if you execute:
bash /etc/os-release
Because you opened a "new session" inside that bash that you called, the new bash executes and close, cleaning the session.
The same process happen if you give execute permission +x to the script, because when you call the script with ./ or something like that, a new session will be created too.
I need to run a Make script that invokes a shell script.
I can run the shell script directly as root but when running make on the makefile (still as root) make is denied permission to run the same shell script?
The offending line in the Makefile is that one:
PLATFORM=$(shell $(ROOT)/systype.sh)
I could go in and hardcode the value of every PLATFORM variable of every Makefile scrip on the system but that would be pointless fix, I'd like to understand why there is that Permission Denied error:
make[1]: execvp: ../systype.sh: Permission denied
PS: The content of the shell script is not the issue even if the shell script only contain ls or echo linux the Permission is Denied to the Make utility to run the shell script.
PS: I am not a make expert by an mean so if the explanation is related to Make please be as specific as you can.
In your comments above you say when you "run it manually" you use . scriptname.sh, is that correct? You use . followed by scriptname.sh?
That does not run the script, that sources the script. Your statement that scriptname.sh will execute with and without the x permission since it is a shell script is wrong. You can source the script if you have read permissions. But you cannot execute the script unless you have execute permissions.
"Sourcing" means that a new shell is not started: instead your current shell (where you type that command) reads the contents of the script and runs them just as if you'd typed them in by hand, in the current shell. At the end all the side-effects (directory changes, variable assignments, etc.) that were performed in that script are still available in your current script.
"Executing" means that the script is treated like a program, but the program is a new shell that's started, which then reads the contents of the script and executes it. Once the script ends the shell exits and all side-effects are lost.
The $(shell ...) function in make will not source your script (unless you also use . there, which you did not). It will try to run your script. The error you show implies that either systype.sh did not have the execution bit set, or else that it had an invalid #! line. There's no other explanation I can think of.
If sourcing the file really does what you want then why not just use the same method in $(shell ...) that you use in your own personal use:
PLATFORM=$(shell . $(ROOT)/systype.sh)
If changing the user permission didn't work, are you sure that whatever user owns the script is the same user you're using to invoke make? You say you're "running as root"; is the script owned by root? Or is it owned by you and you're running sudo make or similar?
I don't know why you don't just use:
chmod +x systype.sh
and call it a day.
Adding execution permission to the file Group rather that the file User fixed the issue.
PS: I wonder why? It seems the Make utility run shell scripts not with the same user that started Make...
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?
I would like to create (and execute) a shell script in my home directory (/home/user).
Have tried the following:
printf "cd /mypath\n" > myShortcut.sh
chmod +x myShortcut.sh
sh myShortcut.sh
where am I going wrong?
(am trying to set up a shortcut to navigate to a different directory)
What is exactly wrong here? That you are still in /home/user after the script executes? Well thats because executing the script creates a child shell that returns to the parent shell once the script ends. Therefore your cd has NO EFFECT in your current shell.
If you want to execute the script in the current shell (as opposed to in a subshell), use the source (or .) command:
source myShortcut.sh
This should then change the directory as expected.
In addition, sourcing also allows you to set and change environment variables in the current shell--a very frequent question in its own right :-)
That won't work because of what the other answer says. The script operates in a child shell.
For a shortcut like that, you could set up an alias, edit the .bashrc file in your home directory and add a line like
alias shortcut='cd /mypath'
Substitute "shortcut" for whatever you want to name it, and mypath to the path you want.
Restart the shell (close terminal and reopen or w/e) and that should work just as you want.
Then you can use "shortcut" anywhere you want in the shell.
I've seen shell scripts that include a line such as:
source someOtherFile
I know that causes the content of someOtherFile to execute, but what is the significance of source?
Follow-up questions: Can ANY script be sourced, or only certain type of scripts? Are there any side-effects other than environment variables when a script is sourced (as opposed to normally executing it)?
Running the command source on a script executes the script within the context of the current process. This means that environment variables set by the script remain available after it's finished running. This is in contrast to running a script normally, in which case environment variables set within the newly-spawned process will be lost once the script exits.
You can source any runnable shell script. The end effect will be the same as if you had typed the commands in the script into your terminal. For example, if the script changes directories, when it finishes running, your current working directory will have changed.
If you tell the shell, e.g. bash, to read a file and execute the commands in the file, it's called sourcing. The main point is, the current process (shell) does this, not a new child process.
In BASH you can use the source command or simply . to source a file.
source is a Unix command that evaluates the file following the command, as a list of commands, executed in the current context. You can also use . for sourcing the file.
source my-script.sh;
. my-script.sh;
Both commands will have the same effect.
In contrast, passing the script filename to the desired shell will run the script in a subshell, not the current context.