Se você tem my_command assim:
#!/bin/sh
echo 'VAR1=some_value'
echo 'VAR2=other_value'
executá-lo obviamente imprime
VAR1=some_value
VAR2=other_value
Agora, source my_command irá executar o script, no shell atual, que produzirá as atribuições como saída. Você usaria source se my_command não imprimisse as atribuições, mas fosse executado diretamente.
export $(my_command) irá pegar a saída do script, e passá-lo para exportar, o que colocará as variáveis no ambiente atual do shell, mas ele só funcionará enquanto as variáveis em questão don não contém espaços em branco ou caracteres glob, pois a substituição do comando não é citada. Colocar "$(my_command)" entre aspas realmente não ajuda, porque, em seguida, export vê VAR1=some_value\nVAR2=other_value como um argumento e apenas VAR1 está definido.
Note que executar export $(my_command) ou definir variáveis de qualquer outra forma dentro de outro script não irá definir aquelas variáveis no shell pai. Se você quiser as atribuições no seu shell interativo, você deve executá-las lá, mas você pode envolver as atribuições em uma função ou source um script que faz as atribuições.
Uma solução óbvia seria fazer o que o ssh-agent faz e ter os comandos export de saída do script para as variáveis que ele define. Então seria o suficiente para executar eval "$(my_command)" .
Se não quisermos fazer isso, podemos usar set -a antes do script para que o shell exporte automaticamente quaisquer variáveis que estejam configuradas.
Então,
$ set -a
$ eval "$(my_command)"
No Bash, podemos usar declare -p para verificar se as variáveis são exportadas ( -x ):
$ declare -p VAR1 VAR2
declare -x VAR1="some_value"
declare -x VAR2="other_value"
Usar eval aqui permitirá que o script produza strings citadas como VAR1="foo bar" e elas serão tratadas corretamente. eval também executará qualquer outra coisa do script my_command de saídas, não apenas atribuições, mas se você não confiar em my_command , não deverá executá-lo.