Bash script: плохой интерпретатор

Ответ 1

Первая строка, #!/bin/bash, сообщает Linux, где найти интерпретатор. Скрипт также должен быть выполнен с помощью chmod +x script.sh, что, как вы, похоже, сделали.

Весьма вероятно, что вы создали этот файл с помощью редактора Windows, который будет помещать <cr><lf> в конце каждой строки. Это стандарт под дос /windows. OS X будет помещать <cr> в конце каждой строки. Однако в Unix/Linux стандарт состоит в том, чтобы просто поставить <lf> в конце строки.

Linux теперь ищет файл /bin/bash<cr> для интерпретации файла, где <cr> - символ возврата каретки, который является допустимым символом файла в Linux. Такой файл не существует. Отсюда и ошибка.

Решение: отредактируйте файл с помощью редактора в Linux и избавьтесь от лишних <cr>. Одним из инструментов, который обычно работает при редактировании файла в Windows, является dos2unix.

Ответ 2

Может ли script использовать новые строки Dos?

Попробуйте запустить dos2unix на нем.

Ответ 3

Похоже, что все было настроено так, чтобы переопределить встроенный export. Это можно сделать с помощью экспортированной функции или встроенной функции enable. Попробуйте положить type export в script для проверки. Если вы устанавливаете BASH_ENV, вы, вероятно, не должны.

Если bash вызывается как sh, он разрешает режим POSIX и не позволяет переопределить export с помощью функции, как того требует POSIX. Аналогично, большинство других оболочек, установленных как /bin/sh, следуют за POSIX в этом и/или не допускают, чтобы среда выполнения script была настолько перепутана, как через импорт функций из среды.

Кстати, script, похоже, предназначен для поиска, т.е. . ./mono-2.6-environment вместо ./mono-2.6-environment.

Ответ 4

Была та же проблема. Используемая грубая сила:

/bin/sh /full/path/to/configure --options

& это сделало трюк

(Конечно, я хотел бы знать, почему)

Ответ 5

Запустили ли вы это (вы упомянули chmod + x)

. /path/to/it

или вот так:

./it

?

У меня есть подозрительное подозрение, что ваш код выполнен в новом процессе, и все, что вы сказали, было потеряно. Следовательно, переменные не будут расширены в вашей текущей оболочке. Однако это не объясняет ошибку плохого интерпретатора, которую вы видели. Я думаю, у вас также есть проблема с терминалом (как в терминале, что вы говорили с cat).

Тот факт, что ваш запрос не сделал то, что сказал:

`PS1="[mono-2.6] \w @` "

Заставляет меня думать, что вы побежали, а не код. Есть разница. Я не мог получить то, что вы отправили, чтобы сломаться.

Ответ 6

что сработало для меня, когда dos2Unix не был в системе, с которой я работал:

sed -i s/{ctrl+v}{ctrl+m}// filename

Ответ 7

Это случается иногда, когда файловая система становится смешной. Попробуйте переместить или переименовать файл. Если вы видите ошибку "Устаревший дескриптор файла", это ваша проблема.

например, случилось у нас с CentOS докер

$ ./test.sh 
-bash: ./test.sh: /bin/bash: bad interpreter: Invalid argument
$ ls -alstr test.sh 
20 -r-xr-xr-x 0 omen omen 17874 Jun 20 01:36 test.sh
$ cp test.sh testcopy.sh
$ ./testcopy.sh
Happy Days

$ mv test.sh footest.sh
mv: cannot move ‘test.sh to ‘footest.sh: Stale file handle
$ rm test.sh 
rm: cannot remove ‘test.sh: Stale file handle

Вы можете скопировать файл и прочитать его. Но не двигайся! И не удаляй это. Может быть, какая-то странная вещь в файловой системе докера.

Решение: пересоздать док-контейнер ИЛИ может быть, диск восстановления файловой системы поможет ИЛИ, конечно, format c: :: -D: -o