defining variables inside function

Question

After some reading somewhere on this interwebs, I found that it was best practice to to the following when using the output of a command as a variable:

FILE_CORE_NAME="$(/usr/bin/env basename $(/usr/bin/env awk -F "." '{print $1}' <<< "${FILE_TO_PROCESS}"))"; local FILE_CORE_NAME;

However, when I use this configuration the value derived for FILE_CORE_NAME is blank. If I remove the trailing local FILE_CORE_NAME from the line, everything works as expected.

Is what I read wrong or am I doing it wrong?

Answer 1

FILE_CORE_NAME="$(/usr/bin/env basename $(/usr/bin/env awk -F "." '{print $1}' <<< "${FILE_TO_PROCESS}"))"; local FILE_CORE_NAME;

Even when reformatted on several lines for legibility

FILE_CORE_NAME="$(
  /usr/bin/env basename $(
     /usr/bin/env awk -F "." '{print $1}' <<< "${FILE_TO_PROCESS}"
  )
)"
local FILE_CORE_NAME

Is wrong on many accounts:

• awk runs that {print $1} command for every line of its input, so if you have a $'/a.b/c\nd.e\nf/g.h.i' file for instance, it will output /a<newline>d<newline>f/g'. newline being as valid a character as any and filename not being guaranteed to be text, you shouldn't use line-based text utilities to process them.
• as hinted above, even for single-line file paths, if you have a /foo.d/file.txt or a /foo.bar.2020.jpg file, you'll get /foo instead of /foo.d/file or /foo.bar.2020. The basename should be done first, and it's the part up to the last . that you want to retrieve.
• quotes were omitted around the second $(...), so it's subject to split+glob with all the possible catastrophic consequences if can have.
• the -- option delimiter is missing after basename, so if the file path starts with a - it will fail.
• local is to declare a variable local to the function. However here, you're defining it local after having modified it, so you've modified the variable of the caller of the function. Then in bash (contrary to ash where the local builtin comes from), unless the locvar_inherit option has been enabled, local var declares the variable local but without any value set.
• all uppercase variable names should be left for environment variable names or at least those with a global scope throughout the script and dependencies.
• I can't see the point of using /usr/bin/env here.

Here, the obvious thing to do would be to switch to zsh and do:

local core_name=$FILE_TO_PROCESS:t:r

Where, like in csh from the 70s or vim (and even bash history substitution, but not its parameter expansions), :t gives you the tail and :r the root name (with one extension removed).

If you have to use bash, you can do:

local core_name
core_name=$(basename -- "$FILE_TO_PROCESS") || return
core_name=${core_name%.*}

(which would also work in all Ash like shells that have a local builtin).

Bearing in mind that $(...) removes trailing newline characters.

Beware that if $FILE_TO_PROCESS is for instance /home/me/.zshrc, $core_name will become the empty string. You might want to guard against that and some other special values such as -, . or .. depending on what you want to do with that $core_name in the rest of the function.

Answer 2

local name=value creates a local variable and set it to value. In your case there is no value so you create a local variable which is empty and the local variable hides the non-local variable with the same name in which you stored the command output.

So you need to first declare the variable local and then assign it a value.

The following snippet:

func() {
  x=4
  local x
  echo "func: $x"
}
x=1
func
echo "outside: $x"

It prints

func:
outside: 4