Home / ubuntu / Questions / 491896
Accepted
BogdanBiv
Asked: 2014-07-05 23:35:34 +0800 CST

.bashrc shebang line reports command not found

  • 772

Tried the following shebang lines:

$ 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 starts with empty line supposedly (the first three characters are invisible):

$ head -n2 .bashrc | od -c
0000000 357 273 277  \n   #   !   /   b   i   n   /   b   a   s   h  \n
$ bash:
: command not found

After that line the bashrc lines are executed normally, so the functionality is NOT affected. However I find this error to be quite annoying.

I hope this post helps someone.

command-line

2 Answers

  1. Your file doesn't start with #!/bin/bash, it starts with the three-byte sequence 357 273 277 (where each byte is typed out in octal; that's ef bb bf in the more usual hexadecimal) is the UTF-8 encoding of the Unicode character U+FEFF ZERO WIDTH NO-BREAK SPACE. Do note the distinction between character endoding (a correspondence between characters or sequence of characters and sequences of bytes, such as UTF-8) and character set (a correspondence between characters and their representation, such as Unicode), because it's important here.

    The character U+FEFF is also called byte-order mark (BOM). This character is used at the beginning of text files encoded in UTF-16. UTF-16 uses a representation based on units of two bytes, and the bytes inside each unit can be in either order: big-endian or little-endian (it just has to be consistent inside one text file). The BOM character is used to indicate the endianness of a file encoded in UTF-16 (the symmetric character U+FFFE is purposefully unassigned, so the first two bytes can only be valid in one of the two possible endiannesses).

    The BOM interpretation of U+FEFF only makes sense in encodings that have a byte order, such as UTF-16. The UTF-8 encoding has no concept of byte order, since characters are encoded in a (variable-size) byte sequence with a well-defined order. Therefore in UTF-8 the byte sequence ef bb bf is just the character U+FEFF which is just another non-ASCII Unicode character.

    Bash, like many other programs, treats all non-ASCII characters as ordinary characters that can appear in strings. For bash, strings include bare words. This has the advantage that bash can work with input in any encoding as long as that encoding is a superset of ASCII, i.e. characters in the ASCII set are encoded as one byte with their ASCII encoding value. UTF-8 is such an encoding. U+FEFF is a zero-width space, and is thus invisible to humans, but it's visible to programs. Programs that interpret their input in Unicode might treat it as a whitespace character, but programs that interpret their input as ASCII plus meaningless non-ASCII characters don't.

    In your file, bash sees an initial sequence of 14 bytes which it parses as ordinary characters: ef bb bf 23 21 2f 62 69 6e 2f 62 61 73 68. The first three encode a U+FEFF in the UTF-8 encoding; bash's parser doesn't care about the encoding and treats them as three ordinary characters. The fourth character # is not a comment-start character because it is not at the beginning of a word. The resulting 14-character word is interpreted as a command name, and there is no command by that name.

    Shell scripts, like most other program text, must be written in an encoding that's compatible with ASCII. Make sure that your editor doesn't add spurious characters such as carriage returns before newlines (the Windows encoding of line endings, but Unix programs treat the carriage return as an ordinary character) or U+FEFF at the beginning. U+FEFF is a byte-order mark only at the beginning of a file encoded in UTF-16 anyway; when it's used at the beginning of a file encoded in UTF-8, it's just a useless space at the beginning. If an editor adds U+FEFF at the beginning of a file in UTF-8, that's a bug.

    In addition to all of this, a shebang line is not useful at the top of .bashrc. While it doesn't cause any harm (the harm here was because you didn't actually have a valid shebang line), it's spurious and potentially confusing. That file is never executed as a standalone script.

    • 8
  2. Best Answer

    Solved the problem by making a backup for .bashrc:

    mv .bashrc ..bashrc
# recreating .bashrc:
touch .bashrc
$ bash # returns no errors !!!

    After editing the .bashrc file with vim, this is its contents:

    head -n2 .bashrc | od -c
0000000   #   !   /   b   i   n   /   e   c   h   o       "   T   e   s
0000020   t   "  \n

    The culprit seem to have been the three invisible characters at the beginning of my .bashrc: "357 273 277". At first I thought these characters belong in my .bashrc file, so I left them there. It will take a while to find which one of my editors corrupts files in this way.

    I hope this post helps someone.

    • 1