Running Codeigniter via CLI outputs website root i

Question

I'm following this tutorial on running Codeigniter via the CLI. I've done everything they've done (copied and pasted) now when I run this command, it doesn't do what is expected except it outputs the website index contents.

$ cd /Users/MyUsername/Sites/code
$ php index.php tools message

The output I get is the index page HTML source, e.g. http://localhost/code.

The expected result should be

Hello World!

How can I achieve this to make it work?

Answer 1

For me this was resolved by changing:

$config['uri_protocol'] = 'AUTO' 

in the main config file.

I had previously changed it to

'REQUEST_URI'

which doesn't work with CLI apparently.

Answer 2

try this:

php index.php/controller/function/param1/param2/param3 etc

or

php index.php controller function param1 param2 param3 etc

also, post the content of your $_SERVER var and value of the 'uri_protocol' variable from config.php.

$config['uri_protocol'] should be 'AUTO'

Answer 3

This worked for me - found at http://www.daharveyjr.com/codeigniter-cli-command-line-interface/

$config['uri_protocol'] = 'CLI';

I then run like this

php index.php controller/function/parameter

Answer 4

The output I get is the index page HTML source, e.g. http://localhost/code.

You have got an error with your routing, your new example CLI controller is not fired, but another controller. Which error you have with your routing is hard to say, as you have not shown your whole code.

Answer 5

Ok sorry to say but here on this page https://ellislab.com/codeigniter/user-guide/general/cli.html

They didn't mention whether the root path of the folder where we place the codeigniter or the controllers folder. I searched a lot over that issue. I tried different things and then I found that.

before that set PHP to your PATH environment variables {Run php file in windows CMD}

after setting the PATH environment variables

1. go to cmd
2. cd the path where you put codeigniter (i.e CI/)
3. php index.php/tools/message

you will get

Hello World!

on to your cmd screen.

Answer 6

I know that this question is old and has already been answered, but for myself and others, the selected answer does not work. What I've found to work is just using wget. Before you down vote me because you're looking for something that doesn't allow external visitors, hear me out!

If you use wget in conjunction with $this->input->ip_address(); you can ensure that the only machine accessing your script is your own webserver. It isn't as good as being able to call the file locally using php index.php controller function, but it is a fallback.

Here's what I have created which has worked for a few months without issue:

1. Create a directory somewhere on your server that you can just use as a scratch pad for the temporary files created by wget. I created a folder named cron one level below my public_html folder.

   ex. /home/myuser/cron

2. Construct your cron command. You can string together commands using &&.

   i. cd /home/myuser/cron && -- move to your scratch directory

   ii. wget http://www.site.com/cron/foo && -- wget your file

   iii. rm -f foo -- Remove the downloaded file "foo" from your scratch directory

3. Your final command will look something like this:

   cd /home/myuser/cron && wget http://www.site.com/cron/foo && rm -f foo

4. Check that the IP address accessing your cron files equals your webserver's IP:

   <?php defined('BASEPATH') OR exit('No direct script access allowed');
   
   class Cron extends MY_Controller {
   
       public function __construct()
       {
   
           parent::__construct();
   
           // this controller can only be called from the IP xxx.xxx.xxx.xxx
           if ($this->input->ip_address() !== 'xxx.xxx.xxx.xxx'){
   
               show_error('Direct access is not allowed');
   
           }
   
       }
   
       function foo($bar = 'bar')
       {
   
           echo $this->input->ip_address();
   
       }
   
   }
   

Important: Please make sure that you fully understand the effects of rm -f. It can have interesting consequences if you do not supply the correct file. If you have spare time, you could opt out of removing the file and just manually remove all of the cron scratch files periodically.