Posted by John_Buehrer on September 20, 2010 at 7:37am
Hi, may I inquire about (or request) support for running Drush scripts referenced by absolute path names, or fed from STDIN under Unix? This is to facilitate scripting in a common Unix manner. Eg, something like this:
$ drush -r /Applications/MAMP/htdocs/my_site scr /tmp/qqHere's a partial work-around, but it would be helpful to support specifying the complete filename, as well as making the documentation consistent. Eg, cheat-sheet says this isn't possible at all (http://drupal.org/files/drush-cheat-sheet.pdf) but new web page says otherwise (http://drush.ws/help/3), and the help info from running drush without parameters doesn't mention --script-path at all.
$ cat - > /tmp/qq.php <<EOF
> <?php echo "test\n"; ?>
> EOF
$ drush -r /Applications/MAMP/htdocs/my_site --script-path=/tmp scr qq.php
testReading from STDIN fails, at least like this:
drush -r /Applications/MAMP/htdocs/my_site scr <<EOF
> <?php
> echo "php\n";
> echo "test\n";
> ?>
> EOF
/usr/local/drush/commands/core/scratch.php$ cat - <<EOF | drush -r /Applications/MAMP/htdocs/my_site scr -
> <?php echo "test\n"; ?>
> EOF
...errors...For reference, this works fine with php:
$ cat - <<EOF | php --
> <?php echo "test\n"; ?>
> EOF
testThanks.
Categories: absolute pathname, scripts, standard input, stdin, UNIX
Comments
drush php-script
drush php-script --script-path=/path/to/scripts scriptname # .php not needed
One option is to change implementation of php-eval to alternatively receive data from stdin, although I don't have any interest on it.
POSIX compliance and following unix modularity
I've been shell scripting for 24 years, and if drush developers are thinking to move in the direction of shell scripting using standard in, out, error and pipes, that would greatly simplify current shell programmers adopting drush, as well as supporting POSIX conventions, for ALL options and command line arguments, then I would vote for it.
Of consider note, and concern to me, is drush 4 included some 'novel' argument conventions, and deprecated some old methods. Neither of these directions, imho, reflect increasing the ease of scripting drush, that is embedding the drush command inside a multiple line shell script. I do understand, and encourage, individuals donating their "plugins", and some of these plugins will "compete", and over time, some will mature faster, while some become unsupported, and identifying the plugin via an abbreviation 'seems' like a good direction. A necessary evil, perhaps(?).
drush is at a difficult growing stage. It's attempting to do what few, if any, other unix commands have ever done. drush is not only changing an application's configuration, but is moving towards 'too' many avenues. Most open source tools create separate executables, like mysql's admin tool(s) compared to content query/manipulation tools (cli and browser).
I think I do not have enough background about drush's current management decision making process, so I will just conclude I hope they look at Unix 'modularity' VERY CLOSELY. The theory behind "data streams" containing both data and control streams has proven to be very flexible, powerful and scalable. Unix filtering is based upon it. All CLI commands use it extensively, and deviations are at considerable risk of becoming obsolete (imo).
It's not clear to me that "all" of drush's future features can following unix conventions. I feel if the attempt is made, then everything will be easier, decision making, feature set requirements, and implementation, not just scriptability.
This may not have been the completely right forum. So, do pass this tidbit on to those who might benefit. thx
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
@bvirtual: Thank you for
@bvirtual: Thank you for your comments. Your ideas are good, but very general. If you have specific requests for drush (or better still, patches with improvements), the best place to bring them is the drush issue queue.
Many drush commands support the --pipe option, which transforms the output of the command into a form that is more useful for piping to another command (grep, sed, awk, etc.). There is an open issue requesting that all drush error messages go to stderr rather than stdout. This is a very good suggestion, and has not been implemented only for lack of time.
There are a lot of contributors to drush, but no one is paid to maintain it. If we all work together, we can make drush even better, and improved interoperability with various unix utilities is an important future direction. We look forward to contributions from the community to help us move in this direction.
@John_Buehrer: It's better to
@John_Buehrer: It's better to put drush feature requests in the issue queue. See http://drupal.org/node/926766 and http://drupal.org/node/926780.
Thanks, will do
Thanks Greg, I'll check the patch. I was uncertain whether this is a general architectural topic or just "an issue". Can I depend on STDIN behavior in other, similar use cases which come naturally to Unixy people?
For example, constructs like this are frequently used for automation:
$ alias dr='drush -r /Applications/MAMP/htdocs/my_site'$ echo n | dr pm-update | grep -i 'update available'
# CKEditor - WYSIWYG HTML editor 6.x-1.1 6.x-1.2 Update available
# Content locking (anti-concurrent editing) 6.x-2.1 6.x-2.2 Update available
(Am I correct that this information is tied to the workflow of making an update, and not available separately?)
Your point about working together is a good one. What does it take to be a Drush contributor? Coding is one thing, but your community culture of doing so is also important and non-obvious: suites of test cases, etc. Thanks...
Be careful of line wrapping
The output formatting of drush pm-update is dependent on the width of your terminal display. If it's narrow enough, 'update available' and/or your version numbers might get split over more than one line.
Yes, your example above is
Yes, your example above is correct, although you can also pass --no to drush rather than "echo n | dr". There is currently no other way to check for updates than
pm-update --no. As far as the issue queues are concerned, you can post "issues", feature requests and support requests there.To become a contributor to a project, please see:
http://drupal.org/node/550576
http://drupal.org/patch/submit
http://drupal.org/patch/apply