pour ce qui est du ".", tu es obligé de le mettre.
En effet
lance un sous-process (process fils) de type bash (grace au shebang, la première ligne du script), mais ISOLE : aucune modification du fils n'affectera le père (variable d'envir, changement de directory, ...)
Le "PATH" ne change rien à l'affaire, il ne sert qu'a chercher des executables (en fait, quand tu fais "cd xxx", tu fais en fait "/bin/cd xxx" grâce au fait que le path il y a "/bin" ).
Donc au mieux dans le PATH tu peux y mettre $HOME, mais ça ne marchera pas pour ". [fichier]" pour lequel la chaine "fichier" doit contenir le chemin
Le seul moyen est le "sourcing" ou "l'import" execute le code contenu dans le fichier indiqué dans le shell courant AVEC le shell courant (ksh si shell ksh, bash avec bash).
C'est ce qui permet de changer le repertoire dans ton process courant (celui qui te permet d'executer des commandes)
Il est d'ailleurs dangereux de mixer car, si certaines syntaxes sont compatibles, d'autres ne le sont absoluement pas et donc dans un ksh faire un sourcing d'un fichier contenant du code "bash" (le shebang est ignoré) va parfois fonctionner (script "simple" ) mais souvent planter (bad substitution, ...).
Pour ton problème (si le . est vraiment rédhibitoire), il y a d'autres solutions :
- variables d'envir (dans le ~/.profile faire un export CHEMIN=/chemin/absolu/vers/mon/repertoire) puis "cd $CHEMIN" après un . ~/.profile (ou logout/login)
- liens symboliques :
ln -s /chemin/absolu/vers/mon/repertoire ~/ln_simple
cd ~/ln_simple |
Bon Courage, en espérant que ça aide (et que je n'ai pas oublié de solutions)
Message édité par dreameddeath le 18-05-2010 à 00:16:36