Comment obtenir le répertoire source d'un script Bash à partir du script lui-même

Comment obtenir le chemin du répertoire dans lequel se trouve un script Bash , à l' intérieur de ce script?

Je veux utiliser un script Bash comme lanceur pour une autre application. Je veux changer le répertoire de travail en celui où se trouve le script Bash, donc je peux opérer sur les fichiers dans ce répertoire, comme ceci:

$ ./application

#!/bin/bash

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"

est une ligne utile qui vous donnera le nom de répertoire complet du script, peu importe d'où il est appelé.

Cela fonctionnera tant que le dernier composant du chemin utilisé pour trouver le script n'est pas un lien symbolique (les liens de répertoire sont OK). Si vous souhaitez également résoudre les liens vers le script lui-même, vous avez besoin d'une solution multi-lignes:

#!/bin/bash

SOURCE="${BASH_SOURCE[0]}"
while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
  DIR="$( cd -P "$( dirname "$SOURCE" )" >/dev/null 2>&1 && pwd )"
  SOURCE="$(readlink "$SOURCE")"
  [[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
done
DIR="$( cd -P "$( dirname "$SOURCE" )" >/dev/null 2>&1 && pwd )"

Ce dernier travaillera avec toute combinaison d'alias, source, bash -c, liens symboliques, etc.

Attention: si vous accédez cdà un répertoire différent avant d'exécuter cet extrait, le résultat peut être incorrect!

Faites également attention aux $CDPATHgotchas et aux effets secondaires de sortie de stderr si l'utilisateur a outrepassé intelligemment le cd pour rediriger la sortie vers stderr à la place (y compris les séquences d'échappement, comme lors d'un appel update_terminal_cwd >&2sur Mac). L'ajout >/dev/null 2>&1à la fin de votre cdcommande prendra en charge les deux possibilités.

Pour comprendre comment cela fonctionne, essayez d'exécuter ce formulaire plus détaillé:

#!/bin/bash

SOURCE="${BASH_SOURCE[0]}"
while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
  TARGET="$(readlink "$SOURCE")"
  if [[ $TARGET == /* ]]; then
    echo "SOURCE '$SOURCE' is an absolute symlink to '$TARGET'"
    SOURCE="$TARGET"
  else
    DIR="$( dirname "$SOURCE" )"
    echo "SOURCE '$SOURCE' is a relative symlink to '$TARGET' (relative to '$DIR')"
    SOURCE="$DIR/$TARGET" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
  fi
done
echo "SOURCE is '$SOURCE'"
RDIR="$( dirname "$SOURCE" )"
DIR="$( cd -P "$( dirname "$SOURCE" )" >/dev/null 2>&1 && pwd )"
if [ "$DIR" != "$RDIR" ]; then
  echo "DIR '$RDIR' resolves to '$DIR'"
fi
echo "DIR is '$DIR'"

Et il imprimera quelque chose comme:

SOURCE './scriptdir.sh' is a relative symlink to 'sym2/scriptdir.sh' (relative to '.')
SOURCE is './sym2/scriptdir.sh'
DIR './sym2' resolves to '/home/ubuntu/dotfiles/fo fo/real/real1/real2'
DIR is '/home/ubuntu/dotfiles/fo fo/real/real1/real2'

Utilisation dirname "$0":

#!/bin/bash
echo "The script you are running has basename `basename "$0"`, dirname `dirname "$0"`"
echo "The present working directory is `pwd`"

l'utilisation pwdseule ne fonctionnera pas si vous n'exécutez pas le script à partir du répertoire dans lequel il se trouve.

[matt@server1 ~]$ pwd
/home/matt
[matt@server1 ~]$ ./test2.sh
The script you are running has basename test2.sh, dirname .
The present working directory is /home/matt
[matt@server1 ~]$ cd /tmp
[matt@server1 tmp]$ ~/test2.sh
The script you are running has basename test2.sh, dirname /home/matt
The present working directory is /tmp

La dirnamecommande est la plus simple, en analysant simplement le chemin jusqu'au nom de fichier de la $0variable (nom du script):

dirname "$0"

Mais, comme l'a souligné matt b , le chemin renvoyé est différent selon la façon dont le script est appelé. pwdne fait pas le travail car cela vous indique uniquement le répertoire actuel, pas le répertoire dans lequel se trouve le script. De plus, si un lien symbolique vers un script est exécuté, vous obtiendrez un chemin (probablement relatif) vers où réside le lien, pas le script réel.

Certains autres ont mentionné la readlinkcommande, mais dans sa plus simple expression, vous pouvez utiliser:

dirname "$(readlink -f "$0")"

readlinkrésoudra le chemin du script en chemin absolu depuis la racine du système de fichiers. Ainsi, tous les chemins contenant des points simples ou doubles, des tildes et / ou des liens symboliques seront résolus en un chemin complet.

Voici un script illustrant chacun de ces éléments whatdir.sh:

#!/bin/bash
echo "pwd: `pwd`"
echo "\$0: $0"
echo "basename: `basename $0`"
echo "dirname: `dirname $0`"
echo "dirname/readlink: $(dirname $(readlink -f $0))"

Exécuter ce script dans mon répertoire personnel, en utilisant un chemin relatif:

>>>$ ./whatdir.sh 
pwd: /Users/phatblat
$0: ./whatdir.sh
basename: whatdir.sh
dirname: .
dirname/readlink: /Users/phatblat

Encore une fois, mais en utilisant le chemin d'accès complet au script:

>>>$ /Users/phatblat/whatdir.sh 
pwd: /Users/phatblat
$0: /Users/phatblat/whatdir.sh
basename: whatdir.sh
dirname: /Users/phatblat
dirname/readlink: /Users/phatblat

Modification des répertoires:

>>>$ cd /tmp
>>>$ ~/whatdir.sh 
pwd: /tmp
$0: /Users/phatblat/whatdir.sh
basename: whatdir.sh
dirname: /Users/phatblat
dirname/readlink: /Users/phatblat

Et enfin en utilisant un lien symbolique pour exécuter le script:

>>>$ ln -s ~/whatdir.sh whatdirlink.sh
>>>$ ./whatdirlink.sh 
pwd: /tmp
$0: ./whatdirlink.sh
basename: whatdirlink.sh
dirname: .
dirname/readlink: /Users/phatblat

pushd . > /dev/null
SCRIPT_PATH="${BASH_SOURCE[0]}"
if ([ -h "${SCRIPT_PATH}" ]); then
  while([ -h "${SCRIPT_PATH}" ]); do cd `dirname "$SCRIPT_PATH"`; 
  SCRIPT_PATH=`readlink "${SCRIPT_PATH}"`; done
fi
cd `dirname ${SCRIPT_PATH}` > /dev/null
SCRIPT_PATH=`pwd`;
popd  > /dev/null

Fonctionne pour toutes les versions, y compris

• lorsqu'il est appelé via un lien souple de profondeur multiple,
• quand le déposer
• lorsque le script est appelé par la commande " source" aka .(point).
• lorsque arg $0est modifié depuis l'appelant.
• "./script"
• "/full/path/to/script"
• "/some/path/../../another/path/script"
• "./some/folder/script"

Alternativement, si le script bash lui-même est un lien symbolique relatif, vous voulez le suivre et renvoyer le chemin complet du script lié:

pushd . > /dev/null
SCRIPT_PATH="${BASH_SOURCE[0]}";
if ([ -h "${SCRIPT_PATH}" ]) then
  while([ -h "${SCRIPT_PATH}" ]) do cd `dirname "$SCRIPT_PATH"`; SCRIPT_PATH=`readlink "${SCRIPT_PATH}"`; done
fi
cd `dirname ${SCRIPT_PATH}` > /dev/null
SCRIPT_PATH=`pwd`;
popd  > /dev/null

SCRIPT_PATHest donné en chemin complet, peu importe comment il est appelé.
Assurez-vous simplement de localiser cela au début du script.

Ce commentaire et code Copyleft, licence sélectionnable sous GPL2.0 ou ultérieure ou CC-SA 3.0 (CreativeCommons Share Alike) ou ultérieure. (c) 2008. Tous droits réservés. Aucune garantie d'aucune sorte. Tu étais prévenu.
http://www.gnu.org/licenses/gpl-2.0.txt
http://creativecommons.org/licenses/by-sa/3.0/
18eedfe1c99df68dc94d4a94712a71aaa8e1e9e36cacf421b9463dd2bbaa02906d0d6656

Réponse courte:

`dirname $0`

ou (de préférence ):

$(dirname "$0")

Vous pouvez utiliser $BASH_SOURCE:

#!/bin/bash

scriptdir=`dirname "$BASH_SOURCE"`

Notez que vous devez utiliser #!/bin/bashet non #!/bin/shcar c'est une extension Bash.

Cela devrait le faire:

DIR="$(dirname "$(readlink -f "$0")")"

Cela fonctionne avec les liens symboliques et les espaces dans le chemin.

Voir les pages de manuel pour dirnameet readlink.

D'après la piste des commentaires, il ne semble pas fonctionner avec Mac OS. Je n'ai pas d'idées pourquoi c'est comme ça. Aucune suggestion?

pwdpeut être utilisé pour trouver le répertoire de travail actuel et dirnamepour trouver le répertoire d'un fichier particulier (la commande qui a été exécutée est $0, dirname $0devrait donc vous donner le répertoire du script actuel).

Cependant, dirnamedonne précisément la partie répertoire du nom de fichier, qui sera plus que probablement relative au répertoire de travail actuel. Si votre script doit changer de répertoire pour une raison quelconque, la sortie de dirnamedevient vide de sens.

Je suggère ce qui suit:

#!/bin/bash

reldir=`dirname $0`
cd $reldir
directory=`pwd`

echo "Directory is $directory"

De cette façon, vous obtenez un répertoire absolu plutôt que relatif.

Étant donné que le script sera exécuté dans une instance bash distincte, il n'est pas nécessaire de restaurer le répertoire de travail par la suite, mais si vous souhaitez revenir dans votre script pour une raison quelconque, vous pouvez facilement attribuer la valeur de pwdà une variable avant de changer de répertoire, pour une utilisation future.

Bien que juste

cd `dirname $0`

résout le scénario spécifique dans la question, je trouve avoir le chemin absolu vers plus plus utile en général.

Je suis fatigué de revenir sur cette page encore et encore pour copier-coller le one-liner dans la réponse acceptée. Le problème, c'est qu'il n'est pas facile à comprendre et à retenir.

Voici un script facile à retenir:

DIR="$(dirname "${BASH_SOURCE[0]}")"  # get the directory name
DIR="$(realpath "${DIR}")"    # resolve its full path if need be

Je ne pense pas que ce soit aussi facile que d'autres l'ont fait croire. pwdne fonctionne pas, car le répertoire courant n'est pas nécessairement le répertoire avec le script. $0n'a pas toujours les informations non plus. Considérez les trois façons suivantes pour appeler un script:

./script

/usr/bin/script

script

Dans la première et la troisième manière, $0les informations de chemin d'accès ne sont pas complètes. Dans les deuxième et troisième, pwdne fonctionne pas. La seule façon d'obtenir le répertoire de la troisième manière serait de parcourir le chemin et de trouver le fichier avec la bonne correspondance. Fondamentalement, le code devrait refaire ce que fait le système d'exploitation.

Une façon de faire ce que vous demandez serait de simplement coder en dur les données dans le /usr/sharerépertoire et de les référencer par son chemin complet. Les données ne doivent de /usr/bintoute façon pas être dans le répertoire, c'est donc probablement la chose à faire.

SCRIPT_DIR=$( cd ${0%/*} && pwd -P )

$(dirname "$(readlink -f "$BASH_SOURCE")")

Cela obtient le répertoire de travail actuel sur Mac OS X 10.6.6:

DIR=$(cd "$(dirname "$0")"; pwd)

Ceci est spécifique à Linux, mais vous pouvez utiliser:

SELF=$(readlink /proc/$$/fd/255)

Voici une doublure conforme POSIX:

SCRIPT_PATH=`dirname "$0"`; SCRIPT_PATH=`eval "cd \"$SCRIPT_PATH\" && pwd"`

# test
echo $SCRIPT_PATH

J'ai essayé tout cela et aucun n'a fonctionné. L'un était très proche mais avait un minuscule bug qui le cassait gravement; ils ont oublié de mettre le chemin entre guillemets.

De plus, beaucoup de gens supposent que vous exécutez le script à partir d'un shell, alors ils oublient que lorsque vous ouvrez un nouveau script, il revient par défaut à votre domicile.

Essayez ce répertoire sur pour la taille:

/var/No one/Thought/About Spaces Being/In a Directory/Name/And Here's your file.text

Cela vous convient, peu importe comment ou où vous l'exécutez:

#!/bin/bash
echo "pwd: `pwd`"
echo "\$0: $0"
echo "basename: `basename "$0"`"
echo "dirname: `dirname "$0"`"

Donc, pour le rendre réellement utile, voici comment passer au répertoire du script en cours d'exécution:

cd "`dirname "$0"`"

Voici la manière simple et correcte:

actual_path=$(readlink -f "${BASH_SOURCE[0]}")
script_dir=$(dirname "$actual_path")

Explication:

• ${BASH_SOURCE[0]}- le chemin complet vers le script. La valeur de ceci sera correcte même lorsque le script est généré, par exemple, source <(echo 'echo $0')imprime bash , tandis que le remplacer par ${BASH_SOURCE[0]}affichera le chemin complet du script. (Bien sûr, cela suppose que vous êtes OK en prenant une dépendance à Bash.)

• readlink -f- Résout récursivement tous les liens symboliques dans le chemin spécifié. Il s'agit d'une extension GNU et non disponible sur (par exemple) les systèmes BSD. Si vous utilisez un Mac, vous pouvez utiliser Homebrew pour installer GNU coreutilset le remplacer par greadlink -f.

• Et bien sûr, dirnameobtient le répertoire parent du chemin.

La façon la plus courte et la plus élégante de le faire est:

#!/bin/bash
DIRECTORY=$(cd `dirname $0` && pwd)
echo $DIRECTORY

Cela fonctionnerait sur toutes les plateformes et est super propre.

Plus de détails peuvent être trouvés dans "Dans quel répertoire se trouve ce script bash? ".

J'utiliserais quelque chose comme ça:

# retrieve the full pathname of the called script
scriptPath=$(which $0)

# check whether the path is a link or not
if [ -L $scriptPath ]; then

    # it is a link then retrieve the target path and get the directory name
    sourceDir=$(dirname $(readlink -f $scriptPath))

else

    # otherwise just get the directory name of the script path
    sourceDir=$(dirname $scriptPath)

fi

Il s'agit d'une légère révision de la solution e-satis et 3bcdnlklvc04a soulignée dans leur réponse :

SCRIPT_DIR=''
pushd "$(dirname "$(readlink -f "$BASH_SOURCE")")" > /dev/null && {
    SCRIPT_DIR="$PWD"
    popd > /dev/null
}    

Cela devrait toujours fonctionner dans tous les cas énumérés.

Cela évitera popdaprès un échec pushd, grâce à konsolebox.

Pour les systèmes ayant des coreutils GNU readlink(par ex. Linux):

$(readlink -f "$(dirname "$0")")

Il n'est pas nécessaire d'utiliser BASH_SOURCElorsque $0contient le nom de fichier du script.

#!/bin/sh
PRG="$0"

# need this for relative symlinks
while [ -h "$PRG" ] ; do
   PRG=`readlink "$PRG"`
done

scriptdir=`dirname "$PRG"`

$_mérite d'être mentionné comme une alternative à $0. Si vous exécutez un script à partir de Bash, la réponse acceptée peut être raccourcie en:

DIR="$( dirname "$_" )"

Notez que cela doit être la première instruction de votre script.

J'ai comparé bon nombre des réponses données et j'ai trouvé des solutions plus compactes. Ceux-ci semblent gérer tous les cas de bord fou qui découlent de votre combinaison préférée de:

• Chemins absolus ou chemins relatifs
• Liens logiciels de fichiers et de répertoires
• Comme l' invocation script, bash script, bash -c script, source scriptou. script
• Espaces, tabulations, sauts de ligne, unicode, etc. dans les répertoires et / ou le nom de fichier
• Noms de fichiers commençant par un tiret

Si vous exécutez sous Linux, il semble que l'utilisation du prochandle soit la meilleure solution pour localiser la source entièrement résolue du script en cours d'exécution (dans une session interactive, le lien pointe vers le respectif /dev/pts/X):

resolved="$(readlink /proc/$$/fd/255 && echo X)" && resolved="${resolved%$'\nX'}"

Cela a un peu de laideur, mais le correctif est compact et facile à comprendre. Nous n'utilisons pas uniquement les primitives bash, mais je suis d'accord avec cela car cela readlinksimplifie considérablement la tâche. Le echo Xajoute un Xà la fin de la chaîne de variable afin que les espaces de fin du nom de fichier ne soient pas consommés et que la substitution de paramètre ${VAR%X}à la fin de la ligne supprime le X. Parce qu'il readlinkajoute une nouvelle ligne qui lui est propre (qui serait normalement consommée dans la substitution de commandes si ce n'était pour notre supercherie précédente), nous devons également nous en débarrasser. Ceci est plus facilement accompli en utilisant le $''schéma de citation, qui nous permet d'utiliser des séquences d'échappement telles que\n pour représenter les retours à la ligne (c'est aussi ainsi que vous pouvez facilement créer des répertoires et des fichiers nommés de manière détournée).

Ce qui précède devrait couvrir vos besoins pour localiser le script en cours d'exécution sur Linux, mais si vous n'avez pas le procsystème de fichiers à votre disposition, ou si vous essayez de localiser le chemin entièrement résolu d'un autre fichier, alors peut-être que vous trouver le code ci-dessous utile. Ce n'est qu'une légère modification par rapport à la doublure ci-dessus. Si vous jouez autour avec répertoire / étranges noms de fichiers, en vérifiant la sortie à la fois lset readlinkest informative, comme lsAffichera chemins « simplifiée », en substituant ?pour des choses comme les nouvelles lignes.

absolute_path=$(readlink -e -- "${BASH_SOURCE[0]}" && echo x) && absolute_path=${absolute_path%?x}
dir=$(dirname -- "$absolute_path" && echo x) && dir=${dir%?x}
file=$(basename -- "$absolute_path" && echo x) && file=${file%?x}

ls -l -- "$dir/$file"
printf '$absolute_path: "%s"\n' "$absolute_path"

Essayez d'utiliser:

real=$(realpath $(dirname $0))

Essayez la solution de compatibilité croisée suivante:

CWD="$(cd -P -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd -P)"

car les commandes telles que realpathou readlinkpourraient ne pas être disponibles (selon le système d'exploitation).

Remarque: Dans Bash, il est recommandé d'utiliser à la ${BASH_SOURCE[0]}place de $0, sinon le chemin peut se casser lors de la recherche du fichier ( source/ .).

Vous pouvez également essayer la fonction suivante dans bash:

realpath () {
  [[ $1 = /* ]] && echo "$1" || echo "$PWD/${1#./}"
}

Cette fonction prend 1 argument. Si l'argument a déjà un chemin absolu, imprimez-le tel quel, sinon imprimez l' $PWDargument variable + nom de fichier (sans ./préfixe).

En relation:

• Comment définir le répertoire de travail actuel sur le répertoire du script?
• Chemin absolu du script Bash avec OS X
• Un moyen fiable pour un script Bash d'obtenir le chemin complet vers lui-même

Je crois que j'ai celui-ci. Je suis en retard à la fête, mais je pense que certains apprécieront d'être ici s'ils rencontrent ce fil. Les commentaires doivent expliquer:

#!/bin/sh # dash bash ksh # !zsh (issues). G. Nixon, 12/2013. Public domain.

## 'linkread' or 'fullpath' or (you choose) is a little tool to recursively
## dereference symbolic links (ala 'readlink') until the originating file
## is found. This is effectively the same function provided in stdlib.h as
## 'realpath' and on the command line in GNU 'readlink -f'.

## Neither of these tools, however, are particularly accessible on the many
## systems that do not have the GNU implementation of readlink, nor ship
## with a system compiler (not to mention the requisite knowledge of C).

## This script is written with portability and (to the extent possible, speed)
## in mind, hence the use of printf for echo and case statements where they
## can be substituded for test, though I've had to scale back a bit on that.

## It is (to the best of my knowledge) written in standard POSIX shell, and
## has been tested with bash-as-bin-sh, dash, and ksh93. zsh seems to have
## issues with it, though I'm not sure why; so probably best to avoid for now.

## Particularly useful (in fact, the reason I wrote this) is the fact that
## it can be used within a shell script to find the path of the script itself.
## (I am sure the shell knows this already; but most likely for the sake of
## security it is not made readily available. The implementation of "$0"
## specificies that the $0 must be the location of **last** symbolic link in
## a chain, or wherever it resides in the path.) This can be used for some
## ...interesting things, like self-duplicating and self-modifiying scripts.

## Currently supported are three errors: whether the file specified exists
## (ala ENOENT), whether its target exists/is accessible; and the special
## case of when a sybolic link references itself "foo -> foo": a common error
## for beginners, since 'ln' does not produce an error if the order of link
## and target are reversed on the command line. (See POSIX signal ELOOP.)

## It would probably be rather simple to write to use this as a basis for
## a pure shell implementation of the 'symlinks' util included with Linux.

## As an aside, the amount of code below **completely** belies the amount
## effort it took to get this right -- but I guess that's coding for you.

##===-------------------------------------------------------------------===##

for argv; do :; done # Last parameter on command line, for options parsing.

## Error messages. Use functions so that we can sub in when the error occurs.

recurses(){ printf "Self-referential:\n\t$argv ->\n\t$argv\n" ;}
dangling(){ printf "Broken symlink:\n\t$argv ->\n\t"$(readlink "$argv")"\n" ;}
errnoent(){ printf "No such file: "$@"\n" ;} # Borrow a horrible signal name.

# Probably best not to install as 'pathfull', if you can avoid it.

pathfull(){ cd "$(dirname "$@")"; link="$(readlink "$(basename "$@")")"

## 'test and 'ls' report different status for bad symlinks, so we use this.

 if [ ! -e "$@" ]; then if $(ls -d "$@" 2>/dev/null) 2>/dev/null;  then
    errnoent 1>&2; exit 1; elif [ ! -e "$@" -a "$link" = "$@" ];   then
    recurses 1>&2; exit 1; elif [ ! -e "$@" ] && [ ! -z "$link" ]; then
    dangling 1>&2; exit 1; fi
 fi

## Not a link, but there might be one in the path, so 'cd' and 'pwd'.

 if [ -z "$link" ]; then if [ "$(dirname "$@" | cut -c1)" = '/' ]; then
   printf "$@\n"; exit 0; else printf "$(pwd)/$(basename "$@")\n"; fi; exit 0
 fi

## Walk the symlinks back to the origin. Calls itself recursivly as needed.

 while [ "$link" ]; do
   cd "$(dirname "$link")"; newlink="$(readlink "$(basename "$link")")"
   case "$newlink" in
    "$link") dangling 1>&2 && exit 1                                       ;;
         '') printf "$(pwd)/$(basename "$link")\n"; exit 0                 ;;
          *) link="$newlink" && pathfull "$link"                           ;;
   esac
 done
 printf "$(pwd)/$(basename "$newlink")\n"
}

## Demo. Install somewhere deep in the filesystem, then symlink somewhere 
## else, symlink again (maybe with a different name) elsewhere, and link
## back into the directory you started in (or something.) The absolute path
## of the script will always be reported in the usage, along with "$0".

if [ -z "$argv" ]; then scriptname="$(pathfull "$0")"

# Yay ANSI l33t codes! Fancy.
 printf "\n\033[3mfrom/as: \033[4m$0\033[0m\n\n\033[1mUSAGE:\033[0m   "
 printf "\033[4m$scriptname\033[24m [ link | file | dir ]\n\n         "
 printf "Recursive readlink for the authoritative file, symlink after "
 printf "symlink.\n\n\n         \033[4m$scriptname\033[24m\n\n        "
 printf " From within an invocation of a script, locate the script's "
 printf "own file\n         (no matter where it has been linked or "
 printf "from where it is being called).\n\n"

else pathfull "$@"
fi

Ce sont de courtes façons d'obtenir des informations sur le script:

Dossiers et fichiers:

    Script: "/tmp/src dir/test.sh"
    Calling folder: "/tmp/src dir/other"

En utilisant ces commandes:

    echo Script-Dir : `dirname "$(realpath $0)"`
    echo Script-Dir : $( cd ${0%/*} && pwd -P )
    echo Script-Dir : $(dirname "$(readlink -f "$0")")
    echo
    echo Script-Name : `basename "$(realpath $0)"`
    echo Script-Name : `basename $0`
    echo
    echo Script-Dir-Relative : `dirname "$BASH_SOURCE"`
    echo Script-Dir-Relative : `dirname $0`
    echo
    echo Calling-Dir : `pwd`

Et j'ai obtenu cette sortie:

     Script-Dir : /tmp/src dir
     Script-Dir : /tmp/src dir
     Script-Dir : /tmp/src dir

     Script-Name : test.sh
     Script-Name : test.sh

     Script-Dir-Relative : ..
     Script-Dir-Relative : ..

     Calling-Dir : /tmp/src dir/other

Voir également: https://pastebin.com/J8KjxrPF

Cela fonctionne dans bash-3.2:

path="$( dirname "$( which "$0" )" )"

Si vous avez un ~/binrépertoire dans votre $PATH, vous en avez Adans ce répertoire. Il source le script ~/bin/lib/B. Vous savez où le script inclus est relatif à celui d'origine, dans le libsous - répertoire, mais pas où il est relatif au répertoire actuel de l'utilisateur.

Ceci est résolu par ce qui suit (à l'intérieur A):

source "$( dirname "$( which "$0" )" )/lib/B"

Peu importe où se trouve l'utilisateur ou comment il appelle le script, cela fonctionnera toujours.

La meilleure solution compacte à mon avis serait:

"$( cd "$( echo "${BASH_SOURCE[0]%/*}" )"; pwd )"

Il n'y a aucune dépendance à autre chose que Bash. L'utilisation de dirname, readlinket basenameconduira éventuellement à des problèmes de compatibilité, il est donc préférable d'éviter autant que possible.