auraphp / aura.cli Goto Github PK

just voicing some concerns

why the Aura\Cli\CliFactory methods are not public static?

if they can be, will you take a PR from me doing this?

From the "it would be nice" department...

I'd like the OPTIONS sections formatted like this:

    -f, --foo=<value>

instead of the current:

    -f <value>
    --foo=<value>

It strikes me as peculiar that I can pass a value as:

mycommand -f 99
mycommand --foo=99

But not as:

mycommand --foo 99

At least, according to the help text.

And I really ought to go figure out how to write PhpUnit tests, so that I can start sending pull requests. I'm using PhpSpec for my own code.

This test here is a bit misleading because it assumes we are using the framework,
https://github.com/auraphp/Aura.Cli/blob/develop-2/tests/config/DefaultTest.php#L4
could it be that we can move this to the respective glue package?

Sounds like V2 packages intend to have some level of 5.3 support. In that area some builds don't have posix_isatty function available which occurs in Stdio::setPosix() since error reporting is turned off, when this happens it is hard to know without step debugging, as for example $stdio = $cliFactory->newStdio(); will just die with no output/php error. Perhaps a function_exists and Throwing of an exception may be warranted.

Not sure what the Aura take is on expected support is scenarios like this, just wanted you to be aware. Thanks!

It would be nice to have an Aura\Cli\Help::getHelpArguments() formatting function in the same vein as the others, but used for describing the positional arguments. (feature request)

In 7fff85a you moved getOptions() from GetOpt to GetOptParser

This change broke our custom build help system. (which we made before you added https://github.com/auraphp/Aura.Cli/blob/develop-2/src/Help.php).

The primary problem is that we used $getopt->getOptions() and then looped over the options and outputted our own pretty-formatted help. As far as I am aware, there is now no way to access the getOptions() call, which has moved to GetOptParser.

Is there a way we can access GetOptParser->getOptions() ?

Hello,
when we have required parameters that where not setted, the systems don't make any error. It should provide any error on hasError ...

Example :

$options = array(
    'action,a:',
    'module,m:'
);
$getOpt = $context->getopt($options);

// check errors
if ($getOpt->hasErrors())
{
    foreach ($getOpt->getErrors() as $error)
    {
        $stdio->errln($error->getMessage());
    }
    exit(Status::USAGE);
}

when I try this with php cli.php -a test I have no error ....

tested on php 5.3

A recent change broke the color rendering in Aura for us.

Our setup is that we are using PuTTY to SSH into a Gentoo server, not sure if that's relevant. The problem is present in both PHP version PHP 5.3.28-pl1-gentoo (cli) (built: Mar 10 2014 18:34:15) and PHP 5.4.23-pl0-gentoo (cli) (built: Mar 10 2014 18:17:14)

I did a bisect, and the offending commit seems to be:

ddcb86be93c9b8ed6991fe98a9d5733970a58399 is the first bad commit
commit ddcb86be93c9b8ed6991fe98a9d5733970a58399
Author: Paul M. Jones <[email protected]>
Date:   Tue Apr 15 20:42:39 2014 -0500

    soothe the scrutinizer

Here are some screenshots that show this:

(./minion is an executable script we created to run cli commands using Aura)

It seems that casting the file descriptor to an int is somehow making Aura think it isn't a TTY anymore. I'm not really sure why that happens, since the php docs say that you should pass in an int.

What was the context for casting it to an int in order to "soothe the scrutinizer"? If casting to an int is necessary for scrutinizer to pass, the following line could be a solution:

 $this->posix = posix_isatty($this->resource) OR posix_isatty((int) $this->resource);

Probably password prompt seems a good one.

Couple of examples and implementations

http://stackoverflow.com/questions/187736/command-line-password-prompt-in-php

http://www.sitepoint.com/interactive-cli-password-prompt-in-php/

http://www.dasprids.de/blog/2008/08/22/getting-a-password-hidden-from-stdin-with-php-cli

http://stackoverflow.com/questions/297850/is-it-really-not-possible-to-write-a-php-cli-password-prompt-that-hides-the-pass

Hi @pmjones ,

I wonder why we need to pass php://stdin , php://stdout, php://stderr as we already have the constants and utilize it ?

new Stdio(
    fopen('php://stdin', 'r'),
    fopen('php://stdout', 'w+'),
    fopen('php://stderr', 'w+'),
    new Vt100
),

I was looking over http://www.php.net/manual/en/features.commandline.io-streams.php

Thanks

Hari K T

I'm using this package in a small project, and need to access the rest of the parsed commandline arguments, since they can be dynamic.

There doesn't appear to be a way to get the entire parsed AbstractValues::$values array, so it would be nice if there were an AbstractValues::getValues() method.

It would also be nice to implement the SPL ArrayAccess, SeekableIterator, and Countable interfaces so that AbstractValues instances can be iterated just like an array.

Context::getopt() (probably) doesn't allow for the Unix convention of shortening options by concatenating them. Example:

896 pds/skeleton$ tar -c -v -f foo.tar src/
a src
a src/ComplianceValidator.php
a src/Console.php
a src/PackageGenerator.php
a src/TestRunner.php


897 pds/skeleton$ tar -cvf foo.tar
src/
src/ComplianceValidator.php
src/Console.php
src/PackageGenerator.php
src/TestRunner.php

Note how first call to tar uses separated arguments -c -v and -f foo.tar, compared to second call where -cvf are concatenated. Most *nix commands follow this convention.

However when using Aura.Cli with the latter (concatenated) case, $getopt->get('-f') returns 1 instead of foo.tar.

Is there a way to pass arguments to the command init?

E.g. I wrote a "shell" that opens other commands - and I need pass the arguments/parameters of the shell command to the one that get's executed from within it.

Thanks :)

A light weight progress bar . Here is one

https://github.com/harikt/Aura.Cli/commit/0b1d0278cc0ec599a70b260073fa895f937d9611

video at http://www.screencast.com/users/brianlmoon/folders/Jing/media/822d9970-a6a3-4071-bdc6-1303cce9800a

taken from http://brian.moonspot.net/php-progress-bar by Brian Moon

Hi again

If you "nest" options within other options this leads to problems.

Example: --option="sometext -parameter"

Parameter now will be recognized as an Aura option.

In my use case I need to enter shell commands like hostname -f - thus, this will fail.

Therefor text entered between "" entered right after an option should be ignored.

could you please describe the branching model you are using? thanks 👶

Should I be using v1 or v2? Has the documentation been updated to v2?

I can obviously extend class Help and override method getHelp() to create a class of my own which does the following, but would you consider incorporating it into Aura.Cli itself? If so, I'll provide a PR.

I'd like to be able to append additional "sections" of output to what's returned by getHelp(), so that they would appear after the OPTIONS section. For example (via some quick hacking), an EXAMPLES section:

OPTIONS
    -v
    --verbose
        Verbose output.

    -h
    --help
        This help.

    -c [<value>]
        Config file directory (default: ./conf).

EXAMPLES
    generate build -v

i wonder if we can remove the @Package old habit 😊 i would like to send PRs to all repos getting rid of them and also @author info if possible and redudant docblocks with the same class name when standing a lone

Using the example from the Aura.Cli README.md, I tried to retrieve the value of an environment variable. It failed. Upon debugging, I found that the $_ENV super global was empty. The reason was because my laptop and my employer's servers all have

variables_order = "GPCS"

in the lynx.ini files. That is to say, $_ENV super global and its equivalents never get set without the "E": http://php.net/manual/en/reserved.variables.environment.php#98113

This is apparently a common configuration these days.

Strangely, the environment variables were all imported into the $_SERVER super global. This is documented as being true whenever "S" is specified for the CGI and FastCGI SAPIs, but no mention of the CLI SAPI is made: http://us.php.net/manual/en/ini.core.php#ini.variables-order

The only reliable way to get environment variables seems to be getenv().

This is really a PHP problem, and probably a result of the CLI SAPI being a "poor stepchild" in PHP for so long. But it seems like Aura.Cli should do its best to try to work around it. A CLI program with environment variables is like a web application without a Document Root.

I'd provide pull requests for potential patches except at the moment, I'm not sure what the cleanest way to fix this is.