When I unzip a file and give the file executable permission and run it, I get:
axel.sh: /bin/bash^M: bad interpreter: No such file or directory
I examined the file with vim and see no ^M anywhere. I tried to search on that and got pattern not found.
The retaining directory (user) is: drwxr-xr-x
The /bin/bash file shows the same size for ls -lt, ls -lc, & ls -ltu
The ls -ltu does show today's date but that is access time.
The other options for ls have dates of 2011 and 2012.
Anyone know of my stupid dog trick I did to myself?

Maybe the file has been created in Windows and ^M is a shortcut for the sequence \r\n, that is the carriage-return/newline used by Windows as line terminator. In vim you can see them by typing the command
and you can remove them by means of
then write and quit. In alternative you can try the linux command:
Hope this helps!

1 members found this post helpful.

vim recognizes ^M automatically and will hide it.
You can use the command file to check if it has ^M chars.
Also you can use od -xc <filename> to look into it.

2 members found this post helpful.

It is important to note that it is not the act of unzipping and making it executable that adds the offending EOL character, those are already in the file.

I agree with astrogeek & pan64 that is the normal situation. Not here tho.
I checked the unzipped file with vim after unzipping. NO ^M's.
After chmod +x axel.sh and run then I get:
bash: ./axel.sh: /bin/bash^M: bad interpreter: No such file or directory
I again check it with vim and again not ^Ms.
That is why I checked /bin/bash because it said "bad interpreter" and from #1 the size is consistent.
I can run other scripts so unless it is seeing something before it executes that is not in other scripts the interpreter is OK.
I could reinstall the bash interpreter but don't think that is a solution due to no ^M following the inspection and knowing EOLs are not showing up.
PAN64 --THANKS!!
I did run UR suggestion.
It appears it was built under dos BUT vim did not show carriage return and new line.
Had not had this problem when unzipping this file before so this was the surprise. Strange.

Hm. I never told you that is the normal situation. Have you tried od -xc? I do not think bash itself is not ok, I still think there is a problem in your file, the first line contains some "strange" chars after the h.

Well, I assure you that...
... is not happening (unless maybe you are running Ballmer Linux ).

The odd characters are in the file. And I agree with pan64, your bash is OK, it would be silly to reinstall.

What is the output of

Or could you open it in vim and convert to hexadecimal

... and post the first couple of lines.

The ^M's may not be visible in vim depending on configuration, so don't get hung up on the fact that you didn't see them.

1 members found this post helpful.

As everybody else has pointed out - the 'CR' is allready there - it has _not_ been caused by unzipping/moving.
Also, bash and vi (and many others for what I know) silently ignores the 'CR'. If you had run: you probably would've been ok.

Here's a li'l example:All the test*.sh looks _exactly_ the same in 'vi' unless you use the appropriate switches

1 members found this post helpful.