": Command not found"

Question

Certaines question devait se poser lors de l'approvisionnement un de votre fichier env (une série d'exportation variable)

par exemple:

... 
export MY_ROOT=/Soft/dev/blah/blah 
export MY_BIN=${MY_ROOT}/bin 
... 

résultats dans

$. my_env.sh 
$echo $MY_BIN 
/bint/dev/blah/blah 

= > "/ bin" semble remplacer le début de la variable au lieu de le suffixer.

Une idée?

D'ailleurs chaque fois que nous approvisionnons ce fichier, un message d'erreur est signalée:

": Command not found" 

Ce qui est bizarre .. Ce message apparaît même si nous commentons tout son contenu. Le shell invoqué au début semble bon #!/bin/sh, ou #!/bin/bash.

Qu'en est-il des caractères de contrôle? Comment les afficher sur Linux?

Answer 1

le fichier:

dos2unix my_env.sh 

Il n'y a pas besoin d'un tralala dans un fichier qui va seulement être source car il est exécuté dans le shell courant de toute façon.Cependant, en tant que commentaire, il pourrait être informatif pour les lecteurs humains.

Answer 2

": Command not found" est l'erreur que j'ai vu quand un script shell UNIX/Linux a été (mis-) manipulé par un système MS Windows. Par exemple, s'il a été extrait à l'aide d'un WebCVS, modifié à l'aide du Bloc-notes ou de WordPad, puis soumis à nouveau.

(Il se plaint qu'il ne peut pas trouver le [Ctrl-M] exécutable --- qui est un nom de fichier parfaitement valide, bien que très gênant et quelque peu suspect pour UNIX/Linux).

Exécutez le fichier via GNU cat -A ou les commandes od -x ou hexdump voir ces (et vérifier mon diagnostic ... ou l'exécuter par tr -d avec le devis et appropriée shell « mot pour mot » manipulation de votre système. (Par exemple tr -d '[Ctrl-V],[Ctrl-M]' . sous Bash sur un système Linux typique)

en fonction de votre version de tr vous pourriez être en mesure d'utiliser: tr -d '\r' ou tr -d \015 (015 est le octal pour CR, "retour chariot" ou^M --- MS-DOS utilisé pour les paires CR/LF utilisés comme terminaison de ligne, ce qui est juste l'une des nombreuses raisons que MS-DOS peut pourrir dans l'abîme Forsaken en matière d'interopérabilité. Terminat ligne eurs de caractères uniques ne causent pas de vrais problèmes pour quelqu'un d'autre ... mais PAIRS causer des problèmes réels de conversion quand tout le reste dans l'histoire de l'informatique grand public utilisé des caractères individuels pour cela).

Oh, ouais, vim a une set ff pratique (aka l'option set fileformat qui peut gérer UNIX, MacOS, et les conventions de terminaison de ligne MS-DOS de toute copie de vim quelle que soit la plate-forme que vous êtes. Je semble rappeler que le vim par défaut est de détecter quels types de terminaison de ligne un fichier utilise et de le laisser inchangé (et par défaut à natif de votre plate-forme pour tous les nouveaux fichiers, bien sûr)