I've been working on a drush command called node that supports UNIX commands (ls, rm, cat, etc). It is currently a port of a drupal/UNIX shell I wrote for fun, but now that it's actually a drush command I've been getting feedback about developing it as a tool for data migration and maintenance. I can currently do things like 'drush node ls type=page' but I don't have STDIN/STDOUT pipes implemented, and I haven't yet implemented a query engine for CCK fields, though I've been pointed at views for this. The ultimate goal would be to be able to do something like this:

'drush node ls type=cck_type | drush node cat fields=title,name,address format=csv | drush node mknode type=cck_type fields=title,name,address'

You get the idea. Lots of command line data management goodness. Feedback would be very appreciated. I just gave a talk on developing drush commands based on my work on the node command, and it's all been a lot of fun so far. Would this be desired as a drush core command, or as a contrib module ideally?

-Daniel

Comments

greg.1.anderson’s picture

greg.1.anderson commented
Category: feature » support
Status: Active » Fixed

First comment is that both migrate and node_export provide drush commands that operate on nodes. You should study these and consider how to extend or interoperate with existing code so that you don't have to start from scratch.

My second comment is that the pipe operator is really the wrong paradigm to pass node selections from 'node ls' to 'node cat' and 'node mknode'. Attributes should be --fields=a,b,c and the targets of the operation should be passed in as args, not on stdin. If you really want to pass data from 'node ls' to 'node cat', use backticks: drush node cat `node ls`.

Finally, in drush-3.0, spaces in commands are deprecated. Use node-ls and node-cat instead.

danielpacker’s picture

danielpacker commented

Thanks Greg - great information. The main reason I'd look to pipes instead of arguments is that you may want to pass hundreds or thousands of nids. Thoughts?

greg.1.anderson’s picture

greg.1.anderson commented

In that instance, I think I would still support nids via args for smaller sets, and also have a --nid-file=path if you need to read in more nids than will fit on the commandline. You could use --nid-file=- to indicate 'read from stdin'.

danielpacker’s picture

danielpacker commented

Greg, thanks again for the feedback. I'm expecting this to be used for batch operations primarily, as opposed to working on a handful of known nids. How about doing it the other way around, where stdin is default, but you can pass nids with --nids if you prefer to work on specific pre-known nids? The cases where I suspect people will work on pre-known nids is for testing and occasional debugging I think, whereas I think the real work for this module is in batch processing where you don't really know nids or how many beforehand. I could be biased, though. Your feedback is appreciated, please keep it coming.

greg.1.anderson’s picture

greg.1.anderson commented

In the case of nids, those are targets, so I would use args, not --nids (e.g. drush node-insert 43 44 rather than drush node-insert --nids=43,44). I'd also recommend that you support --nids-file=..., but I see no reason why the tool could not assume --nids-file=- if no target was specified.

All of this is just opinion, of course. I would again reiterate that you should investigate the other modules mentioned above as well.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.