Capturar e coletar a saída do script, erro "arquivo de entrada é arquivo de saída"?

Com o exec, você está redirecionando toda a saída do script para um arquivo de log específico.

Em seu trap, você deseja exibir o conteúdo do arquivo de log usando cat. Como toda a saída também é redirecionada para esse arquivo, o GNU catpercebe que seu arquivo de entrada e fluxo de saída padrão (que é herdado do shell) são a mesma coisa e se recusa a realizar sua tarefa.

O BSD catnão faz a mesma verificação que o GNU cat, que, se o script não for interrompido, resulta em um arquivo de log infinitamente grande com as mesmas poucas linhas repetidas várias vezes.

Uma solução alternativa é salvar o descritor de arquivo de saída padrão original, fazer o redirecionamento como antes e restabelecê-lo no trap.

#!/bin/bash

exec 3>&1                  # make fd 3 copy of original fd 1
exec >/tmp/error.log 2>&1

# in the trap, make fd 1 copy of fd 3 and close fd 3 (i.e. move fd 3 to fd 1)
trap 'exec 1>&3-; cat /tmp/error.log; curl "http://127.0.0.1/error.php?hostname=$(hostname)" -F file=@/tmp/error.log' EXIT

set -ex
wtfwtf

Isso faz uma cópia do descritor de arquivo 1 (como fd 3) antes de redirecioná-lo para o arquivo de log. Na armadilha, movemos essa cópia de volta para fd 1 e fazemos a saída.

Observe que o fluxo de erro padrão, no trap, neste exemplo, ainda está conectado ao arquivo de log. Portanto, se curlgerar uma mensagem de diagnóstico, ela será salva no arquivo de log em vez de ser exibida no terminal (ou onde quer que o fluxo de erro padrão original tenha sido conectado).

Tendo em conta o comentário de Stéphane Chazelas :

#!/bin/sh

exit_handler () {
    # 1. Make standard output be the original standard error
    #    (by using fd 3, which is a copy of original fd 2)
    # 2. Do the same with standard error
    # 3. Close fd 3.
    exec >&3 2>&3 3>&-
    cat "$logfile"
    curl "some URL" -F "file=@$logfile"
}

logfile='/var/log/myscript.log'

# Truncate the logfile.
: >"$logfile"

# 1. Make fd 3 a copy of standard error (fd 2)
# 2. Redirect original standard output to the logfile (appending)
# 3. Redirect original standard error to the logfile (will also append)
exec 3>&2 >>"$logfile" 2>&1

# Use shell function for exit trap (for neatness)
trap exit_handler EXIT

set -ex
wtfwtf

Seu ponto é que o arquivo de log é apenas para mensagens de diagnóstico de qualquer maneira, então faz mais sentido enviar o arquivo de log para o fluxo de erro padrão original.

Ele também aponta que é perigoso usar um nome de arquivo fixo em um diretório gravável como /tmp. Isso ocorre porque nenhuma verificação é colocada no script para garantir que esse arquivo ainda não exista (alguém ou algum malware pode ter criado um /tmp/error.loglink simbólico para /etc/passwdvocê ~/.bashrc, por exemplo). Sua solução para isso é usar um arquivo de log persistente dedicado para o script em /var/logvez disso (o arquivo é persistente, mas o conteúdo será limpo ao executar o script).

Uma variação disso seria usar mktemppara criar um nome de arquivo exclusivo em $TMPDIR(e, em seguida, remover esse arquivo na EXITarmadilha, a menos que falhe, curlcaso em que rmnão seria executado, pois set -eestá em vigor):

#!/bin/sh

exit_handler () {
    # 1. Make standard output be the original standard error
    #    (by using fd 3, which is a copy of original fd 2)
    # 2. Do the same with standard error
    # 3. Close fd 3.
    exec >&3 2>&3 3>&-
    cat "$logfile"
    curl "some URL" -F "file=@$logfile"
    rm -f "$logfile"
}

logfile=$( mktemp )

# 1. Make fd 3 a copy of standard error (fd 2)
# 2. Redirect original standard output to the logfile (appending)
# 3. Redirect original standard error to the logfile (will also append)
exec 3>&2 >>"$logfile" 2>&1

# Use shell function for exit trap (for neatness)
trap exit_handler EXIT

set -ex
wtfwtf

Seu segundo exemplo funciona, mas apenas porque você não está usando catno arquivo de log, não por copiá-lo.

Pequeno detalhe: URLs na linha de comando provavelmente devem estar sempre entre aspas duplas, pois tendem a conter caracteres que o shell pode interpretar como especiais (por exemplo ?).