Pourquoi est-ce tcsh script donnant à l'erreur lors de la configuration de la variable PATH LD_LIBRARY_PATH

J'ai créé un script shell tcsh comme suit:

#!/bin/tcsh

setenv PATH  ""
setenv PATH  .:$HOME/bin:/usr/sbin:/usr/bin:/bin:/usr/X11R6/bin:/usr/local/cuda/bin:/usr/local/bin:/usr/bin:$PATH

setenv LD_LIBRARY_PATH ""
setenv LD_LIBRARY_PATH .:/usr/local/cuda/lib:/usr/local/cuda/lib64/:/usr/local/cuda:/usr/lib:/usr/lib32:/usr/local/cuda/bin:/usr/local/lib/:${LD_LIBRARY_PATH}

Alors j'ai fait ce script exécutable et quand j'essaie de l'exécuter comme

./script.sh il donne des erreurs suivantes:

script.sh: 3: setenv: pas trouvé

script.sh: 4: setenv: pas trouvé

script.sh: 6: setenv: pas trouvé

script.sh: 7: setenv: pas trouvé

Tous les pointeurs, comment définir ces chemins dans mon script shell?

  • Les œuvres de trouver sur ma boîte. Est votre votre tcsh vraiment ce qu'il prétend être? /bin/tcsh --version?
  • donne: tcsh 6.17.02 (Astron) 2010-05-12 (x86_64-unknown-linux) options de large,nls,dl,al,kan,sr,nd,couleur,filec
  • Il y avait une réponse posté à cette question, mais il est maintenant supprimé( je n'ot savoir pourquoi), qui était liée à the4cs.com/~corin/acm/tutorial/unix/tcsh-help.html. ce qui me donne une autre question: Si j'ai une variable d'Environnement $PATH mis dans mon .cshrc à l'aide de setenv PATH .: <mes dossiers ici> Et puis comme je suis en train de faire dans ce shell script que j'ai mis une variable du même nom, à l'aide de set PATH = <autre chose>, qui a préséance sur l'autre, la variable d'environnement SHELL ou variable? Quel est la différence entre les deux, le cas échéant?
  • set définit les variables locales tout en setenv définit les variables d'environnement qui seront héritées par les sous-coquille. Tout comme dans bash, vous utilisez export pour exporter une variable comme une env var.
  • Ce shell que vous utilisez dans votre terminal?
InformationsquelleAutor goldenmean | 2011-11-17
  1. 4

    Je n'ai pas la même erreur sur mon système.

    Mise à JOUR : Voir les deux derniers paragraphes de mon mieux pour deviner ce qu'il se passe.

    Au départ, ma meilleure supposition est que vous pouvez résoudre le problème en changeant shebang

    #!/bin/tcsh

    à

    #!/bin/tcsh -f

    (Ou utilisez

    #!/bin/csh -f

    Les fonctionnalités que tcsh ajoute à l'original csh sont surtout utiles pour l'utilisation interactive plutôt que de script.)

    La -f option indique à tcsh pas pour le traitement de votre .login et .cshrc ou .tcshrc fichiers lorsqu'il démarre. En général, vous ne voulez pas un script pour ce faire, il en fait le script de comportement dépend de votre propre configuration de l'environnement. Peut-être vous avez quelque chose dans votre .login qui fait quelque chose de bizarre avec setenv, bien que je ne peux pas penser à ce qu'il pourrait être. Essayez d'ajouter le -f et voir si cela aide. Même si ce n'est pas le cas, vous devriez faire de toute façon.

    (Et ne pas utiliser -f pour /bin/sh ou /bin/bash scripts; il signifie quelque chose d'autre, et n'est pas nécessaire.)

    Quelques autres observations:

    Réglage $PATH et $LD_LIBRARY_PATH à la chaîne vide est inutile. Il suffit de supprimer ces deux lignes.

    EDIT :

    Sur la re-lecture de votre question, je vois ce que vous faites là. Vous définissez $PATH à la chaîne vide, puis ajouter plus de texte à:

    setenv PATH ""
setenv PATH this:that:$PATH

    Qui fait plus de sens que ce que je croyais, mais c'est encore plus simple à écrire une seule ligne de commande:

    setenv PATH this:that

    Mettre . dans votre $PATH, surtout au début, est une mauvaise idée. Pensez à ce qui se passe si votre exécuter le script dans un répertoire où quelqu'un a déposé un nom de commande ls qui fait quelque chose de méchant. Si vous souhaitez exécuter une commande dans le répertoire courant, utilisez ./command. (Mettre . à la fin de $PATH est plus sûr, mais pas encore une très bonne idée.)

    (Et à l'aide de tcsh ou csh comme un langage de script (par opposition à un shell interactif) est largement considéré comme une mauvaise idée. Cet article, même si ce n'est pas vous persuader de renoncer à tcsh script, permettra au moins de vous faire prendre conscience des pièges.)

    Oh, et si c'est un tcsh script, pourquoi l'appelez-vous script.sh? Les Suffixes sur les noms de fichier ne sont pas requis en vertu des systèmes de type Unix (contrairement à Windows), mais en général, une .sh suffixe implique que c'est un Bourne shell script. Appeler script.tcsh, ou script.csh, ou tout simplement script.

    EDIT :

    Regardons de plus près le message d'erreur que vous obtenez, il semble que les erreurs viennent de /bin/sh, pas de tcsh.

    Sur mon système, quand je change de setenv à Setenv (une inexistant de commande), l'exécution du script avec tcsh me donne:

    Setenv: Command not found.
Setenv: Command not found.
Setenv: Command not found.
Setenv: Command not found.

    qui ne correspond pas les messages d'erreur que vous nous avez montré. Quand je le lance, explicitement, comme /bin/sh foo.tcsh (en laissant le setenv commandes seul), j'obtiens:

    foo.tcsh: 3: setenv: not found
foo.tcsh: 4: setenv: not found
foo.tcsh: 6: setenv: not found
foo.tcsh: 7: setenv: not found

    qui ne correspond pas au format des erreurs que vous avez obtenu.

    Vous dire que /bin/tcsh --version donne des résultats corrects, ce qui n'est pas le problème. En quelque sorte, le script est exécuté par /bin/sh, pas par tcsh.

    Voici ma meilleure supposition sur ce qui se passe. Vous êtes en cours d'exécution sur Cygwin, ou peut-être MSYS, mais vous êtes en invoquant votre script à partir d'un cmd shell, et non à partir d'un shell Cygwin. Votre système Windows a été configuré pour reconnaître un .sh suffixe pour indiquer que le fichier est un script à exécuter par C:\cygwin\bin\sh.exe (comme je l'ai mentionné avant, des suffixes de fichier n'a généralement pas de question sur Unix, ou dans l'environnement Cygwin, mais ils faire sur Windows).

    La solution la plus simple serait probablement de réécrire le script pour se conformer à la syntaxe Bourne shell. Mais il doit exister des moyens à mettre Windows à invoquer Cygwin est tcsh pour l'exécuter. Si j'ai le deviner, laissez-nous savoir et nous pouvons sans doute trouver une solution.

    InformationsquelleAutor Keith Thompson
  2. 2

    Je ne vois rien de mal avec votre script. Il fonctionne très bien sur ma boîte.

    La seule raison de ce message d'erreur (que je pense) est tcsh est en quelque sorte pas utilisé en tant qu'interprète.

    Je peux reproduire l'erreur si j'ajoute un saut de ligne avant #!/bin/tcsh. Lorsque l'arborescence n'est pas la première caractères dans le fichier, l'interprète de la directive ne prend pas effet et de votre shell est utilisé (je devine votre shell n'est pas c-shell variante (csh ou tcsh)?).

    Vérifiez que #!/bin/tcsh est en effet la première ligne du fichier, avec un pas d'espace avant.

    Pour déterminer qui interprète est effectivement utilisé, essayez d'ajouter ceci à votre script:

    echo "$shell"  ## prints shell name if tcsh or csh
echo "$BASH"   ## prints /bin/bash if bash

    exemple:

    [me@home]$ bash x.sh  # run using bash

/bin/bash

[me@home]$ tcsh x.sh # run using tcsh
/bin/tcsh
BASH: Undefined variable.
    • J'ai vérifié, #! est la première ligne dans le fichier de script. Pls vérifier mon dernier commentaire ci-dessus. Vous disposez de tous les pointeurs basés sur cette info/questions dans les commentaires
    • Je pense toujours à tcsh n'est pas en cours d'utilisation par votre script. cela fonctionne comme prévu si vous l'exécutez en utilisant /bin/tcsh script.sh?
    InformationsquelleAutor Shawn Chin
  3. 1

    vient de frapper ce problème, et il s'est avéré être dû au fichier de script Windows ayant EOLs. Une fois que j'ai nettoyé, tout était bon.

    InformationsquelleAutor