shellcheck conseille de ne pas utiliser le nom de base: pourquoi?

J'essaie le shellcheck .

J'ai quelque chose comme ça

basename "${OPENSSL}" 

et je reçois la suggestion suivante

Use parameter expansion instead, such as ${var##*/}.

D'un point de vue pratique, je ne vois aucune différence

$ export OPENSSL=/opt/local/bin/openssl
$ basename ${OPENSSL}
openssl
$ echo ${OPENSSL##*/}
openssl

Puisque basenamec'est dans les spécifications POSIX , je n'ai aucune raison pour que ce soit la meilleure pratique. Un indice?

Ce n'est pas une question d'efficacité - c'est une question d'exactitude. basenameutilise des retours à la ligne pour délimiter les noms de fichiers imprimés. Dans le cas habituel, lorsque vous ne passez qu'un seul nom de fichier, il ajoute une nouvelle ligne de fin à sa sortie. Étant donné que les noms de fichiers peuvent contenir eux-mêmes des sauts de ligne, il est difficile de gérer correctement ces noms de fichiers.

Il est encore compliqué par le fait que les gens utilisent habituellement basenamecomme ceci: "$(basename "$file")". Cela rend les choses encore plus difficiles, car elles $(command)suppriment toutes les nouvelles lignes de fin command. Considérez le cas peu probable qui $filese termine par une nouvelle ligne. Ensuite , basenameajoutera une nouvelle ligne supplémentaire, mais "$(basename "$file")"dépouillera les deux nouvelles lignes, vous laissant avec un nom de fichier incorrect.

Un autre problème avec basenameest que si $filecommence par un -(tiret aka moins), il sera interprété comme une option. Celui-ci est facile à réparer:$(basename -- "$file")

La manière robuste d'utiliser basenameest la suivante:

# A file with three trailing newlines.
file=$'/tmp/evil\n\n\n'

# Add an 'x' so we can tell where $file's newlines end and basename's begin.
file_x="$(basename -- "$file"; printf x)"

# Strip off two trailing characters: the 'x' added by us and the newline added by basename. 
base="${file_x%??}"

Une alternative est d'utiliser ${file##*/}, qui est plus facile mais qui a ses propres bugs. En particulier, c'est faux dans les cas où $fileest /ou foo/.

Les lignes concernées shellcheckdu » code source sont:

checkNeedlessCommands (T_SimpleCommand id _ (w:_)) | w `isCommand` "dirname" =
    style id "Use parameter expansion instead, such as ${var%/*}."
checkNeedlessCommands (T_SimpleCommand id _ (w:_)) | w `isCommand` "basename" =
    style id "Use parameter expansion instead, such as ${var##*/}."
checkNeedlessCommands _ = return ()

Il n'y a aucune explication donnée explicitement mais basée sur le nom de la fonction ( checkNeedlessCommands) il semble que @jordanm soit tout à fait raison et cela vous suggère d'éviter de bifurquer un nouveau processus.

dirname, basename, readlinkEtc (merci @Marco - ceci est corrigé) peut créer des problèmes de portabilité lorsque la sécurité est importante (nécessitant la sécurité du chemin). De nombreux systèmes (comme Fedora Linux) le placent sur /bintandis que d'autres (comme Mac OSX) le placent sur /usr/bin. Ensuite, il y a Bash sur Windows, par exemple cygwin, msys et autres. Il est toujours préférable de rester pur Bash, lorsque cela est possible. (par commentaire @Marco)

BTW, merci pour le pointeur sur shellcheck, je n'ai jamais vu ça avant.