hiya,

anyone know if it's possible to grab the entire commandline
that was used to start up a php script on the CLI, an example
of what I'm looking to grab from within the script (test.php in
this example):

"php -qC -ddisplay_errors=1 ./test.php -o -d -e jochem@iamjochem.com -f ./last.log | grep Exception"

of course I know what the script name and arguments are but I'd rather like the
whole enchilada (php binary and it's args + the pipe to grep).

possible? bad idea? down boy?

Does this work?
$command = implode(' ', $argv);

http://us2.php.net/manual/en/reserve...ables.argv.php


Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com



Jochem Maas wrote:
> hiya,
>
> anyone know if it's possible to grab the entire commandline
> that was used to start up a php script on the CLI, an example
> of what I'm looking to grab from within the script (test.php in
> this example):
>
> "php -qC -ddisplay_errors=1 ./test.php -o -d -e jochem@iamjochem.com
> -f ./last.log | grep Exception"
>
> of course I know what the script name and arguments are but I'd rather
> like the
> whole enchilada (php binary and it's args + the pipe to grep).
>
> possible? bad idea? down boy?
>

On Thu, 2008-08-28 at 10:22 -0500, Micah Gersten wrote:
> Does this work?
> $command = implode(' ', $argv);

Only do it that way if it's for a log of general output. If you're going
to punt any of those parts back to the OS in another command you'll need
to properly escape them.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

2008/8/28 Jochem Maas <jochem@iamjochem.com>:

> anyone know if it's possible to grab the entire commandline
> that was used to start up a php script on the CLI, an example
> of what I'm looking to grab from within the script (test.php in
> this example):
>
> "php -qC -ddisplay_errors=1 ./test.php -o -d -e jochem@iamjochem.com -f
> ./last.log | grep Exception"
>
> of course I know what the script name and arguments are but I'd rather like
> the
> whole enchilada (php binary and it's args + the pipe to grep).
>
> possible? bad idea? down boy?

Not possible, I'm afraid. Certainly not portably. The command line is
manipulated quite heavily before your script gets run. (eg shell
wildcard expansions).

A quick Google suggests that it is possible under VMS, but I doubt
that's much use to you.

--

http://www.otton.org/

Robert Cummings schreef:
> On Thu, 2008-08-28 at 10:22 -0500, Micah Gersten wrote:
>> Does this work?
>> $command = implode(' ', $argv);

no syntax errors, so in that sense it works.
but it doesn't answer my question (check the body of the post as
well as the subject and that might become clear).

> Only do it that way if it's for a log of general output. If you're going
> to punt any of those parts back to the OS in another command you'll need
> to properly escape them.

true, and yes it's for a log and no join(' ', $argv); doesn't cut it :-)

>
> Cheers,
> Rob.

David Otton schreef:
> 2008/8/28 Jochem Maas <jochem@iamjochem.com>:
>
>> anyone know if it's possible to grab the entire commandline
>> that was used to start up a php script on the CLI, an example
>> of what I'm looking to grab from within the script (test.php in
>> this example):
>>
>> "php -qC -ddisplay_errors=1 ./test.php -o -d -e jochem@iamjochem.com -f
>> ./last.log | grep Exception"
>>
>> of course I know what the script name and arguments are but I'd rather like
>> the
>> whole enchilada (php binary and it's args + the pipe to grep).
>>
>> possible? bad idea? down boy?
>
> Not possible, I'm afraid. Certainly not portably. The command line is
> manipulated quite heavily before your script gets run. (eg shell
> wildcard expansions).

I have a feeling I'm out of luck - probably security issues that keep
you from doing such a thing as well.

I did have the idea of grabbing the PID and then grepping the output of
ps via exec() ... that would do it, but I reckon it smells. :-)

> A quick Google suggests that it is possible under VMS, but I doubt
> that's much use to you.

STW wasn't giving me any joy either, it's for linux only (although it
would be nice if it worked on my Mac)

>

I suggest creating a shell wrapper for PHP that will write the command
to a file for you and then call PHP with the appropriate arguments. PHP
won't even see most of the command that you originally posted.

Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com



Jochem Maas wrote:
> Robert Cummings schreef:
>> On Thu, 2008-08-28 at 10:22 -0500, Micah Gersten wrote:
>>> Does this work?
>>> $command = implode(' ', $argv);
>
> no syntax errors, so in that sense it works.
> but it doesn't answer my question (check the body of the post as
> well as the subject and that might become clear).
>
>> Only do it that way if it's for a log of general output. If you're going
>> to punt any of those parts back to the OS in another command you'll need
>> to properly escape them.
>
> true, and yes it's for a log and no join(' ', $argv); doesn't cut it :-)
>
>>
>> Cheers,
>> Rob.

Micah Gersten schreef:
> I suggest creating a shell wrapper for PHP that will write the command
> to a file for you and then call PHP with the appropriate arguments. PHP
> won't even see most of the command that you originally posted.

which wouldn't catch the pipe to grep now would it. nevermind, I don't think
you ge what I was looking for, not worry I can hack together a 'solution'
using exec() ... by grepping the output of ps.

> Thank you,
> Micah Gersten
> onShore Networks
> Internal Developer
> http://www.onshore.com
>
>
>
> Jochem Maas wrote:
>> Robert Cummings schreef:
>>> On Thu, 2008-08-28 at 10:22 -0500, Micah Gersten wrote:
>>>> Does this work?
>>>> $command = implode(' ', $argv);
>> no syntax errors, so in that sense it works.
>> but it doesn't answer my question (check the body of the post as
>> well as the subject and that might become clear).
>>
>>> Only do it that way if it's for a log of general output. If you're going
>>> to punt any of those parts back to the OS in another command you'll need
>>> to properly escape them.
>> true, and yes it's for a log and no join(' ', $argv); doesn't cut it :-)
>>
>>> Cheers,
>>> Rob.
>

On Fri, 2008-08-29 at 04:48 +0200, Jochem Maas wrote:
> Micah Gersten schreef:
> > I suggest creating a shell wrapper for PHP that will write the command
> > to a file for you and then call PHP with the appropriate arguments. PHP
> > won't even see most of the command that you originally posted.
>
> which wouldn't catch the pipe to grep now would it. nevermind, I don't think
> you ge what I was looking for, not worry I can hack together a 'solution'
> using exec() ... by grepping the output of ps.

I doubt it. The ps command sees what the script sees. If I do mplayer
*.avi, ps shows me the expanded file list that was given to mplayer.
Remember, shell gets first dibs before anything happens. BTW your
subject line does not imply that you wanted the EXACT command line
used

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

2008/8/28 Jochem Maas <jochem@iamjochem.com>:

> I have a feeling I'm out of luck - probably security issues that keep
> you from doing such a thing as well.
>
> I did have the idea of grabbing the PID and then grepping the output of
> ps via exec() ... that would do it, but I reckon it smells. :-)

That won't work.

Quote the entire command as a string. Pass it to a shell script that
sets an environment variable to that string, then executes the string.

--

http://www.otton.org/

Robert Cummings schreef:
> On Fri, 2008-08-29 at 04:48 +0200, Jochem Maas wrote:
>> Micah Gersten schreef:
>>> I suggest creating a shell wrapper for PHP that will write the command
>>> to a file for you and then call PHP with the appropriate arguments. PHP
>>> won't even see most of the command that you originally posted.
>> which wouldn't catch the pipe to grep now would it. nevermind, I don't think
>> you ge what I was looking for, not worry I can hack together a 'solution'
>> using exec() ... by grepping the output of ps.
>
> I doubt it. The ps command sees what the script sees. If I do mplayer
> *.avi, ps shows me the expanded file list that was given to mplayer.

output after shell expansion is fine, I'm interested in knowing what
arguments we're given to the php interpreter, for example
(other than the scriptname and *it's* args which are readily available
via $argv) and where ever the output is being piped or redirected to.

> Remember, shell gets first dibs before anything happens. BTW your
> subject line does not imply that you wanted the EXACT command line
> used

lol

>
> Cheers,
> Rob.

David Otton schreef:
> 2008/8/28 Jochem Maas <jochem@iamjochem.com>:
>
>> I have a feeling I'm out of luck - probably security issues that keep
>> you from doing such a thing as well.
>>
>> I did have the idea of grabbing the PID and then grepping the output of
>> ps via exec() ... that would do it, but I reckon it smells. :-)
>
> That won't work.

in what sense won't it work? the complete line is in the output of ps somewhere
albeit after wildcard/shell expansion.

>
> Quote the entire command as a string. Pass it to a shell script that
> sets an environment variable to that string, then executes the string.

if life were that simple. it's user X running the php script from the
commandline ... I wanna know exactly what he is doing (which is not
necessarily the same as what he should be doing). I only really control
the php script in question not the context it is run in.

>

On 29 Aug 2008, at 19:46, Jochem Maas wrote:
> David Otton schreef:
>> 2008/8/28 Jochem Maas <jochem@iamjochem.com>:
>>> I have a feeling I'm out of luck - probably security issues that
>>> keep
>>> you from doing such a thing as well.
>>>
>>> I did have the idea of grabbing the PID and then grepping the
>>> output of
>>> ps via exec() ... that would do it, but I reckon it smells. :-)
>> That won't work.
>
> in what sense won't it work? the complete line is in the output of
> ps somewhere
> albeit after wildcard/shell expansion.
>
>> Quote the entire command as a string. Pass it to a shell script that
>> sets an environment variable to that string, then executes the
>> string.
>
> if life were that simple. it's user X running the php script from the
> commandline ... I wanna know exactly what he is doing (which is not
> necessarily the same as what he should be doing). I only really
> control
> the php script in question not the context it is run in.

I think the only way to do what you want is to parse the output from
ps with appropriate arguments. You'll probably need to find the parent
process of your PHP script. Don't think you're going to find a
portable way to do it.

-Stut

--
http://stut.net/

Stut schreef:
> On 29 Aug 2008, at 19:46, Jochem Maas wrote:
>> David Otton schreef:
>>> 2008/8/28 Jochem Maas <jochem@iamjochem.com>:
>>>> I have a feeling I'm out of luck - probably security issues that keep
>>>> you from doing such a thing as well.
>>>>
>>>> I did have the idea of grabbing the PID and then grepping the output of
>>>> ps via exec() ... that would do it, but I reckon it smells. :-)
>>> That won't work.
>>
>> in what sense won't it work? the complete line is in the output of ps
>> somewhere
>> albeit after wildcard/shell expansion.
>>
>>> Quote the entire command as a string. Pass it to a shell script that
>>> sets an environment variable to that string, then executes the string.
>>
>> if life were that simple. it's user X running the php script from the
>> commandline ... I wanna know exactly what he is doing (which is not
>> necessarily the same as what he should be doing). I only really control
>> the php script in question not the context it is run in.
>
> I think the only way to do what you want is to parse the output from ps
> with appropriate arguments. You'll probably need to find the parent
> process of your PHP script.

yeah, the 'grab the PID' explaination was too simplistic, actually I should
be able to grep on the scriptname - it will only run if no other instances are
already running (race conditions aside ;-))

> Don't think you're going to find a portable
> way to do it.

portability not needed beyond linux and MacOS. thank goodness :-)
at least it's doable ... and the smell will be running on someone else's
hardware :-P

>
> -Stut
>

2008/8/29 Jochem Maas <jochem@iamjochem.com>:

> in what sense won't it work? the complete line is in the output of ps
> somewhere
> albeit after wildcard/shell expansion.

With the pipe? I'd really like to see an example, beacuse I couldn't
coax it out of ps, and it might be handy someday.

> if life were that simple. it's user X running the php script from the
> commandline ... I wanna know exactly what he is doing (which is not
> necessarily the same as what he should be doing). I only really control
> the php script in question not the context it is run in.

You should have said... you are the admin of the machine, right? Patch
bash to log user input. Google variations on bash, patch and syslog.

--

http://www.otton.org/

You can rename the php executable and replace it with a shell script
that logs what is run.

Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com



Jochem Maas wrote:
> David Otton schreef:
>>
>> Quote the entire command as a string. Pass it to a shell script that
>> sets an environment variable to that string, then executes the string.
>
> if life were that simple. it's user X running the php script from the
> commandline ... I wanna know exactly what he is doing (which is not
> necessarily the same as what he should be doing). I only really control
> the php script in question not the context it is run in.
>
>>
>
>

On Fri, 2008-08-29 at 20:42 +0200, Jochem Maas wrote:
> Robert Cummings schreef:
> > On Fri, 2008-08-29 at 04:48 +0200, Jochem Maas wrote:
> >> Micah Gersten schreef:
> >>> I suggest creating a shell wrapper for PHP that will write the command
> >>> to a file for you and then call PHP with the appropriate arguments. PHP
> >>> won't even see most of the command that you originally posted.
> >> which wouldn't catch the pipe to grep now would it. nevermind, I don't think
> >> you ge what I was looking for, not worry I can hack together a 'solution'
> >> using exec() ... by grepping the output of ps.
> >
> > I doubt it. The ps command sees what the script sees. If I do mplayer
> > *.avi, ps shows me the expanded file list that was given to mplayer.
>
> output after shell expansion is fine, I'm interested in knowing what
> arguments we're given to the php interpreter, for example
> (other than the scriptname and *it's* args which are readily available
> via $argv) and where ever the output is being piped or redirected to.

You won't get redirection or piping from the following but it will give
you the command line info you wanted:

<?php

$info = implode( '', file( '/proc/'.posix_getpid().'/cmdline' ) );
$info = explode( "\x0", $info );
print_r( $info );

?>

Probably doesn't run on windows, and I don't care enough to even think
about checking

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

On Fri, 2008-08-29 at 15:36 -0400, Robert Cummings wrote:
> On Fri, 2008-08-29 at 20:42 +0200, Jochem Maas wrote:
> > Robert Cummings schreef:
> > > On Fri, 2008-08-29 at 04:48 +0200, Jochem Maas wrote:
> > >> Micah Gersten schreef:
> > >>> I suggest creating a shell wrapper for PHP that will write the command
> > >>> to a file for you and then call PHP with the appropriate arguments. PHP
> > >>> won't even see most of the command that you originally posted.
> > >> which wouldn't catch the pipe to grep now would it. nevermind, I don't think
> > >> you ge what I was looking for, not worry I can hack together a 'solution'
> > >> using exec() ... by grepping the output of ps.
> > >
> > > I doubt it. The ps command sees what the script sees. If I do mplayer
> > > *.avi, ps shows me the expanded file list that was given to mplayer.
> >
> > output after shell expansion is fine, I'm interested in knowing what
> > arguments we're given to the php interpreter, for example
> > (other than the scriptname and *it's* args which are readily available
> > via $argv) and where ever the output is being piped or redirected to.
>
> You won't get redirection or piping from the following but it will give
> you the command line info you wanted:
>
> <?php
>
> $info = implode( '', file( '/proc/'.posix_getpid().'/cmdline' ) );
> $info = explode( "\x0", $info );
> print_r( $info );
>
> ?>
>
> Probably doesn't run on windows, and I don't care enough to even think
> about checking

BTW, you can also look into hacking the bash binary. Several years ago I
wanted to log the command-line to a database table and I hacked the bash
binary to trap history and send to database log.

Isn't open source a beautiful thing

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

Robert Cummings schreef:
> On Fri, 2008-08-29 at 15:36 -0400, Robert Cummings wrote:
>> On Fri, 2008-08-29 at 20:42 +0200, Jochem Maas wrote:
>>> Robert Cummings schreef:
>>>> On Fri, 2008-08-29 at 04:48 +0200, Jochem Maas wrote:
>>>>> Micah Gersten schreef:
>>>>>> I suggest creating a shell wrapper for PHP that will write the command
>>>>>> to a file for you and then call PHP with the appropriate arguments. PHP
>>>>>> won't even see most of the command that you originally posted.
>>>>> which wouldn't catch the pipe to grep now would it. nevermind, I don't think
>>>>> you ge what I was looking for, not worry I can hack together a 'solution'
>>>>> using exec() ... by grepping the output of ps.
>>>> I doubt it. The ps command sees what the script sees. If I do mplayer
>>>> *.avi, ps shows me the expanded file list that was given to mplayer.
>>> output after shell expansion is fine, I'm interested in knowing what
>>> arguments we're given to the php interpreter, for example
>>> (other than the scriptname and *it's* args which are readily available
>>> via $argv) and where ever the output is being piped or redirected to.
>> You won't get redirection or piping from the following but it will give
>> you the command line info you wanted:
>>
>> <?php
>>
>> $info = implode( '', file( '/proc/'.posix_getpid().'/cmdline' ) );
>> $info = explode( "\x0", $info );
>> print_r( $info );
>>
>> ?>
>>
>> Probably doesn't run on windows, and I don't care enough to even think
>> about checking
>
> BTW, you can also look into hacking the bash binary. Several years ago I
> wanted to log the command-line to a database table and I hacked the bash
> binary to trap history and send to database log.

didn't know about that bit of /proc, thanks :-)

>
> Isn't open source a beautiful thing

rather like frankenastein's bride :-P

> Cheers,
> Rob.

David Otton schreef:
> 2008/8/29 Jochem Maas <jochem@iamjochem.com>:
>
>> in what sense won't it work? the complete line is in the output of ps
>> somewhere
>> albeit after wildcard/shell expansion.
>
> With the pipe? I'd really like to see an example, beacuse I couldn't
> coax it out of ps, and it might be handy someday.

ah okay, wasn't sure about the pipe, figured it might not show up in ps.

>
>> if life were that simple. it's user X running the php script from the
>> commandline ... I wanna know exactly what he is doing (which is not
>> necessarily the same as what he should be doing). I only really control
>> the php script in question not the context it is run in.
>
> You should have said... you are the admin of the machine, right? Patch
> bash to log user input. Google variations on bash, patch and syslog.

I'll take a gander, although I doubt I'll get permission to actually patch
something like that ... client is pretty adament about having a std box.

anyway, Im much the wiser, thanks for the info everyone.

>

Micah Gersten schreef:
> You can rename the php executable and replace it with a shell script
> that logs what is run.

true, but that still wouldn't get me the pipe, besides which one day
someone will figure out that it's not the actual executable and either:

1. recompile and install php (shell script overwritten)
2. start using the actual binary instead

in both cases they'd probably think they're doing something smart :-)
which is why it would be nice to do it from with in my own script without
tweaking/hacking anything on the system. it's then self contained and
because I deliver the script I control it's functionality

of course the script could be edited, but if a 3rd party or the client
does *that* then I'm no longer responsible ... currently I'm not responsible
for the system/server itself (although I have full access) and I'd like to keep
it that way ... sysadmin is a special kind of beast, I'm of another genus

> Thank you,
> Micah Gersten
> onShore Networks
> Internal Developer
> http://www.onshore.com
>
>
>
> Jochem Maas wrote:
>> David Otton schreef:
>>> Quote the entire command as a string. Pass it to a shell script that
>>> sets an environment variable to that string, then executes the string.
>> if life were that simple. it's user X running the php script from the
>> commandline ... I wanna know exactly what he is doing (which is not
>> necessarily the same as what he should be doing). I only really control
>> the php script in question not the context it is run in.
>>
>>
>