That's pretty basic, but unless you specify more, I don't know what else to add.
Just read the first line from the file, save it as a variable, and use simple comparisons like -gt
(greater than) or -eq
(equal to) to get your desired output. You can of course switch $val
and $comp
here, depending on what you really want.
#!/usr/bin/env bash
val=$(< c.txt)
comp=$1
if [[ "$val" -gt "$comp" ]]
then echo "greater"
elif [[ "$val" -eq "$comp" ]]
then echo "equal"
fi
Here, c.txt
is your input file, and it is assumed that it only contains one line. The value you compare against is read as an argument, therefore you should call this script as:
./script.sh 40
Anyway, I'd highly recommend to read the Advanced Bash Scripting Guide.
There are three options I use when I have a bash script that I want to behave differently when it is sourced vs. when it is executed (or in other words have data items in a script that I want access to without executing any code at that time). The comments touched on them to an extent.
Option One
Determine when being sourced and end 'sourcing' at appropriate time
Separate script into two sections, exit from script when sourced before getting to lower second
Create an upper section of script with definitions (functions / variable assignments / etc), but no direct code execution.
Just before the executable code section starts, place logic that will exit the script if it detects it is being sourced.
The following code segment will do this:
file1.sh
#!/usr/bin/env bash
export var1="/data/share"
export var2='password'
# --- End Definitions Section ---
# check if we are being sourced by another script or shell
[[ "${#BASH_SOURCE[@]}" -gt "1" ]] && { return 0; }
# --- Begin Code Execution Section ---
echo "Hello"
echo $var1
echo $var2
file2.sh
#!/usr/bin/env bash
source file1.sh
echo "$var1"
echo "$var2"
Output of running ./file2.sh
$ ./file2.sh
/data/share
password
Option Two
This one is usually only used in complex situations, and for this particular example it's overkill. I create a function in the file that I want to source, and in that function determine what should be available to the caller. In this case it's the two exported variables. Normally I use this mode when I have associative arrays, which are otherwise nearly impossible to hand around. Also, the tmp file should be deleted by the caller; but I didn't in this case:
file1.sh
#!/usr/bin/env bash
export var1="/data/share"
export var2='password'
exportCfg() {
tmpF=$(mktemp)
declare -p var1 var2 > "$tmpF"
echo "$tmpF"
}
if [ "$1" == "export" ]; then
exportCfg;
exit 0;
fi
echo "Hello"
echo $var1
echo $var2
file2.sh
#!/usr/bin/env bash
source $(./file1.sh export)
echo "$var1"
echo "$var2"
The output from executing file2.sh is the same as above
Option 3
The final common way I handle this is simply with a library file that only holds definitions, and has no code that will execute when sourced or directly run.
This is simply a matter of dividing up your code. I have a group of bash 'libs' that contain frequently used functions, and on a per project basis usually setup a small sourceable library for storing configuration data (constants). If that data includes populated arrays, then I will also use a version of Option 2.
Best Answer
Word-Splitting
Protect your parameter strings and expansions from word-splitting by wrapping them in "quotes". Notice how the following examples are colour-coded differently? It's revealing the differences between how the words are being grouped and separated.
You may or may not actually even need to \ escape\ the file path's white-space anymore, either.
Quoted
Un-Quoted