TheDudeAbides's questions

Conforme claramente explicado na documentação do Bash sobre aritmética do shell , se você prefixar um número com a 0dentro de uma expressão de expansão aritmética ( por exemplo , $(( expr ))), ele será tratado como octal. Da mesma forma, você pode usar b#npara um número nem base b.

No entanto, independentemente da base usada para a aritmética dentro da expressão, o valor é sempre retornado como base 10. Como faço para retornar octal do resultado de uma expansão aritmética?

Meu caso de uso original para isso foi avisar um usuário de que as permissões em seu sistema ~/.my.cnferam muito frouxas (legíveis em grupo ou em todo o mundo) juntando os bits de permissão do arquivo com uma máscara de bits, mas depois decidi que testar a saída de find ~/.my.cnf -perm +0044é provavelmente mais limpo e mais portátil, já statque as strings de formato não são padrão entre macOS/BSD e Linux. Ainda assim, a questão permanece.

Eu tenho um arquivo delimitado por tabulação onde uma das colunas está no formato "LastName, FirstName". O que eu quero fazer é dividir esse registro em duas colunas separadas, last, and first, use cutou algum outro verbo(s) nesse , e gerar o resultado em JSON.

Devo acrescentar que não sou casado com JSON e sei usar outras ferramentas como jq, mas seria bom obtê-lo nesse formato em uma etapa.

A sintaxe do nestverbo parece exigir a memorização de muitas opções francamente não memoráveis, então imaginei que haveria uma operação DSL simples para fazer esse trabalho. Talvez não seja o caso?

Aqui está o que eu tentei. (Vamos esquecer o espaço extra que está anexado Firstnameagora, OK? Eu usaria stripou ssubalgo para me livrar disso mais tarde.)

echo -e "last_first\nLastName, Firstname" \
  | mlr --t2j put '$o=splitnv($last_first,",")'

# result:
# { "last_first": "LastName, Firstname", "o": "(error)" }

# expected something like:
# { "last_first": "LastName, Firstname", "o": { 1: "LastName", 2: "Firstname" } }
#
# or:
# { "last_first": "LastName, Firstname", "o": [ "LastName", "Firstname" ] }

Por quê (error)? Não é razoável que atribuir $ocomo acima atribuiria uma nova coluna oao resultado de splitnv?

Aqui está outra coisa que tentei que não funcionou como eu esperava:

echo -e "last_first\nLastName, Firstname" \
  | mlr -T nest --explode --values --across-fields --nested-fs , -f last_first

# result (no delimiter here, just one field, confirmed w/ 'cat -A')
# last_first
# LastName, Firstname

# expected:
# last_first_1<tab>last_first_2
# LastName,<tab> Firstname

Edit : O problema com o comando acima é que eu deveria ter usado --tsv, não -T , que é sinônimo de --nidx --fs tab(colunas indexadas numericamente). O problema é que o Miller não produz uma mensagem de erro quando é obviamente errado pedir colunas nomeadas nesse caso, o que pode ser um recurso incorreto; veja a edição #233 .

Qualquer insight seria apreciado.

Eu trabalho em um ambiente relativamente heterogêneo onde posso estar executando diferentes versões do Bash em diferentes nós HPC, VMs ou minha estação de trabalho pessoal. Como coloquei meus scripts de login em um repositório Git, gostaria de usar o mesmo (ish) .bashrcem geral, sem muita bagunça do tipo "se este host, então...".

Eu gosto do comportamento padrão do Bash ≤ 4.1 que se expande cd $SOMEPATHao cd /the/actual/pathpressionar a Tabtecla. No Bash 4.2 e acima, você precisaria shopt -s direxpandreativar esse comportamento, e isso não ficou disponível até 4.2.29 . Este é apenas um exemplo; shoptoutra opção possivelmente relacionada complete_fullquote(embora eu não saiba exatamente o que ela faz) também pode ter alterado o comportamento padrão na v4.2.

No entanto, direxpandnão é reconhecido por versões anteriores do Bash e, se eu tentar shopt -s direxpandno meu .bashrc, isso resultará em uma mensagem de erro sendo impressa no console toda vez que eu efetuar login em um nó com um Bash mais antigo:

-bash: shopt: direxpand: invalid shell option name

O que eu gostaria de fazer é envolver uma condicional shop -s direxpandpara habilitar essa opção no Bash > 4.1 de maneira robusta, sem irritar as versões mais antigas do Bash ( ou seja , não apenas redirecionar a saída de erro para /dev/null).