Corte de linhas no Bash

Question

Suponha que eu tenha uma string na minha variável como segue.

var="/fnxn/ngfdg/abc.ext"

Eu posso pegar a raiz desta variável (remover extensão. *) como segue

echo ${var%.*}

Eu posso pegar a cauda desta variável (removendo o caminho * /) como segue

echo ${var##*/}

Mas agora tenho que remover o caminho e a extensão. Eu posso fazer isso em duas etapas usando outra variável da seguinte forma.

var2=${var##*/}
var3=${var2%.*}

Mas a opção de etapa única (semelhante à sintaxe zsh abaixo) mostra uma mensagem de erro "substituição ruim" no bash.

echo ${${var##*/}%.*}

Seria útil se eu conseguisse uma única opção compreensível para reduzir o tamanho do código e evitar uma variável de ambiente adicional.

    

Answer 1

Se você tem uma extensão fixa, POSIX basename suporta exatamente o recorte ' re tentando:

basename "$var" .ext

Se você não fizer isso, a expansão zsh suporta exatamente o que você ' está tentando:

If a ${...} type parameter expression or a $(...) type command substitution is used in place of name above, it is expanded first and the result is used as if it were the value of name. Thus it is possible to perform nested operations: ${${foo#head}%tail} substitutes the value of $foo with both ‘head’ and ‘tail’ deleted.

Então, em zsh

echo ${${var##*/}%.*}

fará o que você esperava.

Se você estiver comprometido com o Bash e quiser salvar linhas, poderá usar o sed:

sed -e 's/\.[^.]*$//' <<<"${var##*/}"

Isso é apenas uma substituição de expressão regular de tudo após o último . com nada, depois de perder o prefixo da mesma forma que você está agora. Eu não vejo isso particularmente salvando memória sobre a versão de duas linhas, no entanto, e é provavelmente menos compreensível também.

Note que não há motivo para você não usar a mesma variável durante o processo:

var2=${var##*/}
var2=${var2%.*}

A expansão acontece antes da atribuição, portanto, isso é seguro. Se a sua preocupação é que um nome de arquivo muito longo seja armazenado duas vezes, isso não acontecerá agora, mas não acho que seja um problema realista.