Environment pollution : "${strings}" vs /usr/bin/strings?

If I am not wrong,
there seems to be an undocumented environment variable “strings” - or that variable gets replaced by some script ?

however, I use in some script something like :

my_var="$(/usr/bin/strings  "${HOME}/some_file.txt" | grep "test")"   # seems not to work ....
my_var="$(strings  "${HOME}/some_file.txt" | grep "test")"   # seems not to work ....
my_var="$(cat "${HOME}/some_file.txt" | /usr/bin/strings | grep "test")"   # seems not to work ....
my_var="$(cat "${HOME}/some_file.txt" | '/usr/bin/strings' | grep "test")"   # seems not to work ....
/usr/bin/strings  "${HOME}/some_file.txt" # gives some unrelated output of build internals 

I set up xenial in one of my VMs to make sure it is nothing common.

What I do wrong ?

All the commands WFM.

One of the internal functions sets a Bash variable named strings which is used by several other internal functions. But this shouldn’t affect any of the commands you gave. Your build logic must be at fault – maybe it redefines this command?

Another possible reason is that some_file.txt is not where you expect it to be.