Greg Hauptmann
7/12/2008 9:36:00 AM
tks xc,
Given I'm a hobbiest programmer I think I'll try to write my linux
backup script in Ruby then. I don't get that much time so sticking to
Ruby for me would be great.
BTW: I'd also posted on the capistrano (which I use) group re this. I
guess if I'm using rsynch however it'll handle ssh under the bonnet
(cf cap's libraries for ssh etc)
Are there any tips re calling unix commands & receiving responses in ruby?
thanks
On 7/12/08, Xeno Campanoli <xcampanoli@gmail.com> wrote:
> Greg Hauptmann wrote:
>> hi,
>>
>> I need to develop some backup scripts for my linux box. I'm ok with
>> Ruby but havn't done bash scripts before.
>
> Bash is a different kind of language, both because it's more devoted to
> handling native unix executables, but also because it's a more primitive
> and older language devoted to doing things in ways they needed to be
> done before the present price/cost of resources.
>
> There are a lot of things you can do much more efficiently in Bash, and
> in far fewer lines. Also, in Sysadmin land, you may find more of the
> people managing your production boxes will know Bash than Ruby.
> Probably far more. In my shop, practically everyone is still refusing
> to use Ruby and they want me to write anything I can in Bash, when it's
> at all practical. To a certain extent I think this kind of request has
> reasonable roots and should be taken into account.
>
> That all being said, and despite the fact that Ruby programs can be
> longer, Ruby programs can be much more readable, IMHO, than Bash
> scripts, especially when the complexity of the program increases beyond
> a few hundred lines of code. Now I have several Bash scripts that
> include libraries of Bash functions and the entire things are well over
> a thousand lines, and these are still reasonable pieces of software.
> Most things that size make me think of Ruby as the best long term,
> maintainable way to program. The reasons, again IMHO, include:
>
> 1. A lot of general facilities which allow for clean solutions
> that would be ugly in Bash. For instance, I recently ran into a
> Bash script that had sequences of over 10 sed commands to decode
> %nn embedded strings from an HTTP query string. Ruby has native
> methods for this that you can depend upon. When you write your
> own, thats gonna be delicate code subject to getting trashed in
> some quick vi edit.
>
> 2. Class organization, which I like to do when the programmed
> activity is best illustrated with that kind of organization, is
> nicely formalized in Ruby, and requires thought and jury-rigging
> in Bash.
>
> 3. Loops are very flexible in Ruby. On the other hand, in Bash
> they may sometimes be more concise.
>
> 4. Structures in Ruby are generally clearer and more readable:
>
> if [[ x != 'y' ]]; then
> somefunction $arg1 $arg2
> else
> echo "ERROR: blek $myevidence"
> exit 1
> fi
>
> vs Ruby
>
> if x != 'y' then
> somemethod(arg1,arg2)
> else
> raise Exception, "ERROR: blek #{myevidence}"
> end
>
> The difference may not send you, but the extra little tick marks
> and such can be a big time cost when it comes to debugging and
> maintenance. Interpolation, as evidenced above, actually uses
> more, but is more clear and flexible, and is always the same.
>
>
>>
>> Is ruby up to replacing bash shell scripts for this? (eg calling
>> commands, eg rsynch, getting responses etc?
>
> Yes, but it's up to you whether you want to spend the time. I have a
> class I call FlatAccess which has methods like:
>
> MYUSER=myusername
> SUDOPART = "sudo -u #{MYUSER}"
>
> def FlatAccess.sudo(shellcmd)
> `#{SUDOPART} #{shellcmd}`
> end
>
> But of course you can just state the command directly like:
> result = `sudo -u myusername #{shellcmd}`
> ---snip---
>
> Now all that being said, there's also something called capistrano that
> does this kind of thing in Ruby for you, so if you're doing that a lot,
> it is worth looking into capistrano. Perhaps I'll do that myself some
> time soon....
>
> There are a lot of other facilities in native Ruby to do system stuff,
> so the more encompassing answer is: yes.
>
> One thing I did recently which was interesting was to use pipes and
> threads to collect output from stderr and stdout at the same time from a
> shell execution of curl.
>
> xc
>
>
>
>>
>> Thanks
>>
>>
>
>
>