in reply to Re^4: Clean smoke-test install for Inline based modules using Inline::MakeMaker
in thread Clean smoke-test install for Inline based modules using Inline::MakeMaker

Er, yes it does. On my machine.

Full console log:

<Reveal this spoiler or all in this thread>

And so do all of the last 6 versions.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?
  • Comment on Re^5: Clean smoke-test install for Inline based modules using Inline::MakeMaker
  • Download Code

Replies are listed 'Best First'.
Re^6: Clean smoke-test install for Inline based modules using Inline::MakeMaker
by syphilis (Archbishop) on Dec 15, 2011 at 12:33 UTC
    Wow ... something weird going on there. If I grab http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/ExtUtils-MakeMaker-6.62.tar.gz by clicking on that link (in the browser), then gzip -d and tar xvf the file, it unwraps into a directory named 'ExtUtils-MakeMaker-6.62' (as expected).

    I think that's the same tarball as wget fetched for you ... so we're left to ponder what's making the difference.
    Is it something that wget does ? or gunzip ? or tar ?

    It's hard to believe that wget could be the culprit ... more likely something that your gunzip or tar is doing.
    And if it's only EU::MM that's afflicted with this condition (and not other source tarballs from CPAN), then it's even more mysterious - and, of course, indicative of there being something unique about the way Schwern bundles up his source tarballs.

    Cheers,
    Rob
[reply]
[d/l]
[select]
      I think that's the same tarball as wget fetched for you ...

      It is exactly the same file as identified by the md5sum.

      more likely something that your gunzip or tar is doing.

      It seems to be something to do with the version of the tar used by the distribution builder that is incompatible with older versions of tar when it comes to untarring.

      As I've now discovered ptar -- it successfully unpacks the very same file that gave me troubles -- and that it is installed with Perl, I'll use that in future. Indeed, I've renamed tar.exe to tar.exe.old and copied ptar.bat to tar.cmd so that if I should forget, I won't have to spend hours working out which files and directories I need to delete as I did this time.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?
[reply]
[d/l]
Re^6: Clean smoke-test install for Inline based modules using Inline::MakeMaker
by Anonymous Monk on Dec 15, 2011 at 12:24 UTC

    Oh yeah, that is a problem with your version of tar/gunzip from http://unxutils.sourceforge.net/

    I had some similar problems with tar from http://gnuwin32.sf.net

    today I'm sucessfully using tar -zxvf from mingw 

    $ tar --version
tar (GNU tar) 1.23

    [download]

    though I have successfully used ptar

    FWIW, as Anonymous Monk I really dislike your usage of spoiler tags instead of readmore tags

[reply]
[d/l]
      FWIW, as Anonymous Monk I really dislike your usage of spoiler tags instead of readmore tags

      Could you explain why?

      I prefer spoilers to readmores because readmores expand automatically whenever anyone views the post.

      • For the casual viewer, this means they download and are forced to view a crap load of information they neither need nor want to view.
      • Anything posted after the readmore is pushed way down the screen, and in many cases will never be seen.

      Spoilers on the other hand allow:

      • the viewer to read the entire post minus the long boring details without scrolling.
      • The casual viewer never needs download, much less read or have to skip over the content.
      • The interested viewer to take in the overall flow and gist of the post *before* choosing whether to view the details.

      I cannot think of any purpose for which readmores are preferable to spoilers.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?
[reply]

        I prefer spoilers to readmores because readmores expand automatically whenever anyone view the post.

        This is the reason.

        I accept the spoiler tags in use of actual spoilers, but I haven't seen a real one in a long time.

        When I click on a node I wish to see it in full.

        Yeah, I guess my dislike stems from my extensive conditioning to click on a node title instead of readmore or spoiler link

        And it turns out I agree with your reasoning :)

        Thanks, I'll have to adjust my conditioning :)

[reply]

In Section Seekers of Perl Wisdom