Como posso atribuir um heredoc a uma variável de forma que seja portátil entre Unix e Mac?

Esse bug específico do bash foi corrigido no 4.0, lançado há mais de 15 anos, mas o macOS ainda fornece uma versão 3.2.x. Como a Apple aparentemente não atualizará seu bash(e seu shque AFAIK ainda é baseado em bash), eu sugiro que você relate o bug a eles para que eles façam backport de uma correção para sua versão.

Parece que isso afeta os here-documents usados ​​dentro da substituição de comando, então você pode mover o here-doc para fora da substituição de comando com:

#!/usr/bin/env bash
{
  foo=$(cat)
} <<'EOF'
"\[^"\]+"
EOF
printf %s "$foo"

ou usando uma função auxiliar:

#!/usr/bin/env bash
helper() {
  cat <<'EOF'
"\[^"\]+"
EOF
}
foo=$(helper)
printf %s "$foo"

Ou uma mais útil:

#! /usr/bin/env bash
readvar() {
  eval "$1=\$(cat)"
}
readvar foo << 'EOF'
"\[^"\]+"
EOF
printf %s "$foo"

(acima também usando 'EOF'instead of, EOFpois o último faz expansões e implica em tratamento extra de barra invertida).

Ou adie a interpretação do here-doc usando eval:

#!/usr/bin/env bash
foo=$(eval 'cat <<EOF
"\[^"\]+"
EOF')
printf %s "$foo"

Embora eu suspeite que você esteja usando here-docs em primeiro lugar para evitar ter que se preocupar com aninhamento de citações, isso eval '...'provavelmente não ajudará.

Uma nota sobre terminologia:

• Mac se refere a uma linha de hardware de computador da Apple de diferentes arquiteturas (algumas das quais baseadas em PC) que podem executar uma variedade de sistemas operacionais Unix-like ou não-Unix-like, embora venham pré-instalados com o Apple macos (anteriormente conhecido como OS/X, MacOS/X). Então dificilmente é relevante.
• Unix é uma família de sistemas operacionais que remonta ao Unix OS original, desenvolvido nos laboratórios Bell na década de 70, à qual pertencem o macOS e a maioria dos sistemas operacionais genéricos baseados em GNU/Linux.
• O Linux é o kernel encontrado no núcleo de milhares de sistemas operacionais diferentes, alguns (a maioria) semelhantes ao Unix, outros não.
• bash é o shell do projeto GNU, é principalmente um clone parcial livre e de código aberto do shell Korn (que era de código fechado até por volta de 2000), lançado pela primeira vez em 1989 (portanto, é anterior ao Linux e ao MacOS/X) e pode ser construído para a maioria, se não todos os sistemas do tipo Unix e vários outros não-Unix. Ele é pré-instalado em sistemas GNU, vários sistemas não baseados em GNU Linux e alguns sistemas não-GNU não-Linux, como o macOS, embora lá, seja uma versão muito antiga pré-GPL3.

Aqui, o problema é apenas sobre a versão do bash. Você encontraria o mesmo bug em qualquer sistema anterior a 2009 que tivesse o bash incluído.

Não está claro para mim por que você precisa de um heredoc:

foo='"\[^"\]+"'

deve funcionar no bash no Linux e no macOS.

Se você quiser uma string com várias linhas, declare-a entre aspas em várias linhas:

foo='a
multi-line
string'

Fornecendo isso como uma resposta aqui para fornecer completude, já que todas as respostas contêm as respostas corretas. Isso apenas adiciona outra opção "correta" para o OP.

Um pouco de história

Darwin , baseado no BSD, e o núcleo do MacOS era livre e OpenSource até o Darwin8. O Darwin8 ainda está disponível e lhe dará um OSX 10.4 muito básico. Não haverá GUI nessa instalação. Depois do Darwin8, a Apple escolheu tornar o SO de código fechado. É também este Darwin8 que contém a última versão GPL do BASH da Apple - 3.2.x, razão pela qual nenhum usuário verá uma versão nativa do Apple BASH superior a 3.2.x

A Apple usou os objetos gráficos do NeXTStep e do Darwin8 acima para formar a base de todos os OSX modernos desde 10.4 e o código-fonte permanece fechado com bits e partes compartilhadas no site do desenvolvedor da Apple . O Darwin, sem o Apple anexado, ainda pode ser usado e visto hoje em projetos como o PureDarwin . Observe que ainda não há uma GUI nativa do tipo NeXTStep aqui ou qualquer GUI nativa, mas o sistema executará desktops como o XFCE usando o MacPorts . O Homebrew, discutido abaixo, é um gerenciador de pacotes que é usado principalmente para substituir as versões Apple/Darwin de programas e bibliotecas com suas contrapartes Linux (sem remover as versões fornecidas pela Apple). O MacPorts funciona da mesma forma, mas contém não apenas binários Linux, mas também aplicativos gráficos.

A questão

Com o pequeno histórico fora do caminho, Multiple Sites centra-se no fato de que a Apple violaria a licença GPLv3 se o BASH fosse atualizado além da versão em Darwin8. Relatar o bug pode não adiantar, pois a correção precisaria ser retroportada para continuar evitando a violação. Se a correção foi incluída no BASH4 como a resposta de Stephane declarou, a Apple agora se colocou em um problema de catch-22/ovo e galinha. Para atualizar o BASH para uma versão maior que 3.2, todo o código-fonte (incluindo o código NeXTStep de código fechado) precisaria ser relançado, o que satisfaria a licença GPL. A Apple não quer que o público veja esse código. Veja Sarcasmo abaixo para minha opinião pessoal sobre o porquê.

Comece o Sarcasmo

BTW, eu coloquei isso aqui, e eu tenho um Macbook Pro (Intel de última geração), então até eu me apaixonei pela GUI bacana e pela cor brilhante. Eu também tenho uma torre de jogos, um Toshiba Satellite barato, um Raspberry Pi4, um iPad e um telefone baseado em Android, então, por favor, mantenha os comentários de fanboys da Apple fora da seção de comentários.

Vamos encarar, metade (se não mais) dos clientes que compram um Mac o compram porque o exterior é brilhante e a GUI é intuitiva e bem projetada, em outras palavras, a "beleza simplista" da GUI e as cores brilhantes do case são parte do motivo pelo qual comprar um Mac é um empreendimento lucrativo para a Apple. Como tal, a Apple nunca reabrirá nenhum código-fonte.

Um cliente que usa cores brilhantes e interfaces gráficas de usuário (GUIs) atraentes para julgar o valor do seu computador não vai se importar se sua versão do BASH estiver 18 anos desatualizada .

Fim do Sarcasmo

A resposta principal no resultado da pesquisa vinculado anteriormente contém o seguinte:

A Apple usa uma versão antiga do Bash 3.2.57 lançada inicialmente em 2006 e, devido ao licenciamento GPL3 da GNU, a Apple não instalará uma versão mais recente do Bash (por exemplo, 5.2) que esteja instalada na maioria dos sistemas Linux. Em vez disso, a Apple está comprometida em fornecer o shell Zsh, que tem uma licença MIT. Aprender o shell Zsh seria mais estratégico para você em lançamentos futuros do macOS.

Comprometido em fornecer o Zsh Shell é apenas uma maneira elegante de dizer que temos muitos advogados que nos dizem que violar a GPL seria ruim, então vamos encontrar uma substituição viável com uma licença que não seja GPLv3. O ZSH é essa substituição adequada.

Minha solução

Usuários do sistema Apple não se importam em simplesmente trocar os interpretadores de terminal, mas como usuário de ambos os sistemas (PC e Mac), descobri que instalar a versão Homebrew do BASH corrige a decisão de design escolhida pela Apple.

1. Instalar o Homebrew .
2. Use Como alterar versões do bash no Mac com o Homebrew ou similar para instalar uma versão atualizada do BASH. Basta procurar por Instalar ou Atualizar o BASH no MacOS X

Fazer isso agora torna os scripts BASH compatíveis entre quase todas as distribuições Linux e um Mac e, se desejado, fornece aos usuários uma maneira de continuar usando um shell BASH ao qual estão acostumados.

Desvantagem

Se os usuários precisam de portabilidade (ir de um Mac para outro), e não de compatibilidade, a abordagem acima é desencorajada. No caso da portabilidade, temos 2 opções:

1. Aprenda ZSH - A maioria dos criadores de scripts para Mac adota essa abordagem e depois faz o oposto acima e altera o shell padrão no Linux para ZSH, o que é muito mais fácil no caso do Linux do que adicionar um novo BASH não nativo ao Mac.
2. Não faça nada e aprenda as esquisitices como o OP descobriu aqui e resolva-as uma de cada vez, mantendo um arquivo para referência futura.

Uma abordagem sem substituição de comando que funciona nos bashes mais antigos que tenho (não chegando ao 3.2):

$ read -r -d '' VAR <<'EOF'
multiline data that can include
all kind " ' of quotes or anything 
including \ backslash or $dollar
EOF
$