Run Drupal from a shell.

Nice idea!

WRT og2list, Perl was chosen for the existence of mail related libraries. We did not want to write the scripts in PHP.

I wonder whether it'd be possible to replace index.php with a script (or maybe a prepend is enough?) which would preload the few necessary $_SERVER , $_REQUEST and $_GET variables from argv. This would mean that it can be a contrib for the 4.7 cycle.

So, you are going to write it :) ?

Very nice, however i'd prefer if it would live in contrib cvs for the 4.7 release cycle.

contributions/tricks is a good place imo.

Nice lil script. A --help option to display a short desc on usage and available flags would be good, too.

I don't think this belongs in core. contributions/tricks seems like the best place.

Gordon

Good work. I can think of many uses for it (think scripting of upgrades, extracting statistics, and many others).

You say: "the entire access to cron.php can be removed." Actually, it would be useful for the majority of sites. However, those on shared hosting that have to revert to poormanscron would not be able to use it still.

We now have an install system and this little script could live in scripts/ and make automated but somewhat customized installs possible. Just think of how dpkg-reconfigure could reuse this one.

i agree that this is a good addition to /scripts in core download

I agree completely, but i want us to be able to run install.php and update.php with it as well.

This is _especially_ useful for people hosting many sites as you could do :

for site in `ls - 1 sites`;
do
scripts/drupal.sh --cmd update.php --site $site update;
done;

Whenever they update their source.

Additionally, you could use it to do the install system, namely :

scripts/drupal.sh --cmd install.php --site mysite.com --database=mysql://username:password@localhost/dbname --profile='profilename'

Please:

1. fix the use of capital letters in user output.
2. add some PHPdoc/documentation. This needs more documentation.

Otherwise looks really interesting!

Subscribing.

I see this script as a /cli.sh not as a /scripts/drupal.sh. Much like index.php starts us off for a webserver, cli.sh starts us off for a command line interface to Drupal. Relegating this /really powerful feature/ off into a mere script directory sells it quite short - we'd be insulting it's potential for glue integration with any number of other applications.

Fixed some typos and grammar in usage.

It should be fairly simple to make the script not web runnable.

I believe the argv/argc properties are only set when run via the shell. Unsure about when it is run via CGI (instead of modphp) though.

Regarding execute-protection: Why don't we create a .htaccess in /scripts? This would prevent execution of all other shell scripts as well.

Access to those scripts is already blocked in the parent/standard .htaccess of Drupal, but the concern is that some webhosts don't allow users to use .htaccess files (thus preventing the protection) and a cli.php is far more dangerous than the other scripts we ship.

In my mind, it seems to be a lot easier to do:

./drupal.sh http://mysite.com/foo/bar

than to do:

./drupal.sh -path something -site mysite.com -foo/bar

Also, the difference between '-path' and '-site' is not obvious.

And 'cron.php' is also a 'path' so why do we have to use --cmd for that, but not for other paths.

All in all, I think this scripts needs to evolve a bit. It appears to be more complex than it ought to be.

+1 for simplicity.
Dries, that's awesome!

For those interested, here's the diff.

Q: Is it really possible to pass a $_GET['q'] to this shell script? I don't think so, but maybe I'm wrong. We have to investigate this.

URI has to be enclosured by quotation marks now. (& is a shell command)
URI supports real files now.

CVS ID tag broken, should be $Id$ and placed in top like all other files.

Added CVS ID.

well, whats the status here? going into core or contrib? needs work?

I still vote for contrib. Few people will want/need to use this since it is a more advanced tool. Many people won't even be able to run it on their server environment. So why put it in the package that everyone downloads?

I thought this script would replace cron-curl.sh and cron-lynx.sh in 4.7 scripts folder. Since the folder scripts won't exist for 5.0 anymore (right?) IMO this script should be provided by core in the root directory of Drupal. Drupal core should provide this easy way of cron/shell support.

Question in #30 is still open for answers. If this is not needed, it can be removed.

Subscribing

Has anyone had any luck doing shell access to Drupal in today's 5.0? Even something as simple as:

  require_once 'includes/bootstrap.inc';
  drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
  print "whee"

Which used to work in 4.7 from the shell (prints "whee") fails as a shell script against 5.0. I don't need to run a particular URL, but I do need to load all the Drupal junk inside a shell script.

hmm. Morbus' script fails for me too. odd. anyone know whats going on? this shell script seems not to work for me either. i am running drupal in a subdir, if that matters.

I'm still unable to get the simple script above to work but, for my needs (which, at that moment, meant the bot.module), I did happenstance on the magic required to get it going in 5.0 and a shell. You can find the specific necessities under the --root and --url cases of http://cvs.drupal.org/viewcvs/drupal/contributions/modules/bot/bot_start....

This isn't an actual patch, $Id$ is in there twice, and there are lots of coding style errors (http://drupal.org/node/318). Are the changes to bootstrap.inc still needed?

I can understand gordon so far that making a patch against a file that doesn't exist yet is actually not easy.
Here is the patch against my latest version of drupal.sh in #32.

I like the idea of using parse_url(), because this gives also an option to pass username and password, f.e. for SecureSite module.

Q: Is it possible to commit this or the previous version of drupal.sh to HEAD, so we can patch against that version?

imo the patch needs to be developed within this issue before anything is committed. The code could use some additional comments to explain things.

Including a new file in a diff is very easy once you get the hang of it. I've added some more explanation to http://drupal.org/diffandpatch so it should be clearer about this case. Feel free to email/contact me if you have any questions/suggestions on that.

A full patch is still needed as it shows the location of the file(s); providing partial patches against previously posted files are pretty unhelpful and disorganized. You guys are really not making it easy for someone to review this issue. And if you know that changes need to be made to core for command-line Drupal you should also include them in the patch.

I've added a few definitions of server variables in the attached patch. Without these, we get PHP warnings and notices during bootstrap request_uri().

Tested against Drupal 5 and works like a breeze!

Added $_SERVER['SERVER_SOFTWARE'] = 'PHP CLI'; in attached patch to avoid another PHP Notice in common.inc:1002 on Drupal 4.7.

Now successfully tested with Drupal 4.7 and 5. I've to add that since September 2006 this script properly runs Cron on one of my Drupal 4.7 sites (productive).

Subscribing...

This looks great, and I'd love to have this in core. However, the coding style needs work ...

I ran drupal.sh against Coder module to fix the coding style.

Hi sun, i've looked at it some more and it is starting to look real good. However, I think we can clean up the code some more. We can probably group all the verbose-code near the end of the file. Like that, we don't have to check for the verbose flag a handful of times.

Some of the verbose messages are not helpful. For example, what does "Site set to: xxx" mean? How or why is that useful information? When you say 'Site' what exactly do you mean? Elsewhere we use 'root', I think.

Secondly, the help text is a bit confusing. Say I want to create a file foo.php -- can I also run that file or does it have to be a Drupal path recognized by the menu system. Do I invoke it in the exact same way? Enter '/cron.php' for executing cron.php (i.e. http://default/cron.php). seems to be somewhat contradictionary. Does my script 'foo.php' need to boostrap Drupal or is that taken care of?

I think this is almost ready -- just trying to figure out if we need to make some final changes.

subscribing

Sorry for change status webchick, you must have submitted while i was reading...

Any chance of seeing some integration or borrowing with this project? http://drupal.org/project/drush They have the same remarkably similar goal.

• Moved verbose output code to the end.
• Changed verbose message text 'Site' to 'Hostname'.
• Changed help text for URI parameters.

I'd like to see this go in before working more on my patch (multi-threaded cron). I believe I will use this functionality, or have the option of using this in my patch.

Committed this to CVS HEAD. Good stuff. Thanks all. :-)

I'm urged to re-open this issue. drupal.sh was destined to live in the root directory of Drupal. It has been committed to /scripts now.

a) Either we explain this in the help/usage or
b) we have to modify the code to follow this change.
c) Or we move drupal.sh to the root directory (where it could safely live IMHO)

I'd propose c), and maybe the security team could take a quick look at it.

That's exactly why you should have made a patch, as I stated back in #47.

We definitely should inform users about how to execute this script without --root argument or this will lead to unnecessary support issues. Attached patch explains that.

Committed the patch with the clarifications. Thanks.

Is it safe to say this never made it to core for Drupal 5?

Also, did anyone read #39 above - i also have the same issue whether i use this script or just right simple one on my own - no output after bootstrap run. It works in 4.7 though.

i have the following script called test1.php in my sites root folder:

echo "pre-start\n";

include_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

echo "start\n";

and i run either from the command line or with this script as:

./drupal.sh "http://rv.local/test1.php"

and my output is only

pre-start

the line after bootstrap is never hit

It works in 4.7.

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

drupal.sh is in D6, not 5.

Please open another issue for your problem. This one is too old and too cluttered to re-open it.

I'll try to work on the handbook pages for Setting up cron in the next days.

can this be used to run update.php?