Yes, it works like that, $(...) captures everything that was written to STDOUT.

Now I guess that the "... to STDOUT"-part is news to you. Usually, three channels are associated with each process:

• STDIN (0): Standard input. Unless told otherwise, most programs read from this channel.
  
• STDOUT (1): Standard output. That's where regular output ends up.
  
• STDERR (2): Standard error. This channel is meant for error messages or diagnostics.
  

These channels are not as special as you might think. They're just normal file descriptors. When a process opens another file, it gets file descriptor 3 and so on.

When you use a pipe, you connect STDOUT of the first program with STDIN of the second one: "ls -al | grep foo".

You can choose the desired channel in your script, like this:

You'll see that the first two strings get written to the terminal directly (because they're written to STDERR), whereas the last string is written to STDOUT and thus ends up as your "return value".

Look up "standard streams" and "shell redirection" to learn more.

(Kind of a philosophical issue: Usually, a tool wouldn't print anything unless there's something important to say. There should be a verbose switch "-v", which the user can use to find out exactly what's going on.)