How to deal with bash errors when trying to run it?

Question

Imagine a script which has standard bash linux scripting (running on SUSE linux). Like this:

#!/bin/bash #version=1.0 #Some other text command #-------Comment Changeversion=2.0 ... ... 

Is there any way how to automatically deal with errors or at least say a custom message? For example I will try to run the script but it says:

-bash: ./filename.sh: Keine Berechtigung 

So I have to add rights to the file - is there any way how to add rights to this file automatically when trying to run it or at least add "custom message" like "do chmod +x filename.sh"?

Or if I have different encoding:

/bin/bash^M: bad interpreter: 

Can the script itself run this command:

sed -i -e 's/\r$//' filename.sh 

Or at least say it in error message?

Answer 1

I replicated your problem:

# cat /tmp/tmp #!/bin/bash echo SCRIPT BASH EXECUTED # file /tmp/tmp /tmp/tmp: Bourne-Again shell script, ASCII text executable, with CRLF line terminators # /tmp/tmp -bash: /tmp/tmp: /bin/bash^M: bad interpreter: No such file or directory 

The following command solves the problem for the bash session where the command is executed:

# trap 'file $BASH_COMMAND |grep -qs "Bourne-Again shell script, ASCII text executable, with CRLF line terminators" && sed -i -e "s/\r$//" $(echo $BASH_COMMAND|cut -d" " -f1) && echo "DOS FORMAT BASH SCRIPT, SED EXECUTED" && $BASH_COMMAND' ERR # /tmp/tmp testArgument1 testArgument2 -bash: /tmp/tmp: /bin/bash^M: bad interpreter: No such file or directory DOS FORMAT BASH SCRIPT, SED EXECUTED SCRIPT BASH EXECUTED # /tmp/tmp testArgument1 testArgument2 SCRIPT BASH EXECUTED 

The command trap is valid only for your current session put it in /etc/profile /etc/profile.d or some similiar configuration file to make it persistent to all bash session.

I tested it only with bash-4.2.46-19.el7.x86_64 on RHEL 7 system

Answer 2

The question has been downvoted without anyone explaining why (shame on you downvoters!) So I'll explain why I'm going to downvote (yes this should be a comment, but its a bit too big).

While these may seem like irrelevant obstacles to your objective of getting the code to run, they exist for good reason. Running code on a computer is inherently dangerous. Obviously computers aren't much use unless they do run code, but its important that they run the right code. Implementing an automatic fix for common errors has 2 big impacts:

• it makes it much easier for someone attacking your computer to get their code executing on your machine
• sometimes people mistype commands - maybe your magical script fixing system will repair and execute the wrong code

Further, sometimes the error is not what it appears to be - you might have filesystem permissions to access a script, but it might be on a noexec mounted filesystem, or the access may be blocked by SELinux. Or Apparmour. Or GRSecurity.

One specific error message does not equate to one specific resolution.