Can't find a strip option (now: Drush suggestion)

Yes it does. You have my green light

Ok, this doesn't work - I don't have --strip-components. But otherwise, I updated it to head.

YES! After a weekend of work, I present a robust unpacking script. Run drush unpack-test to test all 12 tests or drush unpack-test [number] to test just one.

Basically, my goal was to create an unpacking script that took (1) a filename, (2) a destination directory, (3) a tmp directory and then unpacked the filename into the destination dir. If you read the code, in _run_test, a destination directory is created and a file to put in to make sure it's not outright overridden, and then it hands it off to the unpacking class.

Also, I had to resort to extreme ugliness to get unzip working in some cases.

Here's a --debug of the worst-case scenario. Take note of unzip -l -> unzip -d -> mv -> tar -c -> tar -t -> tar -x

$ drush unpack-test 12 --debug
- snip -
Executing: unzip -l 'test12.zip' [0.16 sec, 3.39 MB]                [notice]
  Archive:  test12.zip
    Length     Date   Time    Name
   --------    ----   ----    ----
          9  06-19-10 10:55   te.st/test
         25  06-19-10 10:55   te.st/test.txt
   --------                   -------
         34                   2 files
Executing: mkdir -p './tmp/__unzip__' [0.17 sec, 3.39 MB]                                                        [notice]
Executing: unzip 'test12.zip' -d './tmp/__unzip__' [0.18 sec, 3.4   [notice]
MB]
  Archive:  test12.zip
   extracting: ./tmp/__unzip__/te.st/test
    inflating: ./tmp/__unzip__/te.st/test.txt
Executing: rm 'test12.zip' [0.19 sec, 3.4 MB]                       [notice]
Executing: mv './tmp/__unzip__/te.st' './tmp/__unzip__/test12' [0.2 sec, 3.4 MB]                                 [notice]
Executing: tar -c -C './tmp/__unzip__' -f './tmp/__archive__.tar' 'test12' [0.22 sec, 3.4 MB]                    [notice]
Executing: rm -r './tmp/__unzip__' [0.23 sec, 3.4 MB]                                                            [notice]
Executing: tar -tf './tmp/__archive__.tar' [0.24 sec, 3.4 MB]                                                    [notice]
  test12/
  test12/test
  test12/test.txt
Executing: man tar | grep strip-component [0.26 sec, 3.4 MB]                                                     [notice]
Executing: tar --help | grep strip-path [0.43 sec, 3.4 MB]                                                       [notice]
        --strip-path=NUM         strip NUM leading components from file names
Executing: tar -x --strip-path 1 -C './test12' -f './tmp/__archive__.tar' [0.45 sec, 3.4 MB]                     [notice]
Executing: rm './tmp/__archive__.tar' [0.46 sec, 3.4 MB]                                                         [notice]
- snip -

latest round of brokenness

Patch is growing...

w/ test. still growing...

YESSS IT WORKS!

This should fix bzr.

Tested with core, with and without --working-copy.

great thanks, will commit in a moment. What repo are you pulling from and what .make file code? I'd like to turn this into a test.

Here's the make file I was testing with:

core = 6.x
; Pressflow
projects[pressflow][download][type] = Bzr
projects[pressflow][download][url] = "https://code.launchpad.net/~pressflow/pressflow/6"
projects[pressflow][type] = "core"

awesome, thanks

Hi guys,

I hate to re-open a nicely fixed issue, but it looks like I'm having issues that are related to this patch.

Running drush make on my make file I'm getting the following error:
"Unable to find a strip option in your version of tar"

Full output of my drush make command can be found at http://pastebin.com/BRv4bZsL

Hope you can help.

Cheers,
Decipheed.

ok, putting on my list - need to use cp -fn

Just adding my push here; the current code doesn't work for me at all. My `tar` binary has the "--strip-components" option which this won't auto detect at all. I need to manually set a `--strip-option=components` to drush make working again. I'm all for the switch to `cp`, I think grep'ing man pages is just asking for trouble.

Same for me, I'm on a mac and man tar | grep strip-component returns nothing even though the flag is valid, probably because it's bold (so it's wrapped in formatting tags which mess up the string lookup).
Running man -t tar | grep strip-component "works" by exposing all the formatting tags, but I agree with jmiccolis that man|grep is not a reliable method.

For OSX users, the attached patch seems to fix the problem, but it might screw up other platforms.

@thebuckst0p, this patch worked for me on osx.

I'm a terminal newb, but the 'col' command would also work:
man tar | col -b | grep strip-component

I don't know what effect either approaches has on different systems.

hunmonk: I disagree - I think that if the tar --strip format worked for everything, it would be a good solution, however given the fact that I have to use cp -rn in many cases anyway (git, bzr, .zip files, etc), I don't think we'd lose anything by using that for tar as well.

hunmonk: I disagree - I think that if the tar --strip format worked for everything, it would be a good solution, however given the fact that I have to use cp -rn in many cases anyway (git, bzr, .zip files, etc), I don't think we'd lose anything by using that for tar as well.

Additionally, detecting the operating system is a no-go. For example, on Mac OS X, you may have the system-installed version, or the version from fink, both of which have different --strip options.

This is indeed my case - I've got the bsdtar `/usr/bin/tar`, GNU tar in `/sw/bin/tar`, and still another version of GNU tar in `/opt/local/bin/tar`. So on my system it's quite necessary to look at which tar binary is in use.

If we could detect which version tar we had and from that determine which option to use that could work - but they we may be in a position of only supporting certain versions of tar. A quick survey of the various versions may tell whether this is workable.

The patch in #27 worked for me too. I'm running a fresh install of 6.x-2.0-beta8.

fixed again...

I don't want to reopen this, but I did run into this issue on linux. I am running a minimal install of 10.04 (use to be JEOS). It doesn't include man, as a result I ran into this issue. So I installed man and everything worked fine relating to this issue.

The dev version doesn't ever call man.

sorry, there something realy realy going wrong.

Drupal (and its modules) should work on any OS with php.

The conclusion of this requirement (http://drupal.org/requirements) is, that there should be no dependencies to OS specific tools.

So - what solution offers php for such cases?

have a look at http://pear.php.net

and you'll find packages like

http://pear.php.net/package/Archive_Tar
or http://pear.php.net/package/File_Archive

so imho these packages could solve a lot of problems.

(and it is legitimate to suppose that it is easier to install a pear package, than eg. a tool to extract tar - files via commands on e.g. windows).

best
Thomas

(working with ubuntu)

Slackware 12.0, tar 1.16:

• man page does not have strip-component(s).
• --help does not have strip-path, but does have strip-components.

I hacked drush_make to change strip-path to strip-components and changed strip_option to components. The --help docs said to put an = sign for key=value instead of a space.

This worked for me.

Edit: I'm not changing the status even though I feel like it should change to needs work. This really isn't a viable solution.

I'm getting this:

$ drush make only-core.make 
Make new site in the current directory? (y/n): y
Project information for drupal retrieved.                                                                                                                                           [ok]
drupal downloaded from http://ftp.drupal.org/files/projects/drupal-6.19.tar.gz. [ok]
Unable to find a strip option in your version of tar                            [error]
An error occurred at function : drush_drush_make_make                           [error]
$

My makefile is as simple as it can be:

core = 6.x
projects[] = drupal

Anyway, it seems it's not an "error", since all the files seem to be extracted properly. Attached is a patch which works this around, though I know it's not the proper solution.

On Mac OS you may use as workaround:

drush make --strip-option=component example.make example

[edit] Sorry, I overlooked that this was already mentioned in #26.

@ositoblanco: Is it possible to add this to an rc file or something if I don't want to type this much on every drush make call?

This was fixed in the latest beta. the strip-component option is no longer used. the patch is against an outdated version of drush make

For those reading this, the problem has been fixed in CVS (not in beta-8 as available on the project page).

To download the latest version (dev releases are not enabled for this project) you need to run the following:

cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d drush_make -r DRUPAL-6--2 contributions/modules/drush_make/

It took me a while to find as this bug was marked as closed, so I'm going to re-open this in the hope that the maintainer releases a new beta or enables dev releases for the project. Thanks Dmitri :)

Sorry, yeah. We're currently sprinting on this beta and should be done in a few days.

Perhaps related, perhaps not:
Drupal Aegir alpha13 install script has errors on my MacOS 10.5 powerpc:

  Unable to find a strip option in your version of tar [error]

Aegir install script downloads a file 'drush_make.download.inc' contains:

  protected function unpackTar() {
  ...
      // Detect whether the user uses --strip-path or --strip-components
      $strip_option = drush_get_option('strip-option', FALSE);
      if (!$strip_option) {
        drush_shell_exec("man tar | grep strip-component");
        ...
        drush_shell_exec("tar --help | grep strip-path");

Both my native tar and Gnutar from MacPorts have the --strip-components option, but neither man page refers to it. Yes that's annoying, but shouldn't the Aegir script only check "tar --help" in the first place, and not rely on the man page??

Should I report this to the Aegir team, or do I misunderstand something? (It's nice when things "just work" out of the box.)

...and sorry if this is the same generic error reported above. I'm unsure if the fix mentioned earlier also fixes this Aegir instance, or whether another set of patching is required in this case.

...the CVS patch mentioned above fixes the Aegir problem. Drush make was mistakenly not in my drush path when I ran the install script.

this is also fixed in the latest -dev

Perhaps the launch script could check an environment variable for the php path, before trying to find it automatically? I have both MAMP and XAMPP installed, but each environment should use only its own php for Drush. Setting a bash alias doesn't always work, as some scripts (like Aegir install) do a `which drush` which doesn't catch aliases.

export DRUSH_PHP='/Applications/XAMPP/xamppfiles/bin/php'

Great that you soon will be releasing a new beta as mentioned in #46.

FYI the patch in #27 worked great for me as well, I am on Mac OS X 10.6.

Thanks dmitrig01!

Sorry, this is isn't working for me. The drupal core downloads OK but when it tries to download contributed modules it gives the error "Unable to find a strip option in your version of tar."

I'm so confused. I'm using beta9. Am I supposed to download the dev release with CVS? I tried the command given in #45 and it's not working; I get:

cvs checkout: authorization failed: server cvs.drupal.org rejected access to /cvs/drupal-contrib for user anonymous
cvs checkout: used empty password; try "cvs login" with a real password

Despair!!

In working in Unix, by the way.

I was able to check out the dev release using Cygwin on Windows. Then uploaded it to my Unix server. I got the same error messages, but it downloaded the contributed modules anyway. So I guess it's working, but only in dev, not in beta9, even though the note with beta9 says, "This release will blow your socks off: it WORKS!" So, still confused: is beta9 supposed to include the fix for this particular issue or not?

I am 100% sure you did not find the error "Unable to find a strip option in your version of tar" on beta 9, because it doesn't exist there. Please open a new issue.

:P