What about 'rubocop' rules?

The first one I really don’t understand, the shebang I used is all over the internet, and my .rb script executes.

Don’t understand the second offence. again, this shebang seems to be the way to go.

The next three are the same. should I follow the rule ? is there a config file I can edit like with ESLint ?

1 Like


The first offense seems like you didn’t make the Introduction_to_Ruby.rb script into an executable hence the missing execute permission. To make it into an executable, type chmod u+x ./Introduction_to_Ruby.sh

I was able to run it in the terminal, doesn’t that mean it 's already executable ?

If you can do ./Introduction_to_Ruby.rb and see it runs, then you are right. Otherwise, it’s most likely not according to rubocop.

Running ls -l ./Introduction_to_Ruby.rb should give you more information about the permissions of the file.

I guess there is difference whether you run the script with ./ or pass it to the Ruby interpreter.

So I believe you’ve already figured it out?

I have a grip on it now. just not sure whether to use ‘ruby xxx.rb’ or ./
Is it just matter of preference ?

If you are going to distribute the Ruby script to others as a standalone program, then using ./ would be preferred as the user won’t have to know how and which program to use to run the script.

For example, irb is actually a Ruby script and you can run it with calling irb instead of ruby irb. Also, a big advantage over this, you could make sure the script to only use a specific program to run the script or it’ll fail to run (which is good compared to the program running fine early on but breaks down a few minutes later due to incompatible ruby version in some part of your code)

For example, whether the script want to call ruby or jruby, zsh or bash etc…, is depending on the shebang line string in the script.

Another thing is, if you put the executable script into a directory which is known by $PATH environment variable, you can invoke it from anywhere in your system using my_ruby_script_or_similar instead of /path/to/my_ruby_script_or_similar every time which can be tedious and hard to remember the path.

Also, if you are interested in finding out which other executable scripts you have in your system, I made this quick one liner to fulfill your curiosity -

for i in /usr/bin/*; do file $i | awk -F: '{print$1,$2}' | awk '{ if($2!="symbolic"&&$2!="ELF"&&$2!="setuid"&&$2!="setgid") printf"%s        %s\n",$1,$2}' ; done

Above would print the path to the scripts in /usr/bin/* and the programming language type based on the shebang string they use.

For example -

$ for i in /usr/bin/*; do file $i | awk -F: '{print$1,$2}' | awk '{ if($2!="symbolic"&&$2!="ELF"&&$2!="setuid"&&$2!="setgid") printf"%s        %s\n",$1,$2}' ; done
/usr/bin/xfce4-set-wallpaper        Bourne-Again
/usr/bin/xfhelp4        POSIX
/usr/bin/xflock4        POSIX
/usr/bin/xml2-config        POSIX
/usr/bin/xml2odf        Python
/usr/bin/xml_grep        Perl
/usr/bin/xml_merge        Perl
/usr/bin/xml_pp        Perl
/usr/bin/xml-resolver        Bourne-Again
/usr/bin/xml_spellcheck        Perl
/usr/bin/xml_split        Perl
/usr/bin/xml-xparse        Bourne-Again
/usr/bin/xml-xread        Bourne-Again
/usr/bin/xorg-backtrace        Perl
/usr/bin/xsubpp        Perl
/usr/bin/xzdiff        POSIX
/usr/bin/xzgrep        POSIX
/usr/bin/xzless        POSIX
/usr/bin/xzmore        POSIX
/usr/bin/xznew        POSIX
/usr/bin/yacc        POSIX
/usr/bin/yupdate        Ruby

When I give a script the ‘chmod u+x xxx.rb’ treatment, doesn’t that just effect things locally ? how does the script file get modified to the point of other people running it on their end ?

Usually, you supply a script for them to run or an instruction to let the user know how to make it into an executable