CLI command naming conventions?

[Joe Stump]

Do we have naming conventions for naming CLI utilities that ship with  
packages?

--Joe


--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Helgi Þormar Þorbjörnsson-2]

On Sat, Apr 12, 2008 at 1:00 AM, Joe Stump <joe@...> wrote:
> Do we have naming conventions for naming CLI utilities that ship with
> packages?

To my knowledge there isn't anything official;

People like Greg, Chuck, Ken and Laurent might be able to answer that
tho, they are people that are maintaining a CLI app in pear, there are
probably more people but those I remember from the top of my head.

If there isn't one then perhaps a RFC might be in order so we have a
common naming convention if people don't find that over doing things.

- Helgi

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Chuck Burgess-2]

On Fri, Apr 11, 2008 at 8:33 PM, Helgi Þormar Þorbjörnsson <
helgith@...> wrote:
> On Sat, Apr 12, 2008 at 1:00 AM, Joe Stump <joe@...> wrote:
>  > Do we have naming conventions for naming CLI utilities that ship with
>  > packages?


I'm also not aware of any *conventions* per se, though based on the few CLI
utility apps that I've seen in PEAR, it looks like the main thing would be
for the name to semi-reasonably match the package name that it is the key
runtime script for:

   - pear - PEAR
   - pearsize - PEAR_Size
   - phpdoc - PhpDocumentor
   - phpcs - PHP_Codesniffer
   - docblockgen - PHP_DocBlockGenerator
   - php_beautifier - PHP_Beautifier

I suppose another convention would be to keep its name all lowercase, to
avoid complications with case-sensitive vs. case-insensitive platforms.

An observation I've made in looking at these various runtimes is that the
*nix executable script has no extension, while the Windows executable should
be the same name plus the *.bat* extension.  Presumably this is so the same
*command* can be used on either platform, without requiring any extension to
be typed.
--
CRB

Hello Chuck,


>    - pear - PEAR
>    - pearsize - PEAR_Size
It integrates itself into PEAR, so you do "pear size" now.

I have one html_template_phplibtool. Other than that, on gnope.org I
ship dev_inspector (Dev_Inspector package)

--
Regards/Mit freundlichen Grüßen
Christian Weiske

[David Jean Louis]

> I'm also not aware of any *conventions* per se, though based on the few CLI
> utility apps that I've seen in PEAR, it looks like the main thing would be
> for the name to semi-reasonably match the package name that it is the key
> runtime script for:
>
>    - pear - PEAR
>    - pearsize - PEAR_Size
>    - phpdoc - PhpDocumentor
>    - phpcs - PHP_Codesniffer
>    - docblockgen - PHP_DocBlockGenerator
>    - php_beautifier - PHP_Beautifier

Just to add it to the list:

     - phpdt - Testing_DocTest;
     - php-shell - PHP_Shell;
     - pci - PHP_CompatInfo;
     - DB_DataObject_createTables.bat - DB_DataObject;
     - gtkmdbdesigner - GTK_MDB_Designer;
     - system-procwatch/system-procwatch-lint - System_ProcWatch;
     - t2xmlchk.php - Translation2.


Maybe the recommandation could be:
     - prefix with "php-" (or "pear-" ?) in order to minimize conflicts
with others command line programs (eg. php-doctest);
     - use a lowercase name not too long (say: <= 15);
     - use a hiphen if you want to separate parts of the name (eg.
php-system-procwatch);
     - create a "<name>.bat" for windows users.

--
David.


--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Ken Guest-2]

On Sat, Apr 12, 2008 at 8:27 AM, Christian Weiske <cweiske@...>
wrote:

> Hello Chuck,
>
>
> >    - pear - PEAR
> >    - pearsize - PEAR_Size
> It integrates itself into PEAR, so you do "pear size" now.


you may issue the command as "pear size", however in the interests of
laziness I let tab completion help and do:
$pears<tab>

;-)

k.

[Joe Stump]

On Apr 12, 2008, at 1:16 PM, Ken Guest wrote:

>> It integrates itself into PEAR, so you do "pear size" now.

Is this documented somewhere? I'd think it'd make sense to leverage  
the PEAR CLI framework for stuff like this (e.g. `pear gearman  
restart`, `pear gearman stats`, etc.). Is this allowed? :)

--Joe


--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Ken Guest-2]

On Sat, Apr 12, 2008 at 9:21 PM, Joe Stump <joe@...> wrote:

>
> On Apr 12, 2008, at 1:16 PM, Ken Guest wrote:
>
>  It integrates itself into PEAR, so you do "pear size" now.
> > >
> >
> Is this documented somewhere? I'd think it'd make sense to leverage the
> PEAR CLI framework for stuff like this (e.g. `pear gearman restart`, `pear
> gearman stats`, etc.). Is this allowed? :)


It isn't particularly well commented -  I  had to rtfs of the pear code to
determine what to do and I'm fairly certain there are bits left out

k.

[Igor Feghali-4]

MDB2_Schema - mdb2_schematool

by the way... where is the right path to install those "binaries" ?
currently MDB2_Schema is installing it at MDB2_Schema/bin/ under php
lib dir. but this is something that always annoyed me because
obviously its not a default PATH so I ask whether its ok to install
such executable under /usr/bin or /usr/local ?

how are the other packages handling that ?

regards,
iGor.

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Chuck Burgess-2]

On Wed, Jul 23, 2008 at 7:20 AM, Igor Feghali <igor.feghali@...>
wrote:

> MDB2_Schema - mdb2_schematool
>
> by the way... where is the right path to install those "binaries" ?
> currently MDB2_Schema is installing it at MDB2_Schema/bin/ under php
> lib dir. but this is something that always annoyed me because
> obviously its not a default PATH so I ask whether its ok to install
> such executable under /usr/bin or /usr/local ?
>
> how are the other packages handling that ?
>
> regards,
> iGor.

I'd expect any and all command-line tools to be installed in the
*bin_dir*directory, which from what I've seen is typically the only
PEAR dir you add
to your PATH, if it's even necessary to add it... Ubuntu's pear installation
uses /usr/bin for its *bin_dir*, so no PATH changes are necessary.
--
CRB

[Ken Guest]

On Wed, Jul 23, 2008 at 1:20 PM, Igor Feghali <igor.feghali@...>
wrote:

> MDB2_Schema - mdb2_schematool
>
> by the way... where is the right path to install those "binaries" ?
> currently MDB2_Schema is installing it at MDB2_Schema/bin/ under php
> lib dir. but this is something that always annoyed me because
> obviously its not a default PATH so I ask whether its ok to install
> such executable under /usr/bin or /usr/local ?
>
> how are the other packages handling that ?


If you have a look at the package.xml file for PEAR_Size you'll see I use
the following:
   <file baseinstalldir="/" install-as="pearsize"
md5sum="3b211cf3c3a1ca9b2686b62322bf65db" name="scripts/pearsize.php"
role="script">
    <tasks:replace from="@PHP-BIN@" to="php_bin" type="pear-config" />
    <tasks:replace from="@PACKAGE_VERSION@" to="version" type="package-info"
/>
    <tasks:unixeol />
   </file>

and in the pearsize.php script:
#!@PHP-BIN@
<?php
$lorem = new ipsum();
....
?>

after that I let the pear installer work its "magic" - from the package.xml
it knows, for pearsize.php, to convert any occurances of "@PHP-BIN@" to
whatever value it determines it should be; this is normally /usr/bin or some
such. I also have the version number in that script being updated and have
the script installed to be plain "pearsize" (note there is no ".php" in the
name of that file).

There are details about these tags here
http://pear.php.net/manual/en/guide.developers.package2.tags.php and more
specifically
http://pear.php.net/manual/en/guide.developers.package2.tasks.php for
details on what you can do with the "task" tags.


regards

k.