Create ishacked drush command

+1 for getting this in, would love to see contrib modules checked as well.

This patch introduces 2 Call-time pass-by-reference has been deprecated warnings in commands/core/core.drush.inc on line 507.

Otherwise, worked great for me!

I tried this patch with no much luck. I haven't any message back, although I hacked index.php and even deleted it.

I see that I'm having a premissions problem as logged in the watchdog:

mkdir(): Permission denied in /home/predircam/drush/commands/core/core.drush.inc on line 450.

opendir(/tmpDRUPAL-ISCOREHACKED/drupal-6.13): failed to open dir: No such file or directory in /home/predircam/drush/commands/core/core.drush.inc on line 483.

readdir(): supplied argument is not a valid Directory resource in /home/predircam/drush/commands/core/core.drush.inc on line 486.

And no, I'm not getting any output at all at command line.

Subscribing for excellence.

+1 so long as the name is changed. The command should properly be invoked with:

./drush/drush.php find_dead_kittens

subscribing

Maybe this is a bad place for brainstorming, but if the script determined the file was hacked, what if then it returned a patch of the differences?

+1 so long as the name is changed. The command should properly be invoked with:
./drush/drush.php find_dead_kittens

+1 from me.

The diff is what I expected all along. I don'gt thin it should be verbose option - it should be the primary output IMO

You're missing a return after drush_core_find_dead_kittens()
Why are .htaccess and default.settings.php excluded?

Not sure if this should go here, but what about "aremoduleshacked" as well? sometimes its crazy hacks to views or CCK that causes no end of problems?

I am also not sure, but could we not unify iscorehacked with a contrib version? I started to put together some code for it, for now the first half (download and unpack) of the contrib module works fine, the md5 check still needs work because I need to find how to get the installed path of the module. After it is done it should be usable for any installed project, be it core, contrib modules or themes.

subscribe

+1 for the same functionality for modules

Find dead kittens? WTF?

Also, on the verbose option, it's worth noting that md5summing both files/dirs and then diffing the output is about 10 times faster than just diffing the files/dirs. I would definitely support that as a standard option, as it would be more useful for scripting. It's unlikely that I'd want to use the verbose mode for scripting, and if I did use it, it would probably only be for core, or one module at a time, so that I could patch a new version. Having verbose mode as a switch would make far more sense to me.

actually, I think that's not correct about the speed. ignore it.

naught101, see http://heyrocker.com/hack_core.jpg

Also: http://blog.merge.nl/2008/08/27/drupalcon-day1-think-about-all-the-kittens/
More: http://www.google.com/search?q=hack+core+kill+kitten

I've linked to this issue from #434944: Allow minor upgrades of drupal core - lets unite there.

+1 to Aaron; recommend keeping the scope as-is for now, getting it committed, and then adding more functionality as appropriate.

re #25: I think we should work on a solution that can handle both drupal core and contrib modules to be checked for alterations, but that patch will need more work. If we implement a core only and then later a contrib only, we will be making certain parts of the code redundant.

+1 to getting this committed as a 'is core hacked' command and then focus on adding contrib module checking.

The contrib module idea is nice, but far far more complex, given the versioning and multiple places modules can live, etc.

Check #434944: Allow minor upgrades of drupal core where I've just attached a prototype script that solves the iscorehacked problem.

acstewart: I agree with you on getting the core check in now, and adding the module checks later.

applied the patch in #16, a couple of comments

• I would also rather see the diff output only with verbose option turned on. Even if diff output is default, a quiet option should be able to turn it off. The use case I'm thinking of: someone deletes CHANGELOG.txt - currently I get a diff that's a full printout of the file with "-" at the beginning of each line. Deleting just a couple of these text files results in completely useless output. On second thought, how about just showing a "file deleted" message in this case instead?
• find_dead_kittens - fine to leave in as an alias (easter egg) but does it have to show up in the list of available commands? I looks a little weird and may confuse new drush users. There are no other "joke" commands in core_drush_command().

otherwise, I think the patch in #16 is ready.

@acstewart:

of course I agree with you that if it is simple there is no need to over-scope it.

I was just pointing your atention at some working prototype code - to get ideas from :)

P.S. Actually from your implementation of this new command I will try to learn and implement the updatecode_diff command - the one I've pointed you to.

Actually, while we're at it, why not add an alias option to drush? I can see it being useful for items beyond find_dead_kittens, such as shortcuts of other existing commands.
Seems like 3 pieces here: add 'alias' as a value for hook_drush_command(), modify show to list the alias (optional?), and drush_parse_command() to handle the alias.

Help save the kittens!

+1 for command aliases. This will allow for shortcut commands similar to "svn co" for "svn checkout".

+1 as well

the patch in #33 works for me.

Thanks for all the hard work and cooperation here.

Still, I read this patch and I don't really get too warm and fuzzy. First, I don't see all that much utility in the code. You can drush dl drupal and then diff between the virgin drupal and your drupal. thats two commands in your shell yet we have a many lines of code here. And in the end, you can't even see the diff.

Also, the code isn't really drupalish enough.

I'd like some input from other comitters on this. I'm willing to change my mind.

I'm with Moshe. I like the idea still, but the patch needs some coder help and the diff is a requirement IMO. The approach needs a re-evaluation - it has to be possible to skip a lot of the custom checking and use other methods or tools to dl and diff.

I think it's a very useful addition, it resolves what is probably every developers first question when coming onto a project or getting a first look at a client's codebase. Drush has many such utility commands. drush sql cli is just a shortcut for inspecting settings.php and then using the mysql shell for example.

If this command is eventually expanded to include contrib modules, it becomes extremely useful, something that would take quite a bit of work via the command line.

just my opinion of course.

whoops, didnt mean to change status - 2 comments came in while I was writing mine :)

You use @simplexml_load_file($url) which caused us a lot of grief a few months ago. Check out the fallbacks implemented in drush_pm_dl(). Perhaps refactor than and use a common function.

the patch uses mkdir when every other mkdir in drush uses drush_op(): @drush_op('mkdir', $destination, 0777, TRUE);

looks like we re-implement some simplexml release finding code instead of refactoring. perhaps revisit that. maybe there is a reason.

yeah, gnu diff is what I had in mind. i missed it because of the iterating over the files. i think we should remove _drush_core_iscorehacked_process() and just rely on diff. if diff is not present, return an error.

drush requires php5 so lets remove the php4 compatibility function.

personally, i dislike even a whiff of moralizing. i don't agree that hacking core is taboo. it should be avoided, until the avoidance is worse than the cure. every large site i have worked on hacks core. pressflow is a collection of useful core hacks. i understand that why we discourage it, but the tone "thou shalt not" is one i don't subscribe too. please remove the help text about kittens.

along those lines, i'm tempted to call this `drush diff`. it is an unusual diff method when core was modified without using source control.

finally, would it be much more effort to support contrib modules too. seems like a straightforward extension.

I dont think it would be too much for contrib, i was looking at that possibility in my patch earlier on, basically just using any drupal.org project instead of core, should work.

instead of diff how about we use md5sums when diff is not present?

I've just started work on a module that will hopefully check most of contrib, and one day core.

http://drupal.org/project/hacked

Using Steven's module is definitely the way to go. I'm consider setting this to "By design" and moving the discussion over to #599750: Drush integration? as that module is damn awesome.

maybe move this patch over to the module as well, so the Hacked! module exports some drush commands? That way moshe doesn't have to worry about adding this code to drush itself.

drush ishacked core
drush ishacked sites/all/modules
drush ishacked sites/all/modules/views
drush ishacked all

Okay, let's extend the hacked module with a drush command as suggested.

I've marked this as postponed because the hacked module itself is still changing pretty quickly, I added support for 'core' and projects with complex structures only last night. I'll reopen this issue in a week or two when the main module is working nicely.

Drush integration should be pretty easy I think.

I disagree that this should be included into the hacked module. Why would i need to install a module on my sites i want to check, when Drush could handle this on its own? I see that it would be logical for hacked to provide a drush interface given the framework/caching the hacked module does, but if i want to monitor more than one site, this will be just an addition to the number of contrib modules I have to install.

Lets implement this as a drush command, and the hacked module may implement its own, cheaper (cached) solution if it wishes. Especially because for hacked this is a postponed issue.

I'm quite happy for this to live as a separate package from drush.

Given that drush can download and enable modules, once there's a drush command set for Hacked! you could add a command to drush that would download the module, enable it and run the commands against the Hacked! commands.

By postponed, I only mean that I want to wait a week or so that the supporting features are in Hacked! Once that's done adding he drush commands should be super simple.

My problem with hacked is that it relies on the module code, which in case your system is hacked is already unreliable. If someone can change the code, what keeps him or her from overwriting the hacked! cache, or the hacked! code itself? I liked the original method of the ishacked drush command, because it is completely independent of the installed drupal code it is verifying.

It is absolutely your domain to implement a drush extension for hacked! of course, but I will still prefer a standalone implementation that goes along the lines the patches work.

A fair point well made.

Hacked! is aimed more at people who want to see if someone has changed some code (to apply a patch or fix an issue) rather than for people who are being deliberately attacked. In the case of the latter, surely drush is just as attackable?

So, sorry for all the issue table tennis, but I'm going to move this issue back to the drush issue queue; Moshe can decide what to do with it there. Hacked! will be getting drush support, and if people want features provided by it they can download and install it.

This looks really useful. It could be used to create patches too.

Imagine the scenario: I have a module that was installed from tarball rather than CVS. I do some work to fix an issue on the module. What I would normally do at this stage is download the dev version from CVS and manually merge my changes, then use cvs diff to create the patch. It is a bit of a pain, maybe this could be a solution to that.

That's an awesome idea. I'm going to get it into the Hacked! project if I can over here: http://drupal.org/node/603030#comment-2154970

sub

Moving over from the drush queue... I think this is fixed in Hacked! Please go ahead and close as "fixed" or "won't fix", or otherwise handle as desired. Thanks.

Okay, we need some documentation for Hacked! And the drush command in that documentation for keen developers.

The code is over here: #604820: Drush system commands

/me would like to point out that "shack" has some connotations (http://en.wiktionary.org/wiki/shack#Verb), and without camel case, the command (eg. "drush ishacked date") is vaguely amusing.