Команда .bashrc shebang line reports не найдена
Пробовал следующие строки shebang:
$ head -n2 .bashrc | od -c
0000000 357 273 277 # ! / b i n / b a s h \n
$ bash
bash: #!/bin/bash: No such file or directory
.bashrc начинается с пустой строки предположительно (первые три символа невидимы):
$ head -n2 .bashrc | od -c
0000000 357 273 277 \n # ! / b i n / b a s h \n
$ bash:
: command not found
После в этой строке строки bashrc выполняются нормально, поэтому функциональность НЕ затрагивается. Однако я нахожу эту ошибку довольно раздражающей.
Надеюсь, этот пост кому-нибудь поможет.
2 ответа
Решенный проблема путем создания резервного копирования для .bashrc:
mv .bashrc ..bashrc
# recreating .bashrc:
touch .bashrc
$ bash # returns no errors !!!
После редактирования .bashrc файла с энергией, это - ее содержание:
head -n2 .bashrc | od -c
0000000 # ! / b i n / e c h o " T e s
0000020 t " \n
преступник, кажется, были три невидимы символы в начале моего .bashrc: "357 273 277" . Сначала я думал, что эти символы принадлежат моего .bashrc файла, таким образом, я оставил их там. Это будет требовать времени для нахождения, какой из моих редакторов повреждает файлы таким образом.
я надеюсь, что это сообщение помогает кому-то.
Ваш файл не запускается с #!/bin/bash, он запускается с трехбайтовой последовательности 357 273 277 (где каждый байт выводится в восьмеричном; это - ef bb bf в более обычном шестнадцатеричном), кодировка UTF-8 символа Unicode НУЛЕВАЯ ШИРИНА U+FEFF ПРОСТРАНСТВО без повреждений. Действительно отметьте различие между символьный эндозвон (корреспонденция между символами или последовательностью символов и последовательностями байтов, такими как UTF-8) и набор символов (корреспонденция между символами и их представлением, такими как Unicode), потому что это важно здесь.
символ U+FEFF также называют метка порядка байтов (BOM) . Этот символ используется в начале текстовых файлов, закодированных в UTF-16. UTF-16 использует представление на основе единиц двух байтов, и байты в каждой единице могут быть в любом порядке: обратный порядок байтов или прямой порядок байтов (это просто должно быть последовательно в одном текстовом файле). Символ BOM используется для указания на порядок байтов файла, закодированного в UTF-16 (симметричный символ U+FFFE является целеустремленно неприсвоенным, таким образом, первые два байта могут только быть допустимыми в одном из двух возможных порядков байтов).
интерпретация BOM U+FEFF только имеет смысл в кодировке, которая имеет порядок байтов, такой как UTF-16. Кодировка UTF-8 не имеет никакого понятия порядка байтов, так как символы кодируются в (переменный размер) последовательность байта с четко определенным порядком. Поэтому в UTF-8 последовательность байта ef bb bf является просто символом U+FEFF, который является просто другим символом Unicode неASCII.
Bash, как много других программ, рассматривает все не - символы ASCII как обычные символы, которые могут появиться в строках. Для удара строки включают пустые слова. Это имеет преимущество, что удар может работать с входом в любом кодировании, пока то кодирование является надмножеством ASCII, т.е. символы в наборе ASCII кодируются как один байт со своим значением кодирования ASCII. UTF-8 является таким кодированием. U+FEFF является пространством нулевой ширины и таким образом невидим для людей, но это видимо к программам. Программы, которые интерпретируют их вход в Unicode, могли бы рассматривать его как пробельный символ, но программы, которые интерпретируют их вход как ASCII плюс бессмысленные символы неASCII, не делают.
В Вашем файле, удар видит начальную последовательность 14 байтов, которые это анализирует как обычные символы: ef bb bf 23 21 2f 62 69 6e 2f 62 61 73 68. Первые три кодируют U+FEFF в кодировке UTF-8; синтаксический анализатор удара не заботится о кодировании и рассматривает их как три обычных символа. Четвертый символ # не является начальным символом комментария, потому что это не в начале слова. Получающееся слово с 14 символами интерпретируется как название команды, и нет никакой команды тем именем.
Сценарии оболочки, как большая часть другого текста программы, должны быть записаны в кодировании, это совместимо с ASCII. Удостоверьтесь, что Ваш редактор не добавляет побочные символы, такие как возвраты каретки перед новыми строками (кодирование Windows окончаний строки, но программы Unix рассматривают возврат каретки как обычный символ), или U+FEFF вначале. U+FEFF является меткой порядка байтов только в начале файла, закодированного в UTF-16 так или иначе; когда это используется в начале файла, закодированного в UTF-8, это - просто бесполезное пространство вначале. Если редактор добавляет U+FEFF в начале файла в UTF-8, это - ошибка.
<час> В дополнение к все это, строке хижины не полезно наверху .bashrc. В то время как это не наносит ущерба (вред здесь был то, потому что у Вас на самом деле не было допустимой строки хижины), это побочно и потенциально сбивает с толку. Тот файл никогда не выполняется как автономный сценарий.