balupton's questions

Dado o seguinte código:

out="$(mktemp)"
rm -f "$out"
clear

printf '%s\n' 0 >"$out"
{
    printf '%s\n' '1' >/dev/stdout
    printf '%s\n' '2' >/dev/stdout
} >"$out"
cat -e -- "$out"
rm -f "$out"

No Ubuntu isso produz:

2$

No MacOS isso gera:

1$
2$

Ao anexar explicitamente, eles se comportam de forma consistente:

out="$(mktemp)"
rm -f "$out"
clear

printf '%s\n' 0 >"$out"
{
    printf '%s\n' '1' >/dev/stdout
    printf '%s\n' '2' >>/dev/stdout
} >"$out"
cat -e -- "$out"
rm -f "$out"

No MacOS e no Ubuntu isso gera:

1$
2$

O exemplo mais confuso para mim é este:

out="$(mktemp)"
rm -f "$out"
clear

printf '%s\n' 0 >"$out"
exec 3>>"$out"
{
    printf '%s\n' '1' >/dev/stdout
    printf '%s\n' '2' >/dev/stdout
} >&3
{
    printf '%s\n' '3' >/dev/stdout
    printf '%s\n' '4' >/dev/stdout
} >&3
cat -e -- "$out"
rm -f "$out"
exec 3>&-

Que no MacOS gera:

0$
1$
2$
3$
4$

Que no Ubuntu gera:

4$

Eu esperava isso no Ubuntu:

0$
2$
4$

Estou completamente confuso sobre o porquê desse comportamento ocorrer neste exemplo e em todos os outros exemplos que criei para ilustrar essa discrepância.

Minhas perguntas:

• O que é essa discrepância? O que está acontecendo? Essa discrepância é intencional?
• Onde mais essa discrepância se aplica? Quais são suas origens?
• Se essa discrepância é intencional, por que foi justificada? Qual deveria ser o comportamento correto?
• O que pode ser feito para atenuar essas diferenças ao escrever scripts entre sistemas operacionais?
• É shopt -o noclobbera resposta apropriada? É essa a verdadeira necessidade de noclobber?

O seguinte produz uma bash: test: too many argumentsexceção em test, com status de saída 2:

v='>'
test -n "$v" -a yes '!=' no # bash: test: too many arguments
echo $? # 2

test -n '>' -a 1 -eq 1 # bash: test: too many arguments
echo $? # 2

[ -n '>' -a 1 -eq 1 ] # bash: [: too many arguments
echo $? # 2

[[ -n '>' -a 1 -eq 1 ]]
# bash: syntax error in conditional expression
# bash: syntax error near `-a'
echo $? # 2

Ele funciona sem o -a e, como tal, funciona usando && em vez do -a:

v='>'
test -n "$v"
echo $? # 0

[ -n "$v" ]
echo $? # 0

test -n "$v" && test yes '!=' no
echo $? # 0

[ -n "$v" ] && [ yes '!=' no ]
echo $? # 0

Não há menção a esse comportamento peculiar na documentação: https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html#index-test

Versões conhecidas afetadas: GNU bash, versão 5.2.37(1)-release (x86_64-apple-darwin22.6.0) GNU bash, versão 3.2.57(1)-release (x86_64-apple-darwin22)

Se esse for o comportamento pretendido, qual é a solução alternativa adequada?

1. Devo sempre usar &&em vez de -a?
2. Devo usar uma substituição de parâmetro? por exemplotest -n "${v//>/.}" -a 1 -eq 1
3. Existe alguma outra sugestão?

Ao instalar o Visual Studio Code via apt ou homebrew, o codeexecutável VSCode vai para um local padrão que está dentro de PATH, porém parece que ao instalar o VSCode via Flatpak, ele vai para algum lugar especial. Estou tentando encontrar esse local para poder adicioná-lo ao meu arquivo PATH.

Eu gostaria de ter um arquivo no meu computador que armazena um token específico (em vez de exportá-los para o shell env). Como tal, gostaria que o token só pudesse ser lido por sudo, portanto, o acesso a ele requer autorização. Como posso escrever um arquivo que só pode ser lido pelo sudo?