I see various formats, such as
if [[ -L ${LINK1_DIR} ]]; then

if [[ -L "$LINK1_DIR" ]]; then

rather than just $LINK1_DIR
I presume this is insurance to ensure script works in every version of
Red Hat, Debian, Arch whatever...
So which is the ideal extra character to put around the environment
variable?

On 17.10.2022 at 19:28, Barry Stir scribbled:

> I see various formats, such as
> if [[ -L ${LINK1_DIR} ]]; then
>
> if [[ -L "$LINK1_DIR" ]]; then
>
> rather than just $LINK1_DIR
> I presume this is insurance to ensure script works in every version
> of Red Hat, Debian, Arch whatever...
> So which is the ideal extra character to put around the environment
> variable?

There are different reasons for using either notation, and they are not
mutually exclusive. Portability between distributions is irrelevant in
this regard.

° The ${VARIABLE} notation bears preference due to the fact that it
protects against errors caused by concatenation.

° The "$VARIABLE" notation is used when there is a chance of the
variable containing spaces or other special characters, such as
e.g. a backslash or a newline character.

Therefore, one can combine the two formats as "${VARIABLE}" if
one suspects that the variable may contain spaces and/or other
special characters AND if the variable is to be concatenated with
either a literal or another variable.

--
With respect,
= Aragorn

* Barry Stir <scooter@mealteam6.mil>
| I see various formats, such as
| if [[ -L ${LINK1_DIR} ]]; then
>
| if [[ -L "$LINK1_DIR" ]]; then
>
| rather than just $LINK1_DIR
| I presume this is insurance to ensure script works in every version of
| Red Hat, Debian, Arch whatever...

Using "" also works if the variable is not set or empty, otherwise you
get a syntax error in that case.

Usually you need {} only when additional text should be appended to the
contents: ${LINK1_DIR}X (because without the {} the variable name would
be LINK1_DIRX).

| So which is the ideal extra character to put around the environment
| variable?

It depends :-)

"" also prevents file name globbing from happening, which might
or might not be what one wants.

$ touch foo1 foo2
$ a=foo\*
$ echo $a
foo1 foo2
$ echo "$a"
foo*

R'

On 17/10/2022 13.28, Barry Stir wrote:
> I see various formats, such as
>   if [[ -L ${LINK1_DIR} ]]; then
>
>   if [[ -L "$LINK1_DIR" ]]; then
>
> rather than just $LINK1_DIR
> I presume this is insurance to ensure script works in every version of
> Red Hat, Debian, Arch whatever...

There are no differences among distributions. Bash is bash everywhere.

> So which is the ideal extra character to put around the environment
> variable?

Others have explained it well in their posts.

--
Cheers,
Carlos E.R.

Barry Stir <scooter@mealteam6.mil> wrote:
> I see various formats, such as
> if [[ -L ${LINK1_DIR} ]]; then
>
> if [[ -L "$LINK1_DIR" ]]; then
>
> rather than just $LINK1_DIR
> I presume this is insurance to ensure script works in every version of
> Red Hat, Debian, Arch whatever...
> So which is the ideal extra character to put around the environment
> variable?

The ${} form has a different meaning to the quotes (i.e., they do
different things).

The ${} form is defined in the bash man page this way:

${parameter}
The value of parameter is substituted. The braces are
required when parameter is a positional parameter with
more than one digit, or when parameter is followed by a
character which is not to be interpreted as part of its
name.

So the ${} form provides a way to delimit exactly the name of the
variable, without confusing it with further concatenated text.

The double quotes "" are for preventing the interpretation of special
characters that might be stored in the variable. Double qutoes are
defined this way in the bash man page:

Enclosing characters in double quotes preserves the literal
value of all characters within the quotes, with the exception of
$, `, \, and, when history expansion is enabled, !. The
characters $ and ` retain their special meaning within double
quotes. The backslash retains its special meaning only when
followed by one of the following characters: $, `, ", \, or
<newline>. A double quote may be quoted within double quotes by
preceding it with a backslash. If enabled, history expansion
will be performed unless an ! appearing in double quotes is
escaped using a backslash. The backslash preceding the ! is
not removed.

So, if one is not appending text to the variable, one only needs to do:

"$LINK1_DIR"

The {}'s are redundant in that case. However there are some folks who
seem to like the look of ${...} and always include the {}'s.

The double quotes, however, are in most cases, a very good idea to
always include, because if you leave them off, and one day the variable
contains a space (or other character special to the shell) then things
will break, often badly.

Barry Stir <scooter@mealteam6.mil> wrote:
> I see various formats, such as
> if [[ -L ${LINK1_DIR} ]]; then
>
> if [[ -L "$LINK1_DIR" ]]; then
>
> rather than just $LINK1_DIR
> I presume this is insurance to ensure script works in every version of
> Red Hat, Debian, Arch whatever...
> So which is the ideal extra character to put around the environment
> variable?

Hi Barry.

be aware that these forms are not equivalent.

"$LINK1_DIR" and "${LINK1_DIR}" are - kind of - equivalent and
$LINK1_DIR and ${LINK1_DIR} are.

The version with curly brackets is more secure since if you have a
variable "LINK1" defined

echo "-$LINK1_DIR-"

either triggers an error or just prints "--" while

echo "-${LINK1}_DIR-"

prints "-<LINK1 contents>_DIR-" and vice versa if you have a variable
"LINK1_DIR" defined.

Regards
Henning
--
It doesn't matter whether you win or lose -- until you lose.

In comp.os.linux.misc, Barry Stir <scooter@mealteam6.mil> wrote:
> I see various formats, such as
> if [[ -L ${LINK1_DIR} ]]; then
>
> if [[ -L "$LINK1_DIR" ]]; then
>
> rather than just $LINK1_DIR I presume this is insurance to ensure
> script works in every version of Red Hat, Debian, Arch whatever... So
> which is the ideal extra character to put around the environment
> variable?

As others have mentioned, ${} is to force parsing when being next to
something could confuse the variable name. The "$" version is to
force an empty tring to exist in contexts where it might get lost.

In your example neither is needed. Firstly there's nothing adjoining to
confuse the variable name. Secondly, it is [[ not [.

The one [ ] square bracket form of the test command needs empty string
protection because variable expansion happens before thecommand is run.

The two [[ ]] square bracket form of the test command is explicitly a
shell built-in, so it can recognize empty strings without help.

Elijah
------
${} also gets used for manipulations like "base=${path##*/}"

* Eli the Bearded <*@eli.users.panix.com>
| In your example neither is needed. Firstly there's nothing adjoining to
| confuse the variable name. Secondly, it is [[ not [.
>
| The one [ ] square bracket form of the test command needs empty string
| protection because variable expansion happens before thecommand is run.
>
| The two [[ ]] square bracket form of the test command is explicitly a
| shell built-in, so it can recognize empty strings without help.

Interesting, didn't know that difference:

$ unset bar
$ [[ $bar = x ]] && echo yes
$ type [[
[[ is a shell keyword

$ [ $bar = x ] && echo yes
bash: [: =: unary operator expected
$ type [
[ is a shell builtin

Most probably the error thrown with "[" is to ensure compatibility with
/usr/bin/test?

R'

Ralf Fassel <ralfixx@gmx.de> wrote:
> | The two [[ ]] square bracket form of the test command is explicitly a
> | shell built-in, so it can recognize empty strings without help.
>
> Interesting, didn't know that difference:
>
> $ unset bar
> $ [[ $bar = x ]] && echo yes
> $ type [[
> [[ is a shell keyword
>
> $ [ $bar = x ] && echo yes
> bash: [: =: unary operator expected
> $ type [
> [ is a shell builtin
>
> Most probably the error thrown with "[" is to ensure compatibility with
> /usr/bin/test?

The error thrown with "[" is because what "[" sees as its argv is "= x"
because the shell has already converted $bar into "" before "[" is
executed.

Its complaint is that it found an operator it did not expect (the "=") in
the argv[0] slot. The error message is mathematically accurate, but
very confusing to most users not well versed in math operator language
("=" being a "binary operator" not a "unary operator").

* Rich <rich@example.invalid>
| Ralf Fassel <ralfixx@gmx.de> wrote:
| > | The two [[ ]] square bracket form of the test command is explicitly a
| > | shell built-in, so it can recognize empty strings without help.
| >
| > Interesting, didn't know that difference:
| >
| > $ unset bar
| > $ [[ $bar = x ]] && echo yes
| > $ type [[
| > [[ is a shell keyword
| >
| > $ [ $bar = x ] && echo yes
| > bash: [: =: unary operator expected
| > $ type [
| > [ is a shell builtin
| >
| > Most probably the error thrown with "[" is to ensure compatibility with
| > /usr/bin/test?
>
| The error thrown with "[" is because what "[" sees as its argv is "= x"
| because the shell has already converted $bar into "" before "[" is
| executed.

I understand the problem for the case that there is a command to be
called after variable substitution.

But the original theory (first quotation above) why [[ did not throw an
error was that "... ([[) is explicitly a shell built-in, so it can
recognize empty strings without help."

Since '[' is also flagged as a shell-builtin by bash itself ("type [ =>
shell builtin"), I wondered "can't it detect it then just the same?"

There seems to be a difference between shell-keywords here and
shell-builtins when it comes to the handling of empty variables.

(Of course there is also /usr/bin/[ and /usr/bin/test (2 different
programs on my Opensuse) but I suppose that these are not called
when "[" is a shell-builtin.)

R'

On Tue, 18 Oct 2022 15:01:01 +0200, Ralf Fassel wrote:

> * Rich <rich@example.invalid>
> | Ralf Fassel <ralfixx@gmx.de> wrote:
> | > | The two [[ ]] square bracket form of the test command is explicitly a
> | > | shell built-in, so it can recognize empty strings without help.
> | >
> | > Interesting, didn't know that difference:
> | >
> | > $ unset bar
> | > $ [[ $bar = x ]] && echo yes
> | > $ type [[
> | > [[ is a shell keyword
> | >
> | > $ [ $bar = x ] && echo yes
> | > bash: [: =: unary operator expected
> | > $ type [
> | > [ is a shell builtin
> | >
> | > Most probably the error thrown with "[" is to ensure compatibility with
> | > /usr/bin/test?
>>
> | The error thrown with "[" is because what "[" sees as its argv is "= x"
> | because the shell has already converted $bar into "" before "[" is
> | executed.
>
> I understand the problem for the case that there is a command to be
> called after variable substitution.
>
> But the original theory (first quotation above) why [[ did not throw an
> error was that "... ([[) is explicitly a shell built-in, so it can
> recognize empty strings without help."

[[ is not a "shell builtin", it is a "shell keyword". That makes a difference.

The shell parser handles keywords earlier on in the process than it handles
builtins; more to the point, it handles keywords /before/ it performs $ expansion,
and it handles builtins /after/ it performs $ expansion.

> Since '[' is also flagged as a shell-builtin by bash itself ("type [ =>
> shell builtin"), I wondered "can't it detect it then just the same?"

Not by the current syntax definition of the shell. As the shell must be
able to disable a "builtin" command, and use the external in it's place,
the builtin command must accept the same arguments in the same form as
the external command. That implies that the shell must treat the arguments
of a builtin command in the same way it would treat the arguments of
an external command, and that includes $ expansion.

> There seems to be a difference between shell-keywords here and
> shell-builtins when it comes to the handling of empty variables.
>
> (Of course there is also /usr/bin/[ and /usr/bin/test (2 different
> programs on my Opensuse)

Although, they /don't/ have to be different programs. Historically,
the [ command was just an alias (a hardlink or softlink) of the test
command. I don't know why that changed.

> but I suppose that these are not called when "[" is a shell-builtin.

You can disable the [ builtin using the "enable" builtin ("enable -n [")
and then your script will search for and call the external [ command.

HTH
--
Lew Pitcher
"In Skills, We Trust"

On Tue, 18 Oct 2022 14:17:46 +0000, Lew Pitcher wrote:

> On Tue, 18 Oct 2022 15:01:01 +0200, Ralf Fassel wrote:
[snip]
>> (Of course there is also /usr/bin/[ and /usr/bin/test (2 different
>> programs on my Opensuse)
>
> Although, they /don't/ have to be different programs. Historically,
> the [ command was just an alias (a hardlink or softlink) of the test
> command. I don't know why that changed.

The question intrigued me, so I checked the source for the /bin/test
on my Slackware installation. It appears that, for the GNU CoreUtils
version of test, GNU took "the long way around" in it's error reporting.

Specifically, the source includes conditional compilation logic to
report name of the binary based on a value passed in at compilation time.
So, the compilation of test.c produces one of two slightly different
binaries (only the embedded program name changes), depending on whether
the compile includes a -DLBRACKET=1 or not.

The "classic Unix" way to determine the binary's name was to check or
report the contents of argv[0], with no difference in the binaries of
/bin/test and /bin/[ .

[snip]
--
Lew Pitcher
"In Skills, We Trust"

* Lew Pitcher <lew.pitcher@digitalfreehold.ca>
| > But the original theory (first quotation above) why [[ did not throw an
| > error was that "... ([[) is explicitly a shell built-in, so it can
| > recognize empty strings without help."
>
| [[ is not a "shell builtin", it is a "shell keyword". That makes a
| difference.
--<snip-snip>--

Thanks, very informative!

R'

In comp.os.linux.misc, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> The question intrigued me, so I checked the source for the /bin/test
> on my Slackware installation. It appears that, for the GNU CoreUtils
> version of test, GNU took "the long way around" in it's error reporting.
>
> Specifically, the source includes conditional compilation logic to
> report name of the binary based on a value passed in at compilation time.

Time was when many non-Linux systems used to have Gnu utilities
installed with different filenames, typically adding a 'g' to the front.

On this NetBSD box I'm using, for example:

$ ls --version
ls: unknown option -- -
usage: ls [-1AaBbCcdFfghikLlMmnOoPpqRrSsTtuWwXx] [file ...]

$ gls --version 2>&1
ls (GNU coreutils) 9.0
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard M. Stallman and David MacKenzie.

I expect the compiled in name is relevant to that. Not sure how test
uses it though.

$ cp $(which gtest) /tmp/gnutest
$ /tmp/gnutest x =
gnutest: missing argument after '='

Elijah
------
gcc is called that because the vendor cc was likely different

Ralf Fassel <ralfixx@gmx.de> wrote:
> * Barry Stir <scooter@mealteam6.mil>
> | I see various formats, such as
> | if [[ -L ${LINK1_DIR} ]]; then
>>
> | if [[ -L "$LINK1_DIR" ]]; then
>>
> | rather than just $LINK1_DIR
> | I presume this is insurance to ensure script works in every version of
> | Red Hat, Debian, Arch whatever...
>
> Using "" also works if the variable is not set or empty, otherwise you
> get a syntax error in that case.

Not with [[:
~$ unset x
~$ [[ -L $x ]] || echo false
false
But it's still a good idea to quote variables unless you explicitely
need the unquoted behaviour, like path expansion.

>
> Usually you need {} only when additional text should be appended to the
> contents: ${LINK1_DIR}X (because without the {} the variable name would
> be LINK1_DIRX).
>
> | So which is the ideal extra character to put around the environment
> | variable?
>
> It depends :-)
>
> "" also prevents file name globbing from happening, which might
> or might not be what one wants.
>
> $ touch foo1 foo2
> $ a=foo\*
> $ echo $a
> foo1 foo2
> $ echo "$a"
> foo*
>
> R'