Dries Buytaert wrote:

On 14 Aug 2006, at 07:22, Neil Drumm wrote:

...

I think code-clean.sh and code-style.pl should be moved over to a directory next to the devel module.

I guess we could move these (although I use these daily). ;-)

I expect those who use shell scripts a lot know about symbolic links. (Which will be different depending on everyone's setup. I'd put mine in ~/bin/.) The code-*.sh scripts are for developers; it would be nice to put them with other developer tools and make Drupal core simpler for non-developers. -- Neil Drumm http://delocalizedham.com/

Bèr Kessels wrote:

Would that be enough to remove the ./scripts/ completely? pleaaasse?

A coherent non-begging reason that people agree upon. :) For example, the only scripts I didn't mention were cron-*.sh. Those could be either put in snippets in the cron setup documentation or removed if something like poormanscron were in core. I didn't say any of that since I am not certain of the above ideas and to focus the discussion on something simple and doable. -- Neil Drumm http://delocalizedham.com/

I agree on the removal of the scripts directory, too. The issue is http://drupal.org/node/52575. 2006/8/14, Johan Forngren <johan@forngren.com>:

Neil Drumm wrote:

...

Bèr Kessels wrote:

...

Would that be enough to remove the ./scripts/ completely? pleaaasse?

A coherent non-begging reason that people agree upon. :) Absolutely

For example, the only scripts I didn't mention were cron-*.sh. Those could be either put in snippets in the cron setup documentation or removed if something like poormanscron were in core. I'd say that the cron docs could be a very nice new home to those scripts.

I didn't say any of that since I am not certain of the above ideas and to focus the discussion on something simple and doable.

Personally, the combination of "cron-lynx.sh + cPanel cron manager" has always allowed me to set up real cron jobs for my Drupal installs, despite my having a very weak knowledge of Unix scripting. I'm sure that there are other people in the same boat as me.

I have to go out on a limb here and say "irrelevant". There is nothing different between telling cPanel to use this bit of text: 0 * * * * /path/to/drupal/scripts/cron-curl.sh vs. telling it to use this bit of text (in our INSTALL.txt). 0 * * * * wget -O - -q http://www.example.com/cron.php There are two factors: 1) what "thing" to use to request the cron.php. 2) what line of text to copy into whatever you admin with. The first one requires an understanding of what "curl" or "wget" or "lynx" is (which you have to admit to knowing, since we don't provide any documentation in our scripts/ directory) and that can easily be explained in our INSTALL.txt. The second doesn't require /understanding/ only /implementing/ and the primary differences in implementation relate to your enactors ("crontab -e" vs. "cpanel") and time descriptors (like the above, vs. a cPanel dropdown), NOT whether you blindly copy "cron-curl.sh" vs. an equivalent line that has been provided for you. As for Adrian's:

One case for script/ that I can think of, and something almost all of us would end up using almost daily: http://drupal.org/node/59863

I see that as a /cli.sh not as a /scripts/cli.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. -- Morbus Iff ( sleep breeds sanity ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Scripts should be broken down into two areas depending on their different audience: - Developers Scripts like code clean and such are developer oriented tools. Arguably, these belong to the devel module. That is definitely a better place than the scripts directory of the base Drupal distro. - Site Admins (who are non-developers). This is where cron and other stuff belongs. Some of the oft used stuff can remain the base Drupal distro, while other less used or specific stuff can be merged into sympal. As an aside, sympal uses command line PHP. This requires two things that are not available for most users: ssh and php-cli. Is that correct?

Most shared hosting of late tend not to even offer ssh as an option, paid or otherwise. Not having a shell will prevent using PHP from the command line, regardless of whether the host has PHP CLI or not. I am all for this Drupal CLI thing, and will make use of it for sure. What I am against is making it the only way to run certain things, which will lock out many users. On 8/14/06, Morbus Iff <morbus@disobey.com> wrote:

...

As an aside, sympal uses command line PHP. This requires two things that are not available for most users: ssh and php-cli. Is

Well, no, both of those are pretty commonly available - the problem is the number of users who /get a shell at their host/ - that's a much bigger "what if?" then whether ssh or php-cli is installed.

-- Morbus Iff ( accept no prostitutes ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

On 8/14/06, Neil Drumm <drumm@delocalizedham.com> wrote:

It is good to see the CLI stuff being worked on. Our first priority should always be web interfaces. I don't think including more scripts in core is a good idea at the moment.

i mentioned the cli.php in scripts/ because that's where dries wanted too put it. Also, the cli code is a very small wrapper around the web based code. All that is still needed is a way to submit forms via the cli , and return errors.

On Tue, 15 Aug 2006, Gerhard Killesreiter wrote:

Adrian Rossouw wrote:

...

On 8/14/06, Neil Drumm <drumm@delocalizedham.com> wrote:

...

It is good to see the CLI stuff being worked on. Our first priority should always be web interfaces. I don't think including more scripts in core is a good idea at the moment.

i mentioned the cli.php in scripts/ because that's where dries wanted too put it.

Also, the cli code is a very small wrapper around the web based code. All that is still needed is a way to submit forms via the cli , and return errors.

I think a cli interface is a very nifty thing to have. If we get a graphical installer for the masses, we shouldn't forget to cater for the advanced users, too.

Indeed, Gerhard. Advanced users will not have a problem finding a CLI tools package around drupal.org. Gabor

On 15 Aug 2006, at 11:18, Adrian Rossouw wrote:

i mentioned the cli.php in scripts/ because that's where dries wanted too put it.

Hear, hear. :-) I don't mind putting it elsewhere if there is consensus. For now, let's assume it goes into the scripts-directory but bear in mind that it isn't set in stone. -- Dries Buytaert :: http://www.buytaert.net/

On 8/15/06, Adrian Rossouw <adrian@bryght.com> wrote:

On 8/15/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:

...

Hear, hear. :-) I don't mind putting it elsewhere if there is consensus. For now, let's assume it goes into the scripts-directory but bear in mind that it isn't set in stone.

I'm just happy that we are just assuming it gets in, at all =)

Me too ...

I'm not too happy about putting this in any web accessible place. That is asking for trouble.

Nope. Just prevent access from the web via .htaccess, like we do everything else. Alternatively, it's quite easy to add a check in the script itself to detect if it's being run in a web environment vs. a CLI. Just check for some environment variables here and there. -- Morbus Iff ( accept no prostitutes ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

I wouldn't trust .htaccess at all. The thing get lost all the time due to being invisible on some systems, other installations don't allow access to it, and other HTTP servers don't know about it.

Then surely you must approve of, or at least have comments on, the part of my email that you didn't respond to, nor include in your quote? -- Morbus Iff ( a blivet is 11 pounds of manure in a 10 pound sack ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

On 15 Aug 2006, at 19:10, Neil Drumm wrote:

I know we can probably get the scripts otherwise secured enough to be in a webservable directory. I'm actually going to sit back and let everyone else decide if we actually want them there.

Here is a decision: if properly secured, it makes a lot of sense to have such script. Especially if it makes for an important component for third-party installers (like Gentoo's, Debian's, etc). If both conditions are met, it is core-worthy. -- Dries Buytaert :: http://www.buytaert.net/

Except that many hosts deny .htaccess overrides Note SA-2006-06 (revised): http://drupal.org/node/66763

Note that I wrote and revised that security announcement. -- Morbus Iff ( a blivet is 11 pounds of manure in a 10 pound sack ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

Op dinsdag 15 augustus 2006 19:10, schreef Khalid B:

The discussion of the cli script being under DocumentRoot or not has to be brought into context of previous discussions on what should be under there and what should not.

Sympal scripts checks for existance of certain arguments. If not found it exists quietly. drupal.php requires --site if not set (for now) it exits without any output. Still if in a web accessible dir * they /can/ be loaded. This is bad enough in the first place. * they /don't need to be there at all/. No-one needs non-web-accessible-files in a web-accessible place. No one should want that either. So why put them there? * if they can be loaded, people see no 404, but a blank page or so. People then /know you have these scripts/. I prefer people to not know such things. .htaccess: I think about 1/4th of all servers where I built drupal sites did not eat my .htaccess. Go out there and look for drupal sites with urls in the form of ?q= that will give a rough indication of the amount of servers where .htaccess is not allowed (off course missing mod_rewrite can be causing unclean urls too). Google counts [1] 4.830.000 of em. If even 1/3rd of these are due to missing .htaccess there are still a million! relying on this file for security means, in practice, that we drop all support for none .htaccess servers! Bèr [1] http://www.google.nl/search?q=inurl%3A%3Fq%3Dnode&ie=UTF-8&oe=UTF-8

On 8/14/06, Bèr Kessels <ber@webschuur.com> wrote:

Op maandag 14 augustus 2006 16:00, schreef Khalid B:

...

As an aside, sympal uses command line PHP. This requires two things that are not available for most users: ssh and php-cli. Is that correct?

Why would that be any different from /scripts? you need ssh/bash perl and/or PHP cli there too.

Both need ssh. The PHP CLI is an additional requirement on top of ssh (although I have used cron as a way to run shell scripts when the client has no ssh). On a dedicated host or VPS, this may not be an issue. On shared hosting one or both may not be available. This does not decrease the usefulness of sympal, it only makes the user base for it less than Drupal in general, and is not a problem in itself.

On 14 Aug 2006, at 10:18, Neil Drumm wrote:

I'm honestly not exactly sure who the sympal scripts are for. I think people who want a command-line provisioning system, but I would not be surprised if I am wrong. In my opinion, the devel module is a more findable place for code-*.sh.

I agree. I've never used the sympal script but from what I understand they have nothing to do with the code-style.sh and code-clean.sh functionality. Devel.module is more appropriate. -- Dries Buytaert :: http://www.buytaert.net/

Op maandag 14 augustus 2006 14:01, schreef Adrian Rossouw:

One case for script/ that I can think of, and something almost all of us would end up using almost daily :

http://drupal.org/node/59863

Essentially it's a command line wrapper for Drupal.

This can be useful for a great many things, but imo primarily for automating the install system.

for installing a new site of a specific distribution : scripts/drupal.sh --cmd install.php --site mydomain2.com --db mysql://username:pass@localhost/dbname install profilename

for updating a specific site (useful in a script which recurrs through sites/ whenever you alter the source) : scripts/drupal.sh --cmd update.php ---site mydomain.com update

Sympal scripts has a (quite modular, so you can get rid of all the other crap) Drupal-on-the-commandline-includer. Written in PHP, so even easy to understand for bash n00bs. drupal.php Include the full Drupal code in your PHP session. --site www.example.com Includes the Drupal site www.example.com, for your own scripting fun. Bèr