Assignment in bash

[belier26]

The following goes without error:

file="$HOME/xxx.log"

but adding a blank after the assignment glyph (often called "equal sign")

file= "$HOME/xxx.log"

produces one of two errors according to the existence or not of the file.
In particular, if the file exists, a permission refusal is reported.

Why isn't bash smart enough to ignore this blank?
After all, the tokens are exactly the same. Does bash interpret = as the equality relation?

[guus.leeuw.jr]

Belier,

the tokens are not the same!
Whitespace in this case is assigned the NULL value, which in turn is assigned to file. The second part of your command is then executed with $file set to NULL in its environment.
You'll see this type of env passing often written down as
$ file= \
> "$HOME/xxx.log"
to indicate that file (in the env for program $HOME/xxx.log) should be NULL.
bash is smart enough to let you pass environment variables only to upcoming programs in this way. The other way would be
$ export file=blablah
$ program
$ unset file
which is far too many keystrokes for it to be a valid Un*x/Lin*x command sequence

Guus

[drl]

Hi.

As Steve Bourne says in an interview:

... the shell is a string processing language and the string processing is fairly simple ...

-- The A-Z of Programming Languages: Bourne shell, or sh - a-z of programming languages - Computerworld

The basic idea of this string processing language is that a series of white-space-separated strings is provided to the shell, and an action -- an interpretation -- is performed. A feature, as guus.leeuw.jr wrote above, is that (additional, specific) context may be passed along to commands with assignment statements.

The interview is useful for anyone interested in the design decisions of the Bourne shell.

An interview with David Korn, ksh, is at Slashdot | David Korn Tells All

See also articles in Wikipedia, such as (the link in) http://en.wikipedia.org/wiki/Shell_(computing) for links to additional information... cheers, drl