I have a snippet of code that works when used in its own .sh file:

#! /bin/bash
LastFileUpdate=`find $dir -name $SearchString -type f -printf '%T@ %p\n' | sort -n | tail -n 1| awk '{print $1}'`
echo $LastFileUpdate

This code works on its own, but when I insert it into another .sh script, it doesn't return anything! The variables are not used anywhere else. What could cause this?

let "Diff = $SystemTime - $LastFileUpdate"

This returns " let: Diff = 1111111 - : syntax error: operand expected(expected token is " ")

This implies the variable LastFileUpdate never even gets populated by the expression, which is wierd, because it works on it its own.

Ideas?

Dani AI

Generated

Quoting the pattern was the real fix. As noted, putting the pattern argument in quotes stopped the larger script from behaving differently than the isolated test. ’s comment about using functions is still valid for scoping issues, but the immediate problem here was shell globbing / word-splitting, not scope.

Why this happens: an unquoted variable that can contain wildcard characters or spaces is processed by the shell before the command runs. That pathname expansion can turn a single intended argument into one or more literal filenames (or otherwise change the argument list). The net effect is find doesn’t receive the pattern you expected and returns nothing; the empty result is why the arithmetic expression later fails.

Practical, robust rules that avoid this class of bug:

  • Always double‑quote variable expansions that should be a single argument (both directory and pattern).
  • Use modern, clearer constructs: command substitution $(...) and arithmetic expansion $((...)).
  • Test for empty results before doing math.

Example checks (not the original find line):

if [ -z "$LastFileUpdate" ]; then
  printf 'no match: LastFileUpdate is empty\n'
else
  Diff=$(( SystemTime - LastFileUpdate ))
fi

Quick debugging tips: enable tracing with set -x to see how the shell expands arguments, print variable contents safely with printf '%q\n' "$var", or temporarily disable globbing with set -f (or use shopt -s nullglob in bash if that behavior is desired). Quoting the pattern is the simplest, most portable fix; the checks above help catch similar silent failures inside larger scripts.

Recommended Answers

All 4 Replies

Shell variables, including environment variables, are context sensitive. IE, you set a variable in one script, it (or its changes) are not visible outside of it after exit. If they are exported environmeent variables, then they are visible to scripts that IT calls, but not to the script that called it.

Instead of using separate scripts, use bash functions. Variables set there would be visible to other functions inside the same executing script.

Thanks rubberman, I reported this for deletion before I saw you reply because I figured it was in the wrong spot.

The code is all in the same script, I just isolated the first set to see if it would work and it does in its own script. When I insert it into the other script, it fails. It has no apparent dependencies AFAIK. In this case, this variable is only used for the lines in the example.

If I put double quotes around the $SearchString portion it works. What originally went there was:

Word_*

I replaced that with:

"Word_*"

Now it works and I do not know why.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.