1

I saw codes like this:

fqdn='computer1.daveeddy.com'

IFS=. read hostname domain tld <<< "$fqdn"
echo "$hostname is in $domain.$tld"
# => "computer1 is in daveeddy.com"

I think it works because IFS is assigned to . in the third line.. So I tried this:

x=100  echo $x

but found the bash doesn't print anything, while I expect it will print 100..

Moreover, I found x=100 echo $x; echo $x print nothing, while x=100; echo $x prints 100, which is very confusing.

Does anyone have ideas about this?

Hanfei Sun
  • 45,281
  • 39
  • 129
  • 237

2 Answers2

5

The $x is expanded before echo runs, and the result is passed to echo as an argument. echo does not use the value of x in its environment.

In the first example, read uses the value of IFS in its environment to split the string it receives via the here string.

chepner
  • 497,756
  • 71
  • 530
  • 681
  • 1
    thanks, but why `x=100 echo $x; echo $x` print nothing, while `x=100; echo $x` prints `100`? – Hanfei Sun Apr 07 '15 at 04:54
  • Because you are declaring the value of x as "100 echo $x" - which is not the same as "100". In this case you are referring to x before it can declare x, and therefore is null. The semicolon tells the shell to consider the command as multiple commands rather than one. It splits the command just like if you had placed them on separate lines. – asimovwasright Apr 07 '15 at 07:43
  • 1
    @asimovwasright No, he's *not* assigning `100 echo $x` to the value of `x`. His first example simply has two separate `echo` commands, both of which are executed in an environment where `x` has no value. The pre-command modifier in the first is simply not used by `echo`. The second example has a regular assignment that sets the shell variable `x` to 100 before the next command prints that value. – chepner Apr 07 '15 at 12:01
  • I see that the x is added to the env for the `x=100 echo $x` . Try `x=100 env` – Arun George May 02 '21 at 07:48
  • @ArunGeorge I should have been more precise: `$x` is *expanded* in an environment where `x` is undefined. Once the expansion happens, an environment where `x` equals `100` is created, but the environment isn't used. – chepner May 02 '21 at 12:31
-1

here is another way to think about it:

$ a="echo 100" $a

This is equal to:

$ a="echo 100"

Because at the time of scanning the line, $a is empty. Variable substition occurs first, so the $a just disappears.

Compare this to a very similar statment:

$ a="echo 100"; $a   # returns "100"
toppk
  • 696
  • 4
  • 10
  • Note that the second line is unnecesary. When `$a` expands to the empty string in the first line, the result is a valid assignment statement, not a pre-command modifier of a null statement, so the current shell now has a variable `a` whose value is `echo 100`. – chepner Apr 07 '15 at 12:03
  • @toppk What you're showcasing here is a very fragile practice -- it doesn't work with commands that are complex at all. See [BashFAQ #50: *I'm trying to put a command in a variable, but the complex cases always fail!*](http://mywiki.wooledge.org/BashFAQ/050) – Charles Duffy Apr 28 '19 at 16:37
  • @CharlesDuffy I wasn't recommending a scripting practice, but just trying to explain a shell concept. – toppk Dec 09 '19 at 17:50