CodeIgniter Forums
[CI4] CLI - Printable Version

+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: CodeIgniter 4 (https://forum.codeigniter.com/forumdisplay.php?fid=28)
+--- Forum: CodeIgniter 4 Feature Requests (https://forum.codeigniter.com/forumdisplay.php?fid=29)
+--- Thread: [CI4] CLI (/showthread.php?tid=66841)



[CI4] CLI - marksman - 12-09-2016

Hi,

Good Day!! Is it included in CodeIgniter 4 feature's the CLI like artisan in laravel? it's pretty cool.

I love CodeIgniter conventions and documentations and the way it is built but a CLI like artisan in laravel will make it better. A framework trying hard to adopt CodeIgniter way (FuelPHP) have it, they call it oil. Fuel is good but they have a very bad documentation. Hopefully this features will be available soon to CodeIgniter.


RE: [CI4] CLI - kilishan - 12-12-2016

I'm exploring the possibility now, since it would clean up some of the migration CLI commands, the development server and possibly a couple of other items down the road. Don't expect much, if any, code generation from it, though, as that's not in the works. If this makes it into final release, it will be simple to specify provide your own CLI commands to do code generation if you desire.


RE: [CI4] CLI - humni - 07-16-2017

It would be really nice to remove the need for a migration controller and be able to run the migrations from CLI. Is there any update on this and if it has made it into 4.x?


RE: [CI4] CLI - kilishan - 07-16-2017

Yes, the controller is gone and there's a CLI command for it now. Just run the following to see what's available:

Code:
php ci.php



RE: [CI4] CLI - sv3tli0 - 07-16-2017

Wouldn't it be nice if we remove that .php from the name of ci.php ? (as simple as possible)

We have already the env php at the start so in most cases it will work and without calling the php command before the file.. 
Code:
#!/usr/bin/env php

"ci" shouldn't be used, so either "CI" or "[c|C]ode[i|I]gniter" or even "ignite/r" ..
This way people will only have to write CI <command> (or max php CI <command>).


RE: [CI4] CLI - kilishan - 07-17-2017

(07-16-2017, 10:30 PM)sv3tli0 Wrote: Wouldn't it be nice if we remove that .php from the name of ci.php ? (as simple as possible)

We have already the env php at the start so in most cases it will work and without calling the php command before the file.. 
Code:
#!/usr/bin/env php

"ci" shouldn't be used, so either "CI" or "[c|C]ode[i|I]gniter" or even "ignite/r" ..
This way people will only have to write CI <command> (or max php CI <command>).

I had planned on removing the extension at some point, but hadn't yet looked into the implications on Windows machines, and any other possible conflicts. It's been a decade since I've worked on Windows enough to remember how that would affect things.

What you don't mention is why ci shouldn't be used. Ignite comes across as either cheesy or cocky depending on my mood that day (and yes, it's one that I considered), but the only contradiction I could see with ci was continuous integration, which wouldn't matter whether it was lower or uppercase. And I don't recall ever seeing any CLI function that was named in uppercase, so I think that idea's out.


RE: [CI4] CLI - sv3tli0 - 07-17-2017

(07-17-2017, 06:27 AM)kilishan Wrote: I had planned on removing the extension at some point, but hadn't yet looked into the implications on Windows machines, and any other possible conflicts. It's been a decade since I've worked on Windows enough to remember how that would affect things.

What you don't mention is why ci shouldn't be used. Ignite comes across as either cheesy or cocky depending on my mood that day (and yes, it's one that I considered), but the only contradiction I could see with ci was continuous integration, which wouldn't matter whether it was lower or uppercase. And I don't recall ever seeing any CLI function that was named in uppercase, so I think that idea's out.

"ci" exists as command at linux distributions (related to RCS).
I think that such file name must be short and unique so that there are no conflicts with any standard commands in Linux/Windows/MacOS

P.S. Another good option is to move it under some folder like "bin" ..
This way it will be easy for usage as : bin/ci ....