richardp [richardp]

Here is the download file:

Sorry-- setting the status to "needs review".

Thanks,
Richard

Hello kiamlaluno,

Thank you for checking out the module.

My module does not have a similar purpose as drush. Drush is a command-line utility used to perform operations on drupal, such as installing modules.

My module is a web-based shell, sort of like putty or a telnet client. It can be used to perform almost any operation on the box, not just those having to do with drupal. For example, you can use linux commands like "find", "grep", "wget" and so forth. In fact, you can run drush from my module, if you want. Administrators could use my module, for example, to create new shell scripts, then edit their crontab on the box itself to configure when the script runs.

As I said in my description, this is for users whose web hosts do not give them any kind of shell access. This lets them simulate being able to log into their boxes with putty, for example.

So as you see, this is not similar to drush, so there is no reason try to make a features request for the drush project.

Thanks,
Richard

I see. Well, I still believe my module provides a unique feature in that it allows you to issue any valid linux command to the server, and provides an experience similar to that of putty using ajax callbacks and a terminal interface.

With my module, you can run any script on your server, not just what is exposed through Drush. If I understand you correctly, in order for Drush to do all this, I would need to expose all possible linux commands as Drush commands. This seems impossible, given that with my module, you might chose to compile a java program, run a shell script, execute a downloaded program, etc. There is no way for the module to know every possible thing the user wants to do on their box. And such a module seems like it would be getting away from what Drush is all about-- that being the management of your drupal site.

I still feel like this is a unique module, and that its purpose is very different than that of Drush's.

Thanks
Richard

I am honestly not trying to be difficult here. I guess I am not explaining myself well enough.

My module is for users who do not have shell access, and are probably using an inexpensive web-host, but, would like to be able to simulate being able to access their site through a shell-like interface. I, myself, am under such a situation.

One of Drush's requirements is: "To use drush from the command line, you'll need a CLI-mode capable PHP binary. The minimum PHP version is 5.2."

If the user has no control over the state of their PHP binary, or has an older version of PHP, then they cannot use Drush. But they *can* use my module.

But beside from all that, my module simply has a different function than Drush.

The only similarity I can see between my module and Drush is that they both have the word "shell" in the title. My module is not simply faking commands. When you type "shelp" in my module, yes, you get a couple of commands that it does differently than expected — but — any linux command or script or program will work without me having to program anything extra

I am honestly not trying to be rude, but you keep insisting that I am duplicating the features of Drush, but I am not, at all. The two modules serve two very different functions. And, again, my module is for people who have no access to a shell, making it unlikely they could even get Drush installed in the first place.

Please do not just give up on my project because I am not explaining it well enough.

Richard

_{[Edited by kiamlaluno to remove the excessive use of &lt,strong> tags]}

To clarify something:

You want me to make it so that my module requires Drush to be installed, and passes all linux commands through Drush. The reason I can't do this is because it would severely limit the usefulness of my application. Remember, my application is for users who do not have shell access.

From the Drush readme.txt file:

"1. Untar the tarball into a folder outside of your web site." - If you are on a low-cost web host, with no shell access, you probably cannot do this.

"3. (Optional, but recommended:) To ease the use of drush,
- create a link to drush in a directory that is in your $PATH, e.g.:
$ ln -s /path/to/drush/drush /usr/local/bin/drush
OR
- create an alias to drush:
$ alias drush='/path/to/drush/drush'
"
— again, if you do not have shell access, or are on a cheap web host where your access is limited, you probably cannot perform these actions at all.

So you see what I mean? I do not want to require Drush, because I don't see it as adding anything useful to my module — only making it so that the intended users can't use it!

The irony is that if a user did have my module installed, then, using it, they could probably install Drush and create the links and aliases. But if all you have to work with is cpanel or less, then you just can't.

This is why I don't understand why you keep insisting I should use Drush. They just aren't the same thing and it doesn't make sense to try to force my module to pass commands through Drush.

I don't mean to just argue. I just don't think my module overlaps with Drush at all.

_{[Edited by kiamlaluno to remove the <strong> tags]}

Thank you for taking another look at my module. Sorry about the delay-- I was out of town.

I have fixed the curly brackets, and used the drupal string functions found here: http://open.madcap.nl/fotd/drupal-string-functions where appropriate. I have also tried to make sure that I used t() where appropriate.

I am attaching my updated code now.

Thanks again,
Richard

So-- what happens now? Do I need to do something further? It has been almost 2 weeks since I posted my updated code.

That's okay. Thanks for putting up with me!

Richard

You're absolutely right, Heine. As soon as the project page went up (http://drupal.org/project/shell), I was contacted by the security team to tell me just that. It is fixed now in the beta version on that page. Thanks for the input!