trying to start XBMC with a bash from BOXEE - bash

Hi new to unix and bash programming. I am trying to make a simple startup script to have my boxee start up XBMC that is stored on a Memory card. I can start the commands by entering them in telnet, but if i call the test.sh script it wont allow me to access the directory where XBMC is stored on.
#!/tmp/mnt/6337-3533/xbmc
BASEDIR=/tmp/mnt/6337-3533/xbmc $0
killall U99boxee; killall BoxeeLauncher; killall run_boxee.sh; killall Boxee; killall BoxeeHal
GCONV_PATH=$PWD/gconv AE_ENGINE=active PYTHONPATH=$PWD/python2.7:$PWD/python2.7/lib-dynload XBMC_HOME=$PWD ./xbmc.bin -p
gives:
# sh test.sh
: not foundne 2:
: not foundne 3:
test.sh: line 4: /tmp/mnt/6337-3533/xbmc: Permission denied
: not foundne 5:
: not foundne 6:
killall: U99boxee: no process killed
killall: BoxeeLauncher: no process killed
killall: run_boxee.sh: no process killed
killall: Boxee: no process killed
: no process killed
: not foundne 9:
: not foundne 10:
test.sh: line 11: ./xbmc.bin: not found
#
i used the command line from xbmc. and i assume the $PWD expects the script to be in /tmp/mnt/6337-3533/xbmc
if I enter "cd /tmp/mnt/6337-3533/xbmc" in telnet it wil bring me to the dir
but if i put that code in the script, it will give me access denied.
What am i doing wrong here. or how can i approach this so i wont have to change my work directory?

Line 2 will expand to
BASEDIR=/tmp/mnt/6337-3533/xbmc test.sh
This will try to run test.sh with the /tmp/mnt/6337-3533/xbmc interpreter specified on line 1, which will fail since that is a directory. Line 1 doesn't have to specify a valid interpreter if you're going to run the script by doing 'sh test.sh', but you'll probably be happier if you change line 1 to
#!/bin/sh
If you just want the invocation of xbmc.bin to see the value for BASEDIR in its environment, replace line 2 with
BASEDIR=/tmp/mnt/6337-3533/xbmc
export BASEDIR

Related

What does `exec 200>lockfile` do?

I'm not familiar with the exec command. A bash tutorial about how to lock files throws this:
exec 200>lockfile
flock 200
...
flock -u 200
I got that it is creating a file named lockfile and assigning it an FD of 200. Then the second command locks that file. When done working with the file, the last command unlocks it.
Doing so, any other concurrent instance of the same script will stay at that second line until the first instance unlocks the file. Cool.
Now, what I don't understand is what is exec doing.
Directly from the bash command line, both options seem to work:
exec 200>lockfile
200>lockfile
But when the second option is used in the script, a "Bad file descriptor error" is raised.
Why is exec needed to avoid the error?
--- edit ---
After some more "serious research", I've found an answer here. The exec command makes the FD stay for the entire script or current shell.
So doing:
200>lockfile flock 200
Would work. But later flock -u 200 would raise a "Bad FD error".
The manual seems to mention shell replacement with given command. What does that has to do with file descriptors?
This is explained in the second sentence:
exec: exec [-cl] [-a name] file [redirection ...]
Exec FILE, replacing this shell with the specified program.
If FILE is not specified, the redirections take effect in this
shell. [...]
Essentially, doing exec 42> foo.txt from inside myscript.sh opens foo.txt for writing on FD 42 in the current process.
This is similar to running ./myscript.sh 42> foo.txt from a shell in the first place, or using open and dup2 in a C program.

Using 'exec' in bash_profile stops login shell

I'm creating the following .bash_profile (from linuxfromscratch guide) for lfs user:
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
When executing su - lfs I get:
[1]+ Stopped su - lfs
Executing fg resumes lfs' user shell. Why is this happening?
That's because exec executes the code in the current process. Normally a command is executed in a child shell/environment. Try the following:
$ bash # open second shell
$ exec false # close second shell
$ echo $? # get exit code
$ exit # close terminal
The man page isn't really helpful here. I often use exec if I run a script through a Qt process and it should end after some period of time, regardless whether the command if finished or not.

Error when using mpirun with a shell script

When I run
mpirun -np 4 mpi_script.sh
I get the error
Open MPI tried to fork a new process via the "execve" system call but failed.
...
Error: Exec format error
despite the fact that I can run the script with ./mpi_script.sh
In my case the problem was I didn't have a shebang.
Adding #!/usr/bin/env bash to the top of my script fixed it:
#!/usr/bin/env bash
# rest of script
# ...
N.b. be sure that the file has execute permissions:
chmod +x mpi_script.sh

Run a bash script via another bash script to delete a file is not working properly

I have a bash script start.sh which calls another run.sh, which takes me to another prompt where I have to delete a file file.txt and then exit out of that prompt.
When I call run.sh from inside start.sh, I see the prompt and I believe that it deletes the file.txt but the inner/new prompt waits for me to exit out of it while the script is running - meaning it needs intervention to proceed. How do I avoid it in bash?
In Python I can use Popen and get it going but not sure about bash.
EDIT: I would rather like to know what command to provide to exit out of the shell (generated from running run.sh") so I can go back to the prompt where "start.sh" was started.
Etan: To answer your question
VirtualBox:~/Desktop/ > ./start
company#4d6z74d:~$ ->this is the new shell
company#4d6z74d:~$ logout ---> I did a "Control D here" so the script could continue.
Relevant part of start.sh which:
/../../../../run.sh (this is the one that takes us to the new $ prompt)
echo "Delete file.txt "
rm -f abc/def/file.txt
You can run run.sh in the background using &. In start.sh, you would invoke the script via /path/run.sh &. Now, start.sh will exit without waiting for run.sh to finish (which is running in the background).

Cygwin .sh file run as Windows Task Scheduler

Having issues getting this shell script to run in windows task scheduler.
#!/bin/bash
# Script to ping the VPN server for testing
RESULT=$(ping 192.168.1.252 | grep "Lost" | awk {' print $10 '})
LOG=/home/admin/results.txt
if [ "$RESULT" -gt 0 ];then
echo "VPN 192.168.1.252 NOT pinging" >> $LOG
else
echo "VPN Online"
fi
When I run it in cygwin, it runs with no issue, but when I attempt to run it from command prompt, I get the following:
C:\cygwin64\bin>bash test.sh
test.sh: line 4: grep: command not found
test.sh: line 4: awk: command not found
test.sh: line 7: [: : integer expression expected
My question is, how do I get it to run with bash instead so that it actually knows the grep and awk commands?
In Windows Scheduler, I have Action: Start A Program
Details: C:\cygwin64\bin\bash.exe
Argument: test.sh
Start in: C:\cygwin64\bin
Am I missing something?
I figured it out.
In the Windows Task Scheduler, I had to pass:
Program/script: C:\cygwin64\bin\bash.exe
Add arguments: -c -l test.sh
Start in: C:\cygwin64\bin
In correction to what Jimmy found:
Add arguments: -c -l "c:/FileFolder/test.sh"
You don't need the Start in argument anymore.
For the longest time I was experiencing the same issue as the OP: command not found errors when trying to run a shell script from Task Scheduler or the Command Prompt, despite the fact that running the same script from a Cygwin terminal worked fine.
After some more research I eventually realised that the reason was because my usual Bash PATH ~/.bashprofile wasn't being loaded, and that I needed to use Windows' Environment Variables window to add C:\cygin64\bin to my PATH environment variable (system or user, it doesn't really matter). This directory contains common system executables like grep and awk, which is why Bash is unable to locate them until the path is added to Windows' PATH.

Resources