Проблемы с оболочкой при запуске скриптов в Ubuntu от имени нового пользователя

Question

Когда я захожу на конкретный хост Ubuntu Linux (10.04 64bit) через SSH, я получаю оболочку bash. Отсюда я могу запустить определенный скрипт Python с установленным исполняемым битом, который имеет следующую строку:

#!/usr/bin/env python

Однако, если другой (новый) пользователь входит на тот же хост через SSH и пытается запустить этот (или копию этого) сценария, он получает эту ошибку:

$ ./script.py
: No such file or directory

Оказывается, этот файл на самом деле является файлом с окончанием строки в DOS, но я могу запустить это нормально из своего логина. Если я преобразую его в формат UNIX, то другой человек также сможет нормально его запустить.

Сценарий также отлично работает для нас обоих, если мы добавим префикс «python» независимо от формата DOS / UNIX:

$ python ./script.py
blah blah blah...

В дополнение к этому, как только скрипт преобразуется в формат UNIX и другой пользователь может его запустить, он все равно не запускается из Makefile - make отображает ту же ошибку, что и выше.

Я читал, что / bin / sh - это оболочка 'dash' (не 'bash') в Ubuntu, и мне интересно, имеет ли это какое-то отношение к этому, поскольку он ведет себя иначе, чем bash. Если это так, я хотел бы знать, в чем разница между моим логином (который прекрасно работает и работал годами) и логином этого нового пользователя, который отображает все виды странного поведения. С чего начать искать?

Также возможно актуально - новый пользователь был создан автоматически службой Likewise (клиент интеграции Active Directory), и возможно, что эта служба каким-то образом неправильно настроила нового пользователя.

Я также попытался изменить первую строку на #! / Usr / bin / python без разницы.

Оба пользователя используют оболочку bash в качестве оболочки входа в систему.

Answer 1

У меня была та же проблема, и из приведенных выше ответов не сразу было понятно, что это была за проблема или каково ее решение, однако теперь я понимаю, что понимаю.

Видимо, разрывы строк в Windows кодируются немного по-другому. Хотя cygwin может кодировать в формате unix, я использовал текстовый редактор Windows (Notepad ++) для написания своих сценариев, а формат по умолчанию - кодировка Windows CRLF. Notepad ++ можно перенастроить для unix в качестве формата по умолчанию. Все скрипты, сгенерированные моими коллегами на машинах Linux или Mac, будут работать нормально, но тогда я отредактирую их в Windows, и мне не пришло в голову, что могут возникнуть проблемы, пока я не попробую запустить их на машине Linux. 1003 *

Во-первых, это может быть диагностировано в cygwin или bash с помощью:

cat -v file.py

где каждая строка будет иметь ^ M в конце, если она в формате DOS

Во-вторых, у cygwin есть простой конвертер:

d2u file.py

и вы можете проверить, сработало ли это, как на первом шаге. Все мои сценарии будут работать как обычно.

Answer 2

Загадка в том, почему вы можете запустить его без конвертации.Все остальное поведение ожидается, так как ваш шебанг говорит env выполнить python^M, который не существует. Или это так? Если у вас есть символическая ссылка или скрипт с именем python^M в вашем $PATH (но не у другого пользователя), который объясняет это странное поведение.Выполните type -a python^M (нажмите Ctrl-V, затем Ctrl-M, чтобы получить ^M).

Если вы измените shebang на #!/usr/bin/python, то должно составить разницуВы должны получить -bash: ./script.py: /usr/bin/python^M: bad interpreter: No such file or directory вместо : No such file or directory.

Answer 3

Я решил это и сам отвечу на полноту.

Проблема связана с тем, что мы используем git в Cygwin / Windows с core.autocrlf = true. Мы делаем это по разным причинам, и менять нетривиально.

Первоначальный новый пользователь, вошедший в систему Linux, также скопировал свой Cygwin .gitconfig, который содержал core.autocrlf = true, в свою новую учетную запись. Затем они клонировали репозиторий git, который содержал данный скрипт на python. Я не включил эту информацию в первоначальный вопрос, потому что я просто не установил связь. Я не хотел путать проблему, объясняя вещи, которые казались неуместными. Оглядываясь назад, а?

В любом случае, все сценарии были сделаны в клонированном DOS-формате, и это объясняет, почему для этого пользователя ничего не будет работать должным образом. Это также объясняет, почему сообщения об ошибках были бесполезны, потому что символ возврата каретки ^ M возвращал курсор в начало строки без перевода строки, а затем «Нет такого файла или каталога» перезаписывал полезную часть сообщения. , Я заметил это, когда установил PATH в каталог без разрешения, и получил испорченное сообщение «Permission deniedn» - это жулик «n» заставило меня задуматься.

Поэтому мое первоначальное предположение, что мы все выполняем один и тот же сценарий (поскольку все они были из одного и того же git-репозитория), было неверным - на самом деле мы вообще не запускали один и тот же сценарий. Для большинства из нас это был скрипт Python в формате UNIX, но для этого пользователя это был DOS-формат. В конце концов, это оказывается довольно простой проблемой, но мы снова укушены проблемой, связанной с Windows. Не в последний раз.

Спасибо всем за ваши ответы.