Hello,

I found a code where all variables a set by the following way:

VAR=""`ls -1`

Why "" put before the command?

Only the person who wrote it can say.

It is mostly harmless, perhaps they intended to prepend a title or something in the quotes.

There is no programmatic reason for doing so that I know of.

n/m

the "" tells bash that what is inside is NOT TO BE EXPANDED


ALWAYS use quotes for strings and assignments unless your seeking planned flawless command substitution

see man bash(1) about expansion rules

consider:

VAR=`ls -1`

ls -1 may product "filenames with spaces" then you'd have

VAR=foo foo2

that's illegal, bash complains (if set -e is used, bash quits, see man bash(1))

now it's also possible a filename contains bad things like ! (exclamation mark, which bash thinks is special)

VAR=!foo

a disaster may happen

filename may contain $ and if name is $x

VAR=$x

VAR becomes the value of variable x - defintely not a good idea

VAR="$x" becomes variable x, yes, but bash does not apply commandline expantion to it, which can be a disaster. "$x" tells bash only certain expansions are allowed.

$ VAR=$x
$ VAR="$x"

AGAIN, may be the same: but may be disasterous without ""

VAR=`echo foo | tr -c "o" "i"` is a shortcut and often VAR=`ls` is shown in EXAMPLE scripts which omit "better practices" so to look thinner and be more clear. it's a shortcut but dont do it.

do you know if there are macros define in the envrionment that may be triggered? did you run the shell script in it's own invironment? did it inheirit what macro or global environment ? there are many more questions to ask about unquoted "full bash commandline substitution process" before running around without quotes

------------------------
there are too many more thigs that can go bad or really bad

in general:

ALWAYS use quotes for strings and assignments unless your seeking command substitution

glob * expands to '*' not '' if nothing is found, so be careful

even turning off globs is a safe practice

btw: this is valid in bash. in your example you didnt' show the ending quote.

that's either just a typo or intended to have an "embedded \n" (embedded line feed, see man bash)

$ VAR="hi" ; echo "$VAR"
hi
$ VAR="`ls -1`

hello

"

$ echo $VAR
file1 file2

hello

----------------
do you see the vertical whitespace ?

I think the empty string before the backtics was a mistake and nothing more.

A better and safer way to write it would be:

No

No

No




All the above are wrong.
It is completely unnecessary to stick quotes around command substitutions. Not only that, but the OP's example didn't even have quotes around the command substitution, it had quotes IN FRONT OF it, which is nothing more than a harmless typo.

Also...

No it doesn't, you need single quotes for that.

Please provide a single example where this is true.