On 20/07/2024 05:25, Greg Wooledge wrote:
#!/bin/sh
echo "I am a.sh, and inside me, VAR=<$VAR>."
A way to report a bit more information:
cat /tmp/test.sh
#!/bin/sh
printf "%s: VAR %5s %10s value=<%s>\n" \
"$0" "${VAR+set}" "${VAR:+not empty}" "$VAR"
/tmp/test.sh
/tmp/test.sh: VAR value=<>
VAR= /tmp/test.sh
/tmp/test.sh: VAR set value=<>
VAR=a /tmp/test.sh
/tmp/test.sh: VAR set not empty value=<a>
On 19/07/2024 20:31, The Wanderer wrote:
$ env | grep ^_
_=/usr/bin/env
That appears to be a (shell?) environment variable.
<https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-_005f>
"Bash Variables"
Alternatively
info "(bash)Bash Variables"
man bash
Back to the original questions, "env" is handy to force path search,
e.g. in shebang
#!/usr/bin/env perl
unlike
#!/usr/bin/perl
may run perl from /usr/local/bin/perl, ~/bin/perl, etc. depending on
$PATH. There are some cases when commands are not interpreted by shell
and "env" allows to set environment variables for program, e.g. Exec=
entries in .desktop files allow
Exec=env VAR=value some-application
but not
Exec=VAR=value some-application
(I do not remember if VAR=value needs escaping) despite both cases work
in shell.
