Сценарий оболочки работает при сохранении с помощью nano, но не при сохранении с помощью Notepad ++

Когда я копирую сценарий bash через Notepad ++ в новый файл с помощью редактора nano внутри SSH и сохраняю. Это нормально. (sh ./install).

Но если я сохраню файл (точное содержимое), загрузите его на свой веб-сервер, загрузите его с помощью Wget на том же компьютере. Я получаю синтаксические ошибки. Я проверил кодировку, и они кажутся одинаковыми. С тех пор я использовал множество кодировок символов, чтобы убедиться, что это решит проблему. Я также устанавливаю файл в исполняемый файл после загрузки с помощью wget!

Файл работает нормально, и у меня есть нулевые ошибки при копировании и вставке с использованием nano. Любая идея, что это может быть?

2 Solutions collect form web for “Сценарий оболочки работает при сохранении с помощью nano, но не при сохранении с помощью Notepad ++”

Я был бы готов поспорить, что проблема связана с окончанием строки. Вероятно, вы проходите через не-никс-машину где-то вдоль линии. Я также столкнулся с проблемой, когда apache (работает в Linux) добавлял окончания строки стиля Windows в загруженные текстовые файлы, чтобы вы могли видеть что-то подобное.

Чтобы проверить, возьмите загруженный файл и передайте его через od . Если это длинный файл, просто возьмите первые несколько строк:

 head script.sh | od -c 

Просмотрите результаты и проверьте, есть ли у вас что-то вроде этого:

 foo \r \n 

\r – возврат каретки и в Windows, строки заканчиваются \r\n а не \n on * nix. Если окажется, что это действительно проблема, вы можете исправить файл, удалив возврат каретки:

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

Как отметил @graeme, поскольку у вас есть сценарий в обеих формах на сервере, вы можете выполнить простой diff чтобы определить, что отличается от рабочей версии и проблемной версии.

 $ diff working.sh broken.sh 

Вы также можете выполнить параллельный diff следующим образом:

 $ diff -y working.sh broken.sh 

Если сценарий не работает из-за какой-то опечатки, вы часто можете обнаружить их, добавив ключ -x в bash , что заставляет его быть подробным.

 $ bash -x broken.sh 

Вы также можете включить этот переключатель в shebang ( #!/bin/bash ) в верхней части ваших скриптов, например:

 #!/bin/bash -x 

Линейные окончания

Это часто возникает при перемещении файлов из Windows в системы Unix / Linux. Проблема связана с тем, как концы строк обозначаются на двух платформах. Вы можете прочитать об этом здесь, в Википедии под названием « Ньюлайн» .

сделать образец файла

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

Как пояснил @terdon в своем ответе, вы можете использовать sed чтобы удалить их, вы также можете часто использовать инструмент dos2unix чтобы сделать то же самое. Вы можете использовать его одним из двух способов:

 $ dos2unix unixfile.txt 

или если вы не хотите перезаписывать существующий файл:

 $ dos2unix -n oldfile.txt newfile.txt 

Когда вы используете вышеупомянутый diff я упоминал ранее, вы получите такой вывод, когда вы сравните эти 2 файла:

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

Вы не сможете разглядеть различия, просто они там. И снова ответ @ terdon показывает один метод для маршрутизации проблемы с использованием od . Конечно, вы можете использовать различные способы, чтобы понять, что происходит.

Использование vim

с file cmd.

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

Вышеупомянутое указывает на то, что файл из Windows имеет CRLF (иначе символы возврата каретки + строки в конце строк). Эти символы равны 0x0D и 0x0A в шестнадцатеричном виде, снова см. Статью Википедии о Newlines, если вы хотите узнать больше об этом.

Вы также можете использовать vim чтобы увидеть проблему:

 $ vim winfile.txt 

Вот небольшая последовательность, которая показывает, что делать в vim чтобы увидеть проблему. Символы CRLF обычно отображаются в Unix как ^M , это Ctrl + M.

ss of vim

Последовательность показывает, что я снова открываю файл, winfile.txt как форматированный Unix-файл ( :e ++ff=unix ). Это говорит, что vim не будет автоматически обнаруживать, что файл отформатирован для Windows, и поэтому он отображает символы окончания строки ^M

  • Почему на ноутбуках на базе Linux есть слабый сигнал Wi-Fi по сравнению с ноутбуком на базе Windows?
  • Поддерживается минимальное редактирование строк в формате BASH
  • Вызов java из Bash: «Невозможно выполнить двоичный файл»
  • Как сдвоить окна загрузки 8?
  • Является ли это подходящей установкой для отслеживания владения файлами с использованием доли Samba и управления правами?
  • переупорядочить GRUB для отображения Windows сверху
  • Попытка двойного загрузочного linux с окнами, не позволяя мне загрузиться в
  • Ubuntu и Windows 10 с двойной загрузкой
  • Как добавить систему SLED 11 в домен Windows
  • Не удалось создать загрузочный USB-накопитель Kali Linux с Windows10 / Ubuntu
  • Альтернатива API для телефонии для Linux?
  • Linux и Unix - лучшая ОС в мире.