The leading dot in your command means "relative to the current directory". Remove it and it'll refer to "the file someScript in the directory /home/user/scripts:

/home/user/scripts/someScript

If you get "Permission denied", it's either because you do not have sufficient permissions to access the file in the directory of other users or because the file is not executable. To make it executable, run:

chmod +x /home/user/scripts/someScript

sh /path/to/script will spawn a new shell and run she script independent of your current shell. The source (.) command will call all the commands in the script in the current shell. If the script happens to call exit for example, then you'll lose the current shell. Because of this it is usually safer to call scripts in a separate shell with sh or to execute them as binaries using either the full (starting with /) or relative path (./). If called as binaries, they will be executed with the specified interpreter (#!/bin/bash, for example).

As for knowing whether or not a script will find the files it needs, there is no good answer, other than looking at the script to see what it does. As an option, you could always go to the script's folder in a sub-process without leaving your current folder:

(cd /wherever/ ; sh script.sh)

Use cd in a subshell; the shorthand way to use this kind of subshell is parentheses.

(cd wherever; mycommand ...)

That said, if your command has an environment that it requires, it should really ensure that environment itself instead of putting the onus on anything that might want to use it (unless it's an internal command used in very specific circumstances in the context of a well defined larger system, such that any caller already needs to ensure the environment it requires). Usually this would be some kind of shell script wrapper.

I don't know if this counts, but you can make a subshell:

$ (cd /var/log && cp -- *.log ~/Desktop)

The directory is only changed for that subshell, so you avoid the work of needing to cd - afterwards.

Interactively, you can always run your scripts by typing ~/yourscript.sh on the command line, but that's very limiting, especially if you want to write more scripts that call the scripts you've already written.

A more integrated and flexible approach involves putting all your scripts into one directory and adding that directory to your PATH environment variable.

After you do that, you'll be able to type yourscript.sh, and no matter which directory you're in, the shell will find your script and execute it.

This is how it's usually done:

1. Make a bin directory under your home directory and mv your scripts into it.
2. Change all the scripts to executable (chmod +x).
3. Ensure that your PATH environment variable contains your $HOME/bin directory. On some systems, the default ~/.profile will add your $HOME/bin directory to the PATH automatically, so check your ~/.profile before modifying.

Let me illustrate with some script:

mkdir ~/bin
mv ~/*.sh ~/bin
chmod +x ~/bin/*
if ! grep 'PATH=.*HOME/bin' ~/.profile
then
    echo 'export PATH="$HOME/bin:$PATH"' >> ~/.profile
fi
. ~/.profile
echo "$PATH"      # you should see your bin directory
cd /tmp           # change to another random directory
type myscript.sh  # see if the shell finds your scripts

If you see your bin directory in your PATH, then it's a good idea to logout and log back in and change to another directory and execute type yourscript.sh again to make sure everything is setup correctly.

I understand from your comments that you want your script to have its current working directory to be in A/B/C when it executes. Ok, so you go into directory A:

cd A

and then execute script.sh from there:

(cd B/C; ./script.sh)

What this does is start a subshell in which you first change to the directory you want your script to execute in and then executes the script. Putting it as a subshell prevents it from messing up the current directory of your interactive session.

If it is a long running script that you want to keep in the background you can also just add & at the end like any other command.

Call the program like this:

(cd /c; /a/helloworld)

The parentheses cause a sub-shell to be spawned. This sub-shell then changes its working directory to /c, then executes helloworld from /a. After the program exits, the sub-shell terminates, returning you to your prompt of the parent shell, in the directory you started from.

Error handling: To avoid running the program without having changed the directory, e.g. when having misspelled /c, make the execution of helloworld conditional:

(cd /c && /a/helloworld)

Reducing memory usage: To avoid having the subshell waste memory while hello world executes, call helloworld via exec:

(cd /c && exec /a/helloworld)

[Thanks to Josh and Juliano for giving tips on improving this answer!]

You can't know in all circumstances, but often (not always) when you run a script by path instead of letting the shell search $PATH, the path to the script will be in $0. You can then use dirname "$0" or ${0%/*} to get the path.

You use relative paths in script. So, you need to change your present working directory accordingly in motherscript before calling script.

# motherscript

cd 001
./script

If you want to run the script from everywhere you need to add it to your PATH. Usually /usr/local/bin is in the path of every user so this way it should work. So check if in your system /usr/local/bin is in your PATH doing, on your terminal:

echo $PATH 

You should see a lot of paths listed (like /bin, /sbin etc...). If its not listed you can add it. A even better solution is to keep all your scripts inside a directory, for example in your home and add it to your path.

To add a directory in your path you can modify your shell init scripts and add the new directories, for example if you're usin the BASH shell you can edi your .bashrc and add the line:

PATH=$PATH:/the_directory_you_want_to_add/:/another_directory/

This will append the new directories to your existing PATH.

You can call your script using only the whole path, without the dot .:

/path/to/script

sudo also works fine:

sudo /path/to/script

Will they usually find all the stuff they need to run properly?

Do you mean like, "will my script find the files which are in the same folder?" That depends of your code. For example, if you have the script /tmp/test.sh:

#!/bin/bash
ls

If you invoke it from your home folder, it will run ls in your home:

test@ubuntu:~:/tmp/test.sh
Desktop     Dropbox         Imagens  NetBeansProjects     Público     
Documentos  Modelos    R          Vídeos

In this situation, dirname is your ally:

#!/bin/bash
current=$(dirname $0)
ls $current

Running it from your home folder, it gives:

test@ubuntu:~:/tmp/test.sh
acroread_1000_1000     hiRF7yLSOD              pulse-2L9K88eMlGn7   
unity_support_test.0    clementine-art-jt5332.jpg

which is the content of my /tmp/ folder.

The reason that your code does not work is because of what happens when a filename globbing pattern expands.

The pattern would expand to a list of matching pathnames. The code in your script would call sh with this list. This means it would execute the first matching name as the script and give the other names as arguments to that script:

sh /var/scripts/dir/my_first.inc.sh /var/scripts/dir/my_second.inc.sh /var/scripts/dir/my_third.inc.sh

Instead, just iterate over the matching names:

#!/bin/sh

for name in /var/scripts/*/my_*.inc.sh; do
    sh "$name"
done

This assumes that each of the matching names is a script that should be executed by sh (not bash). If the individual files are executable and has a proper #!-line, then remove the sh from the invocation of the script in the loop above. If the files are "dot scripts", i.e. script that should be sourced, then replace sh by . instead to have the script execute in the current script's environment.

Note that the script above can be an sh script (#!/bin/sh) as it does not use any bash features. If the other script are "dot scripts", then you may obviously have to change this to #!/bin/bash or whatever other interpreter is needed to source the scripts.

First confirm that the configure script is present where you think it is. Second make sure that it's executable:

$ ls -l ./configure 
-rwxrwxr-x 1 saml saml 100 Jun  9 05:11 ./configure

If both of the checks are OK then you might want to try running configure by first changing directories to /mainfolder/execution and then running configure like this:

$ cd /mainfolder/execution
$ ../configure

You also might want to try it this way:

$ cd /mainfolder
$ ./configure execution

EDIT #1

According to comments left by OP, the following directory structure appears to be what he's describing:

$ tree -f
.
`-- /mainfolder
    `-- /mainfolder/execution
        `-- /mainfolder/execution/configure