I need to change the directory inside the shellscript.i have tried below
#!/bin/bash
sudo -u rv bash
cd /opt/test
source /opt/rv/van.env
./rv.sh |grep "STATUS"
When I tried it didn't cd to that path and not executed th rv.sh.guide me with some ideas.
Fyi rv.sh path /opt/test/
The following line:
sudo -u rv bash
Will launch a bash console as the user rv and then your entire script will halt until the program (i.e.: bash) ends.
Only after bash ends, the program will continue execution and run the last two lines.
The last two lines are running as part of the first script, therefor, they run as your user.
It seems like you're expecting sudo to execute the rest of the script in the users context but it is not interactive. It will invoke a separate bash instance and, once exited, resume the rest of the script afterwards.
You'll have to put together a separate script and run that with sudo. Running sudo inside of scripts is rarely a good idea.
S.a. https://askubuntu.com/questions/425754/how-do-i-run-a-sudo-command-inside-a-script
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 have this shell command asebamedulla "ser:device=/dev/ttyACM0", I want it to be run directly after restarting Linux.
I read some solutions ( shell_command & , or run in in background as a daemon process...) but I didn't know how to use them.
My question is :
how to run a shell command automatically and directly after startup?
Solution 1:
>>sudo crontab -e
#In the first line of this file enter this:
#reboot <your command whatever>
#Save and Exit
Solution 2:
Make a script name it "whatever.sh".
Put the file in your /etc/init.d/ directory.
Change the permission of your file by.
chmod +x /etc/init.d/whatever.sh
I'm on ubuntu 17.04, and I'm trying to execute some commands in sequence, so I have written this shell script:
#!
sudo java -jar ~/Desktop/PlugtestServer.jar
sudo /opt/lampp/lampp start
sudo node httpServer.js
The problem is that after the first command, it execute PlugtestServer and then stop on it, because it is a server and continue to execute it. There is a command in order to automatically open a new terminal and execute PlutestServer in it?
There is way to open a new terminal window and execute command in it using gnome-terminal
The sample format for command is:
gnome-terminal -e "command you want to execute"
gnome-terminal -e "./your-script.sh arg1 arg2"
Hope that helps!!
Your script stays on the first command showing output, you can make the shell move on by adding "&" to the end of your lines. However this might still not do what you want, if you want PlugTestServer to remain running when you log out. For that you should include "nohup" which will keep the command running while piping output to a file.
So, an example:
#!/bin/sh
nohup java -jar ~/Desktop/PlugtestServer.jar > plugtest.out & #Pipes output to plugtest.out, use /dev/null if you don't care about output.
/opt/lampp/lampp start
node httpServer.js
Notice I removed sudo from the script. It's generally better to invoke the script with "sudo" unless you have specific reason to, at the very least it simplifies the commands.
I'm not sure if your second and third command "fork" or "block", so add "nohup" and "&" if you need to.
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...
I have a simple script cmakeclean to clean cmake temp files:
#!/bin/bash -f
rm CMakeCache.txt
rm *.cmake
which I call like
$ cmakeclean
And it does remove CMakeCache.txt, but it doesn't remove cmake_install.cmake:
rm: *.cmake: No such file or directory
When I run it like:
$ . cmakeclean
it does remove both.
What is the difference and can I make this script work like an usual linux command (without . in front)?
P.S.
I am sure the both times is same script is executed. To check this I added echo meme in the script and rerun it in both ways.
Remove the -f from your #!/bin/bash -f line.
-f prevents pathname expansion, which means that *.cmake will not match anything. When you run your script as a script, it interprets the shebang line, and in effect runs /bin/bash -f scriptname. When you run it as . scriptname, the shebang is just seen as a comment line and ignored, so the fact that you do not have -f set in your current environment allows it to work as expected.
. script is short for source script which means the current shell executes the commands in the script. If there's an exit in there, the current shell will exit (and e. g. the terminal window will close).
This is typically used to modify the environment of the current shell (set variables etc.).
script asks the shell to fork itself, then exec the given script in the child process, and then wait in the father for the termination of the child. If there's an exit in the script, this will be executed by the child shell and thus only terminate this. The father shell stays intact and unaltered by this call.
This is typically used to start other programs from the current shell.
Is this about ClearCase? What did you do in your poor life where you've been assigned to work in the deepest bowels of hell?
For years, I was a senior ClearCase Administer. I haven't touched it in over a decade. My life is way better now. The sky is bluer, bird songs are more melodious, and my dread over coming to work every day is now a bit less.
Getting back to your issue: It's hard to say exactly what's going on. ClearCase does some wacky things. In a dynamic view, the ClearCase repository on Unix systems is hidden in the shell's environment. Now you see it, now you don't.
When you run a shell script, it starts up a new environment. If a particular shell variable is not imported, it is invisible that shell script. When you merely run cmakeclean from the command line, you are spawning a new shell -- one that does not contain your ClearCase environment.
When you run a shell script with a dot prefix like . cmakeclean, you are running that shell script in the current shell which contains your ClearCase environment. Thus, it can see your ClearCase view.
If you're using a snapshot view, it is possible that you have a $HOME/.bashrc that's changing directories on you. When a new shell environment runs in BASH (the default shell in MacOS X and Linux), it first runs $HOME/.bashrc. If this sets a particular directory, then you end up in that directory and not in the directory where you ran your shell script. I use to see this when I too was involved in ClearCase hell. People setup their .kshrc script (it was the days before BASH and most people used Kornshell) to setup their views. Unfortunately, this made running any other shell script almost impossible to do.