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