Le script Shell fonctionne lorsqu'il est enregistré avec nano mais pas lorsqu'il est enregistré avec Notepad ++

Lorsque je copy mon script bash à travers de Notepad ++ dans un nouveau file avec l'éditeur nano à l'intérieur de SSH et enregistrez. Ça fonctionne bien. (sh ./install).

Mais si je sauvegarde le file (Exact même contenu), download sur mon server web, le download en utilisant Wget sur la même machine. J'obtiens des erreurs de syntaxe. J'ai vérifié l'enencoding et ils semblent être les mêmes. J'ai depuis utilisé une pléthore d'enencoding de caractères pour voir si cela résoudra le problème. Je mets également le file à l'exécutable une fois que je le télécharge en utilisant wget!

Le file fonctionne correctement et j'ai zéro erreurs lors de la copy et le collage en utilisant nano. Une idée de ce que cela peut être?

    Je serais prêt à parier que le problème est lié aux fins de ligne. Vous traversez probablement une machine non * nix quelque part le long de la ligne. J'ai également rencontré un problème où apache (fonctionnant sous Linux) ajoutait des fins de ligne de style Windows aux files text téléchargés afin que vous puissiez voir quelque chose de similaire.

    Pour tester, prenez le file que vous avez téléchargé et passez-le dans od . Si c'est un file long, prenez simplement les premières lignes:

     head script.sh | od -c 

    Regardez à travers la sortie et vérifiez si vous avez quelque chose comme ça:

     foo \r \n 

    Le \r est un return chariot et sur Windows, les lignes se terminent par \r\n par opposition à \n sur * nix. S'il s'avère que c'est effectivement le problème, vous pouvez corriger votre file en supprimant les returns chariot:

     sed -i 's/\r//g' script.sh 

    Comme @graeme l'a astucieusement indiqué puisque vous avez le script dans les deux formulaires sur le server, vous pouvez effectuer un simple diff pour déterminer ce qui est différent entre la version de travail et la version problématique.

     $ diff working.sh broken.sh 

    Vous pouvez également faire un diff côte à côte comme ceci:

     $ diff -y working.sh broken.sh 

    Si le script ne fonctionne pas en raison d'une sorte de faute de frappe, vous pouvez souvent les détecter en ajoutant le commutateur -x à bash , ce qui provoque son verbose.

     $ bash -x broken.sh 

    Vous pouvez également incorporer ce commutateur dans le shebang ( #!/bin/bash ) en haut de vos scripts comme ceci:

     #!/bin/bash -x 

    Fin de ligne

    C'est souvent le problème lors du déplacement de files de Windows vers des systèmes Unix / Linux. La question a à voir avec la façon dont les extrémités des lignes sont notées sur les 2 plates-forms. Vous pouvez lire plus à ce sujet ici sur Wikipedia, intitulé: Newlines .

    faire un file d'exemple

     $ echo -e "This is a file.\nThat I made on Unix.\n" > unixfile.txt 

    Comme l'a décrit @terdon dans sa réponse, vous pouvez utiliser sed pour les supprimer, vous pouvez également utiliser un outil appelé dos2unix pour faire la même chose. Vous pouvez l'utiliser de 1 ou 2 façons:

     $ dos2unix unixfile.txt 

    ou si vous ne souhaitez pas écraser le file existant:

     $ dos2unix -n oldfile.txt newfile.txt 

    Lorsque vous utilisez le diff ci-dessus, j'ai mentionné plus tôt que vous obtiendrez une sortie comme celle-ci lorsque vous comparez ces 2 files:

     $ diff -y unixfile.txt winfile.txt This is a couple | This is a couple of lines of sample | of lines of sample text. | text. 

    Vous ne serez pas capable de discerner les différences, juste qu'elles sont là. Encore une fois, la réponse de @ terdon montre une méthode pour apather le problème en utilisant od . Vous pouvez bien sûr utiliser une variété de façons de comprendre ce qui se passe.

    Utiliser vim

    avec le file cmd.

     $ file unixfile.txt winfile.txt: ASCII text $ file winfile.txt unixfile.txt: ASCII text, with CRLF line terminators 

    Ce qui précède met en évidence le problème que le file de Windows a CRLF (alias Carriage Return + Linefeed caractères à la fin des lignes). Ces personnages sont 0x0D & 0x0A en hexadécimal, voyez à nouveau l'article de Wikipedia sur Newlines si vous voulez en savoir plus à ce sujet.

    Vous pouvez également utiliser vim pour voir le problème aussi:

     $ vim winfile.txt 

    Voici une petite séquence qui montre ce qu'il faut faire dans vim pour voir le problème. Les caractères CRLF apparaissent généralement dans Unix sous la forme ^M , c'est un Ctrl + M.

    ss de vim

    La séquence me montre la réouverture du file, winfile.txt sous la forme d'un file Unix formaté ( :e ++ff=unix ). Cela indique à vim ne pas détecter automatiquement que le file est formaté pour Windows, et il affichera donc les caractères de fin de ligne ^M