Comment faire pour exécuter un script csh à partir d'un script sh

Je me demandais si il existe un moyen de la source d'un script csh à partir d'un script sh. Ci-dessous est un exemple de ce qui est d'essayer d'être mis en œuvre:

script1.sh:

#!/bin/sh

source script2

script2:

#!/bin/csh -f

setenv TEST 1234
set path = /home/user/sandbox

Quand je lance sh script1.sh, j'obtiens des erreurs de syntaxe générée à partir de script2 (normal puisque nous sommes l'aide d'un autre Shebang). Est il possible que je peux exécuter script2 par script1?

OriginalL'auteur user3245776 | 2014-01-28

5

Au lieu de source script2 l'exécuter en tant qu':
```
csh -f script2
```
OriginalL'auteur anubhava
2

Depuis votre cas d'utilisation dépend de retenir les variables d'environnement définies par l' csh script, essayez d'ajouter ceci au début de script1:
```
#!/bin/sh

if [ "$csh_executed" -ne 1 ]; then
    csh_executed=1 exec csh -c "source script2;
                                exec /bin/sh \"$0\" \"$argv\"" "$@"
fi

# rest of script1
```
Si le csh_executed variable n'est pas définie à 1 dans l'environnement, exécuter un csh script sources script2 puis exécute une instance de sh, ce qui permettra de conserver les modifications apportées à l'environnement dans script2. exec est utilisée pour éviter de créer de nouveaux processus pour chaque instance du shell, il vous suffit de "commutation" à partir d'un shell à l'autre. Réglage csh_executed dans l'environnement de la csh de commande assure que nous n'avons pas coincé dans une boucle lorsque script1 est ré-exécuté par le csh instance.

Malheureusement, il ya un inconvénient que je ne pense pas que peut être résolu, du moins pas à ma connaissance limitée de csh: le deuxième appel de script1 reçoit l'original de tous les arguments sous forme d'une chaîne unique, plutôt qu'une séquence d'arguments distincts.

OriginalL'auteur chepner
1

Vous ne voulez pas source là; il exécute le script à l'intérieur de votre shell existant, sans frai un sous-processus. Évidemment, votre sh processus ne peut pas lancer quelque chose comme ce qui n'est pas un script sh.

Il suffit d'appeler le script directement, en supposant que c'est le fichier exécutable:
```
script2
```
OriginalL'auteur Wooble
0

Le plus proche, vous pouvez venir à sourcing d'un script à un autre exécuteur de votre script original est d'utiliser exec. exec remplacera le processus en cours de l'espace avec le nouveau processus. Contrairement à source, cependant, lorsque votre exec-ed à la fin du programme, l'ensemble du processus se termine. De sorte que vous pouvez le faire:
```
#!/bin/sh

exec /path/to/csh/script
```
mais vous ne pouvez pas faire ceci:
```
#!/bin/sh

exec /path/to/csh/script
some-other-command
```
Mais êtes-vous sûr que vous voulez vraiment source le script? Peut-être vous voulez juste pour l'exécuter dans un sous-processus:
```
#!/bin/sh

csh -f /path/to/csh/script
some-other-command
```
Merci pour la réponse informative. Après lecture de votre réponse, je vois que j'ai destiné à être exécuté comme un processus secondaire. Pardonnez ma hâte, mais je suis encore en train d'utiliser pour l'affichage.

OriginalL'auteur kojiro
0

Vous souhaitez que les paramètres de votre csh script pour appliquer à la sh script qui l'invoque.

Fondamentalement, vous ne pouvez pas faire cela, mais il ya certains (assez moche) des moyens de le faire fonctionner. Si vous exécuter votre csh script, il va mettre ces variables dans le cadre de la procédure d'exécuter le script, ils vont disparaître dès qu'il retourne à l'appelant.

Votre meilleur pari est de simplement écrire une nouvelle version de votre script csh comme un script sh, et source ou . de l'appel sh script.

Vous pourriez traduire votre script csh:
```
#!/bin/csh -f

setenv TEST 1234
set path = /home/user/sandbox
```
:
```
export TEST=1234
export PATH=/home/user/sandbox
```
(csh traite le shell variable tableau $path spécialement, l'attacher à la variable d'environnement $PATH. sh et ses dérivés ne le faites pas, ils traitent avec $PATH lui-même directement.)

Noter qu'un script prévu pour être d'origine devrait pas ont un #! ligne en haut, car il ne fait pas de sens pour l'exécuter dans son propre processus; vous avez besoin pour exécuter son contenu dans le contexte de l'appelant.

Si le maintien de deux copies du script, un être sourced de csh ou tcsh scripts et d'un autre être sourced ou .ed de sh/ksh/bash/zsh script, n'est pas pratique, il y a d'autres solutions. Par exemple, votre script peut imprimer une série de sh des commandes à exécuter; vous pouvez ensuite faire quelque chose comme
```
eval `./foo.csh`
```
(fin de ligne, va poser quelques problèmes ici).

Ou vous pouvez modifier le script csh donc, il définit les variables d'environnement requises et invoque ensuite certains de commande, ce qui pourrait être un nouveau shell interactif; ce n'est pas pratique, car il ne définit pas ces variables dans le shell interactif, vous êtes en cours d'exécution.

Si un logiciel nécessite certaines des variables d'environnement à définir, il est pratique courante de fournir des scripts appelés, par exemple, setup.sh et setup.csh, de sorte que sh/ksh/bash/zsh les utilisateurs peuvent faire:
```
. /path/to/package/setup.sh
```
et csh/tcsh les utilisateurs peuvent faire:
```
source /path/to/package/setup.csh
```
D'ailleurs, cette commande:
```
set path = /home/user/sandbox
```
dans votre exemple de script est probablement pas une bonne idée. Il remplace l'ensemble de votre $PATH avec juste un seul répertoire, ce qui signifie que vous ne serez pas en mesure d'exécuter des commandes simples comme ls, sauf si vous spécifiez leur chemin complet. Vous feriez habituellement quelque chose comme:
```
set path = ( $path /home/user/sandbox )
```
ou, en sh:
```
PATH=$PATH:/home/user/sandbox
```
OriginalL'auteur Keith Thompson

Vous devez vous connecter pour publier un commentaire.