Forum: Ruby Re: Archive::Tar uncompress question

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Berger, Daniel (Guest)
on 2006-04-07 00:05
(Received via mailing list)
> guess was an unforseen use.  I need to simply unpack an
>       when /\.t(ar\.)?gz/
> which works fine for what I need *if* I redefine
>
> It seems that @compressed_archive_name can only be set if one
> first compresses an archive.  I don't need to do that here -
> I just need to uncompress an already-existing archive.
>
> Should I be redefining this method or should the package be
> changed to the (my) expected behavior?  Or have I just
> totally missed the usage here?  Has anyone else run up against this?
>
> - Dimitri

Hi Dimitri,

It basically boils down to a case of unexpected usage.  The assumption
is that you're creating (or going to create) an archive when you use
Archive::Tar.new.

You are, of course, free to redefine uncompress_archive, but rather than
patching the lib itself, I recommend taking advantage of Ruby's open
classes:

# Somewhere in your code:
module Archive
   class Tar
      def uncompress_archive(program="gunzip")
         @compressed_archive_name = @archive_name unless
@compressed_archive_name

         cmd = "#{program} #{@compressed_archive_name}"

         Open3.popen3(cmd){ |prog_in, prog_out, prog_err|
            err = prog_err.gets
            if err
               raise CompressError, err.chomp
            end
            @compressed_archive_name = nil
         }
         self
      end
   end
end

I suppose I could add class methods that would do the sort of thing
you're trying to do.  Or, you could add your own class method.

Also note that I'll probably be changing the name to
Archive::Tar::External in the future.

Regards,

Dan
Dimitri A. (Guest)
on 2006-04-07 00:32
(Received via mailing list)
Hi Dan,

On 4/6/06, Berger, Daniel <removed_email_address@domain.invalid> wrote:
> It basically boils down to a case of unexpected usage.  The assumption
> is that you're creating (or going to create) an archive when you use
> Archive::Tar.new.
>

I actually chose Archive::Tar over Archive::Tar::Minitar because I
needed something quick-and-dirty that could handle all the kinds of
archives in my original post.  My application only deals with the
un-packing of these archives - the originals stay where they are, and
my app doesn't create them.

> You are, of course, free to redefine uncompress_archive, but rather than
> patching the lib itself, I recommend taking advantage of Ruby's open
> classes:
>
> # Somewhere in your code:

<snip>

This is actually what I have done.  I just presented it in
pseudo-patch form for conciseness, and perhaps to convince you that it
really isn't an error, but could be handled differently. :)

> I suppose I could add class methods that would do the sort of thing
> you're trying to do.  Or, you could add your own class method.

A la

module Archive
  class Tar
    attr_accessor :compressed_archive_name
  end
end

?

That still involves redefinition.  I try to avoid that with
non-standard-lib libraries.  You never know when the name is going to
change. :)

> Also note that I'll probably be changing the name to
> Archive::Tar::External in the future.
>

Ok, thanks.  Interesting naming discussion this started...

- Dimitri
Daniel B. (Guest)
on 2006-04-07 01:21
(Received via mailing list)
Dimitri A. wrote:
> archives in my original post.  My application only deals with the
>
>   class Tar
>     attr_accessor :compressed_archive_name
>   end
> end
>
> ?
>
> That still involves redefinition.  I try to avoid that with
> non-standard-lib libraries.  You never know when the name is going to
> change. :)

I thought about that, too.  I don't see the harm, really.  If you want
to
uncompress an existing archive then it would just be a matter of
assigning to
that attribute first, then uncompressing.

What makes more sense and/or which would you prefer?

t = Tar::External.new
t.compressed_archive_name = 'somefile.tar.gz'
t.uncompress

# or

Tar::External.uncompress('somefile.tar.gz')

The advantage to the latter is that it's simpler.  The drawback is that
it
wouldn't return an object.

Come to think of it, I should probably manually define
compressed_archive_name=
like so in order to ensure other instance variables are set properly:

How about this patch:

# Assign a compressed archive name.  This autogenerates the archive_name
# based on the extension of the name provided, unless you provide the
# extension yourself.  If the extension is '.tgz', then the base of the
# name + '.tar' will be the new archive name.
#
# This should only be used if you have a pre-existing, compressed
archive
# that you want to uncompress.
def compressed_archive_name=(name, ext=File.extname(name))
    if ext == ".tgz" || ext == '.TGZ'
       @archive_name = File.basename(name, ext) + '.tar'
    else
       @archive_name = File.basename(name, ext)
    end
    @compressed_archive_name = name
end

Thoughts?

Dan

PS - Perhaps we should continue this over on the Shards project page
under
"Open Discussion".  See http://www.rubyforge.org/projects/shards.
Dimitri A. (Guest)
on 2006-04-07 10:38
(Received via mailing list)
On 4/6/06, Daniel B. <removed_email_address@domain.invalid> wrote:

> The advantage to the latter is that it's simpler.  The drawback is that it
> wouldn't return an object.

I prefer the latter.  Would you really need an object returned if
you're just uncompressing an archive?

> Come to think of it, I should probably manually define compressed_archive_name=
> like so in order to ensure other instance variables are set properly:
>
> How about this patch:

<snip>

> Thoughts?

Looks good.  I would still change the "unless" clause in the
uncompress_archive method, in addition to this patch.   Then both
methods of uncompressing could be supported.

> PS - Perhaps we should continue this over on the Shards project page under
> "Open Discussion".  See http://www.rubyforge.org/projects/shards.

I'm happy with where this thread has ended up.  If you feel more
discussion is necessary, let me know, and I'll follow you over there.

- Dimitri
Daniel B. (Guest)
on 2006-04-07 20:51
(Received via mailing list)
Dimitri A. wrote:
> On 4/6/06, Daniel B. <removed_email_address@domain.invalid> wrote:

<snip>

> - Dimitri
Ok, cool.  I've renamed everything and put a new release out.

Thanks for the feedback.

Dan
Dimitri A. (Guest)
on 2006-04-07 23:57
(Received via mailing list)
On 4/7/06, Daniel B. <removed_email_address@domain.invalid> wrote:

> Ok, cool.  I've renamed everything and put a new release out.

Great!  Thanks, Dan.  I'll put those new methods to work on Monday.

- Dimitri
This topic is locked and can not be replied to.