Ruby 1.8.x
Programmer 0.0.2
The script takes two arguments; a file and an md5 or sha512 type sum.
What I want is to avoid having to put things in any certain order.
Is there a better way to do this?
if File.file?(ARGV[0])
then
file = ARGV[0]
sum_given = ARGV[1]
else
file = ARGV[1]
sum_given = ARGV[0]
end
Thanks!
Leam
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.
I hope my answer was helpful here ,
Have a nice day,
Quentin
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]
One of the big questions is why you’re using 1.8 still. It’s deprecated.
On Nov 6, 2014, at 15:05, Brandon W. [email protected] wrote:
One of the big questions is why you’re using 1.8 still. It’s deprecated.
How does that matter when you’re just learning the language?
There were significant changes from 1.8 to 1.9. A better question is why
you aren’t upgrading. Learning on an old version is a bad idea.
On Nov 6, 2014, at 10:06, leam hall [email protected] wrote:
Ruby 1.8.x
Programmer 0.0.2The script takes two arguments; a file and an md5 or sha512 type sum.
What I want is to avoid having to put things in any certain order.
I think that’s a bad requirement.
Is there a better way to do this?
if File.file?(ARGV[0])
then
file = ARGV[0]
sum_given = ARGV[1]
else
file = ARGV[1]
sum_given = ARGV[0]
end
My take:
file = ARGV.shift
sum = ARGV.shift
file, sum = sum, file if File.file? sum
Again, I think this is a bad idea.
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)
When executed with arguments:
$ ruby /tmp/foo.rb --file /tmp/foo --sum 123
path: /tmp/foo
sum: 123On 11/06/14 18:25, Brandon W. wrote:
There were significant changes from 1.8 to 1.9. A better question is why
you aren’t upgrading. Learning on an old version is a bad idea.
The servers I support are on a mix of 1.8.5 and 1.8.7. Whatever I write
needs to work on them.
Good question though. It does kinda stink being in the dark ages.
Leam
On Fri, Nov 7, 2014 at 12:14 AM, Ryan D. [email protected]
wrote:
My take:
file = ARGV.shift sum = ARGV.shift file, sum = sum, file if File.file? sum
Or:
file, sum = ARGV
file, sum = sum, file unless test ?f, file
Again, I think this is a bad idea.
Yeah, rather use an option or fix the order.
Kind regards
robert
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.
cr
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.
The world is complicated.
On Thu, Nov 6, 2014 at 6:25 PM, Brandon W. [email protected]
wrote:
How does that matter when you’re just learning the language?
–
Besnik Ruka – Software Engineer at IData Inc.
703-378-2110 x 809
Yup, we had some discussions around that at work. We invested in
upgrading Ruby because:
security concerns
no ability to retain and recruit when using a 5 year old platform
performance gains
Really nice being on the latest versions. Open a new rails console and
it just pops right up!
It is indeed complicated.
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:
https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/
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.
Wayne C.
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.
On Fri, Nov 7, 2014 at 11:09 AM, Tom C.
[email protected]
On Nov 7, 2014, at 11:59, bruka [email protected] wrote:
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.
On Fri, Nov 7, 2014 at 11:59 AM, bruka [email protected] wrote:
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.
Leam
On Fri, Nov 7, 2014 at 9:48 PM, Robert K.
[email protected] wrote:
file, sum = ARGV
file, sum = sum, file unless test ?f, file
just joining the fun (w robert and ryan) in the hope to make the op
happy. just happy : )
ARGV.reverse unless File.file? ARGV.first
best regards
-botp
Hmm…I wanted to make the parameters movable to give me a reason to
test input as well as delay having to also figure out argument
processing. 
Positional and non-flagged arguments are less desirable but I only have
so many brain cells.
Leam
On Sat, Nov 8, 2014 at 12:02 PM, Leam H. [email protected] wrote:
Hmm…I wanted to make the parameters movable to give me a reason to test
input as well as delay having to also figure out argument processing.Positional and non-flagged arguments are less desirable but I only have so
many brain cells.
And that is also true of users of your program. Often less choices are
better.
Kind regards
robert
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs