"Exec" into specific folder - nsis

From an NSIS script (located at C:\nsis\ for example), I execute an external program (let's say something.bat) with some paramerters:
Exec '"Z:\draft\something.bat" $param1 $param2'
something.bat is suppoed to rename the directory C:\nsis. My question is, how can I tell Exec to launch something.bat inside Z:\draft\ and not C:\nsis\? Because, it can't rename the directory otherwise.
Thanks.

You can use SetOutPath to set the current working directory. I think that should do what you want.
In the NSIS documentation you can also see that it uses the variable that SetOutPath sets (which is $OUTDIR) for Exec statements.
4.9.1.2 Exec
Exec command
Execute the specified
program and continue immediately. Note
that the file specified must exist on
the target system, not the compiling
system. $OUTDIR is used for the
working directory.

Related

Executing a script in a different directory without having to use the full path

I generate a bash script named "script1" and place it in the directory /home/Me/bin. I want to execute it (just by calling it's name ./script1) without the complete path from any directory. How can I do it? Is there any specific command?
The directory the script is in needs to be included in your PATH environment variable. $HOME/bin usually is included already. Otherwise, you can add it in your ~/.bashrc:
PATH=$PATH:/home/Me/bin
Add "/home/Me/bin" to your PATH.
Then, you can just call "script1".

Libraries paths defined by Master bash script, but having to run it in every terminal session, how to make more efficient?

I have build a set of libraries and many of my Fortran programs will use them. This creates a problem in that if I ever need to change the location of the libraries then I will need to individually update the path directories in each make file.
How is this usually overcome? I have planned instead to have each make file read a path from a single master path file in the home or root directory (this files location will never change). Within this file is the path for each Library and if any path changes only this file needs to updated.
So I wrote a bash script file, called Master_Library_Paths:
export Library1_Name = {Library1_Name_Path}
echo $Library1_Name
export Library2_Name = {Library2_Name_Path}
echo $Library2_Name
export Library3_Name = {Library3_Name_Path}
echo $Library3_Name
And placed it in my home directory. Then in the make files, I have a line:
$(shell . {Path for Master_Library_Paths} ) \
And load the libraries:
-I$(Library1_Name)
-I$(Library2_Name)
-I$(Library3_Name)
This works great if I run ./Master_Library_Paths in the terminal session first and then go to the directory to compile the program, however that is quite time consuming, How can I fix it so that these arguments Library1_Name, Library2_Name ect are known throughout the system?
New system wide LD_LIBRARY_PATH´s can be added in /etc/ld.so.conf , /etc/ld.so.conf.d/
Or may be in /etc/profile.d/
-

When should I type ./ to run program and when I should not?

I am very beginner in Linux. I am confused, can someone tell me when we should start the command line with ./ to run a program and when we don't?
I see they do not use it in tutorials, but bash would not recognize the program w/o it.
Thanks a lot,
Sadegh
'.' refers to the current directory. Similarly '..' refers to the parent director.
Consider the following examples:
./foo
Will attempt to execute a program called foo in the current directory.
../foo
Will attempt to execute a program in the parent directory. This and ./foo are called "relative paths" as they are relative to your current position.
foo
Will search for the program in your current PATH, which is a sequence of directories the shell searches to find executables. You can see your value of PATH by enter ing 'echo $PATH'.
Finally, you can give an 'absolute path', such as:
/home/bar/foo
Which will use the whole path starting at root ('/').
when you type a command, linux will finds executables to execute it.
the question is where should it search for?
there is a variable in bash which is called $PATH. lets echo it to see it's content:
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/game/usr/local/games
so the os looks at these paths
So, what happens if your executable file is not in the $PATH variable????? (for example your scripts)
in this situation you should tell it where your executable file is!
if it is in current directory run this:
./program_name
./app is specifying the path to app. Same as /usr/bin/app is specifying a path.
Unless the directory containing the app is on your PATH then you need to specify a path.

simple shell script to copy files and folders and also execute a command

I haven't written any Shell scripts before, but i have to write a simple shell script to do the following;
I will keep all the required files in a single folder and bundle it with this shell script as a tar file; so when the user runs the shell script, it needs to copy the respective files to the respective destinations.
The execution of copy as follows:
copy the plugin.so file to /usrlib/mozilla/plugins/
copy the .so library files to /usr/local/lib/
copy some header files directories(folders) to /usr/local/include/
and finally, need to do ldconfig.
Basically, you can add in a script any command you are able to type inside the terminal itself. Then, you have two options for executing it:
Execute it from the terminal with sh your_script.sh. You don't even need to give execute permission to it with this solution.
Give it the execute permission and run it with ./your_script.sh.
For the second solution, you have to start the file with what is called a shebang. So your script will look like:
#!/bin/sh
cp path/to/source path/to/destination
cp path/to/source path/to/destination
cp path/to/source path/to/destination
ldconfig
echo "Done!"
Nothing else. Just write the commands one after the other.
The first line is the so-called shebang and tells the shell which interpreter to use for the script.
Note: the extension for shell scripts is usually .sh, but you can actually name your file however you prefer. The extension has no meaning at all.
Good scripting!

SVN Pre-commit Symbolic Link Path in Perl

In my workplace, there's one Perl script that runs on a Unix machine every time someone tries to check-in a file to the SVN repo for any of the 10-20 projects.
The way it works is that each project has its own "Hooks" folder with a file called "pre-commit" which SVN automatically executes when someone check-in something. Except the "pre-commit" file is actually a symbolic link to the one central Perl script common to all projects just so that if a change needs to be made to the Perl script it doesn't need to be done for every project.
So my problem is this: I need to put a text file in each of these projects' "hooks" directory, each one containing some settings specific to that project. So there will be 10-20 settings files (one per project) each in their respective "hooks" directory.
The problem is that I need to open these text files in the Perl script and read from them but I'm having issues letting Perl know where to find it. I tried using the $0 parameter which is supposed to tell me where the script is being executed from but because it's a symbolic link it just says "Not a directory" and the script terminates. I need to get the path of the "hooks" directory so that I can find the text file.
The SVN pre-commit script is supposed to be invoked with the path to the repository as its first argument. Inside a Perl script, that argument should be available as $ARGV[0]. You should be able to build the path to the corresponding hooks directory or to a file inside that directory by simply appending to the repository path, like this:
$repopath = $ARGV[0];
$hookspath = $repopath . "/hooks";
$myfilepath = $hookspath . "/myfile";
although for maximum portability it would be cleaner to use the pathname-manipulation functions in the File::Spec module to do this.
If this approach doesn't work then you'll have to explain more about how your Perl script gets invoked. For instance, if your pre-commit script is really a shell script wrapper that eventually invokes perl then perhaps it's not passing the pre-commit arguments along properly.
Showing us your current code that's failing would be a good thing too.

Resources