Re: [EXT]Re: Suddenly, periods / dots in variable values are converted to space

[Kerin Millar]

On Tue, 24 Jan 2023 21:50:59 -0700
Chandler <admin@genome.arizona.edu> wrote:

> I'm certain it was not independent, but it was doing something to remove the 
> dots from ${HOSTNAME} variable I think, like:
>    IFS=. ${HOSTNAME##...}
> 
> if that makes any difference?  (can't remember what was in the ...)

It might have been such. Variable assignments will persist unless they are 
identified as being part of a simple command. Consider the following.

$ hostname=" "
$ IFS=. "${hostname}"
bash:  : command not found
$ declare -p IFS
declare -- IFS=$' \t\n'

Note that the parameter expansion is quoted. Consequently, the resulting word 
is protected against word splitting, leaving an identifiable simple command 
whose name is a single space character. Bash attempts to resolve this command 
by its name and fails, because I happen to have no executable by that name in 
PATH. Had it succeeded, " " would have been executed with the value of IFS set 
to "." in its environment. However, the value of IFS would still have been 
restored afterwards.

Now, consider what happens in the absence of quotes.

$ declare -p IFS
declare -- IFS=$' \t\n'
$ IFS=. ${hostname}
$ declare -p IFS
declare -- IFS="."

The word that is the expansion of the hostname variable is subjected to a round 
of word splitting. Because IFS contains the space character, the original word 
is elided. From the perspective of the parser, all that is left is an ordinary 
variable assignment that is not part of a simple command. Therefore, the value 
of IFS is (unintentionally) altered. The issue would be much the same in the 
case that the word produced by the initial parameter expansion is the empty 
string. From this, we may conclude that parameter expansions should always be 
quoted, unless the effects of not doing so are both fully understood and 
considered as being appropriate for the task at hand.

-- 
Kerin Millar