There's nothing wrong with that syntax. Within that command substitution, the use of single or double quotes is nothing special, even if the command substitution itself is double quoted. The only effect of double-quoting an entire subsitution is that the result of the command is protected from field-splitting and filename globbing (neither of which would happen here anyway, since operations that may yield multiple fields are not performed when assigning to a variable).

From POSIX: Shell Command Language:
The same cannot be said of the older though still widely-used backtick style, ` ... `. In my opinion, that is a very persuasive reason to never use it. The backtick version can get hairy, particularly with nesting or quoting or, or (I hesitate to even contemplate the possibility) nested quoting.

Regards,
Alister

---------- Post updated at 11:49 AM ---------- Previous update was at 11:33 AM ----------

The error is occurring because the pipe character in $comm is not treated specially. The shell command parsing step which interprets the pipe symbol as a special character has completed by the time the shell expands the variable containinig the pipe. For your approach to work, you'd need to use eval to pass the value of $comm (or $both, in your second example) through the shell parser. This has security implications, so if you are not familiar with eval, you should do some research.

Nothing that you've mentioned suggests you need to resort to eval. Aside from security issues, it can be a pain to protect metacharacters from the effects of going through the shell parser more than once. It would be simpler and much more secure and robust to simply parameterize your script so that the grep pattern can be a simple argument.

Regards,
Alister