Hello!
I think you should use symbols instead. This way you will be able to
order
your params in any order you want when you call the script and avoid
this
kind of check and concentrate on the ‘meat’ of the action.
Alternatively, you could use option parsing and that way pass them in
any
order you wish.
For example: myscript.rb -f filename -c checksum
On Thu Nov 06 2014 at 10:11:41 AM Quentin Leonetti [email protected]
Here’s a demo of OptionParser. OptionParser comes with Ruby.
require 'optparse'
class Arguments
attr_reader :path
attr_reader :sum
def parse(args = ARGV)
OptionParser.new do |opts|
opts.on("-f", "--file PATH", "File path (required)") do |v|
@path = v
end
opts.on("-c", "--checksum SUM",
"MD5 or SHA512 type sum (required)") do |v|
@sum = v
end
end.parse!(args)
unless @path
raise OptionParser::MissingArgument, "--file missing"
end
unless @sum
raise OptionParser::MissingArgument, "--sum missing"
end
rescue OptionParser::ParseError => e
abort e.to_s
end
end
arguments = Arguments.new
arguments.parse
puts "file: #{file}"
puts "sum: #{sum}"
When executed with “-h” or “–help”:
$ ruby /tmp/foo.rb --help
Usage: foo [options]
-f, --file PATH File path (required)
-c, --checksum SUM MD5 or SHA512 type sum (required)
You may want to consider Rubinius. There is a 1.8.7 branch that is
maintained for the express purpose of helping people move to a Ruby with
a modern GC, real threading, Just-In-Time compiler, etc. That branch is
used in production at Enova (a Chicago-based financial firm) who also
employs the main Rubinius author, so its the real deal.
It should be just a drop in replacement. I recommend joining the #rubinius channel on irc.freenode.net and asking around.
I use 1.8.7 with Rails 2.3 because my project managers do not consider
it a
high enough priority issue to allocate developer time to it. I reckon
we’ll
be on that platform for a few more years.
By the way: MRI 1.8.7 is not deprecated, as previously mentioned in this
thread. Actually it is no longer supported. It doesn’t even get
security patches. This happened mid-year:
Your managers may wish to factor in the risk of unfixed security holes
when deciding whether and when to spend the money to upgrade to a
supported Ruby.
I don’t want to take this thread on a tangent but since you asked.
I’d love to upgrade believe you me. We’ve had all the discussions about
security and performance and this and that, but there is no interest
from
the higher ups. We keep promising and selling new things to clients and
there’s a constant urgency to get those promises fulfilled. I get nagged
at
if I spend time writing automated tests. We routinely push new code out
to
production with failing automated tests. It’s embarrassing to talk about
it.
We’re a small company operating on thin margins so we are 100% focused
on
getting new sales, and doing everything we can to get new sales. From a
development point of view it’s not all that much fun.
I don’t want to take this thread on a tangent but since you asked.
I’d love to upgrade believe you me. We’ve had all the discussions about security
and performance and this and that, but there is no interest from the higher ups.
We keep promising and selling new things to clients and there’s a constant urgency
to get those promises fulfilled. I get nagged at if I spend time writing automated
tests. We routinely push new code out to production with failing automated tests.
It’s embarrassing to talk about it.
We’re a small company operating on thin margins so we are 100% focused on
getting new sales, and doing everything we can to get new sales. From a
development point of view it’s not all that much fun.
Leave for a firm that isn’t actively hostile to good development
practices. I’ve been at places with significant management resistance to
upgrading and it made me miserable.
I don’t want to take this thread on a tangent but since you asked.
I’d love to upgrade believe you me.
Yeah, large companies have issues since the larger install base
requires more work. That’s my issue. The OS vendor is on the hook for
security patches.