How do you do TCL exec command on PHP script that uses user input?

[comp.lang.tcl]

The TCL command I am using will do a command-line action on a PHP
script:

set cannotRunPHP [catch {
eval "exec php -q $root/scripts/info/php/info.php"
} errMsg]

I have to do it this way as both the TCL script and the PHP script run
as CLI. However, "info.php" requires user input to run; this causes
the TCL script calling the PHP script to hose up and die.

Is there a way I can do this so that the TCL script can call the PHP
script without any problems? Is there an alternate way of calling the
PHP script other than using exec were that to solve this issue?

Thanks
Phil

[Ulrich Schöbel]

Hi Phillip,

if your php script needs input from stdin, try open.
If it needs input from the terminal, use expect.

Best regards

Ulrich
In article <11**********************@f14g2000cwb.googlegroups .com>,
"comp.lang.tcl" <ph**************@gmail.com> writes:

The TCL command I am using will do a command-line action on a PHP
script:

set cannotRunPHP [catch {
eval "exec php -q $root/scripts/info/php/info.php"
} errMsg]

I have to do it this way as both the TCL script and the PHP script run
as CLI. However, "info.php" requires user input to run; this causes
the TCL script calling the PHP script to hose up and die.

Is there a way I can do this so that the TCL script can call the PHP
script without any problems? Is there an alternate way of calling the
PHP script other than using exec were that to solve this issue?

Thanks
Phil

[comp.lang.tcl]

Ulrich Schöbel wrote:

Hi Phillip,

if your php script needs input from stdin, try open.
If it needs input from the terminal, use expect.
Do you mean http://us2.php.net/manual/en/ref.expect.php ? If so, it'll
be running on PHP 4.1.2 and I have no immediate permissions to download
nor install the PECL expect library either. But something to think
about. PTY?

Phil


Best regards

Ulrich
In article <11**********************@f14g2000cwb.googlegroups .com>,
"comp.lang.tcl" <ph**************@gmail.com> writes:

The TCL command I am using will do a command-line action on a PHP
script:

set cannotRunPHP [catch {
eval "exec php -q $root/scripts/info/php/info.php"
} errMsg]

I have to do it this way as both the TCL script and the PHP script run
as CLI. However, "info.php" requires user input to run; this causes
the TCL script calling the PHP script to hose up and die.

Is there a way I can do this so that the TCL script can call the PHP
script without any problems? Is there an alternate way of calling the
PHP script other than using exec were that to solve this issue?

Thanks
Phil

[Cameron Laird]

In article <dl**********@ctb-nnrp2.saix.net>,
Ulrich Schöbel <ul****@outvert.com> wrote:

Hi Phillip,

if your php script needs input from stdin, try open.
If it needs input from the terminal, use expect.

[Ulrich Schöbel]

Hi Phillip,

In article <11**********************@g43g2000cwa.googlegroups .com>,
"comp.lang.tcl" <ph**************@gmail.com> writes:

Ulrich Schöbel wrote:

Hi Phillip,

if your php script needs input from stdin, try open.
If it needs input from the terminal, use expect.

Do you mean http://us2.php.net/manual/en/ref.expect.php ?

No (Yes?). I don't know much of php. I meant
http://expect.nist.gov/
a Tcl extension/replacement.

Best regards

Ulrich

[Ralf Fassel]

* "comp.lang.tcl" <ph**************@gmail.com>
| set cannotRunPHP [catch {
| eval "exec php -q $root/scripts/info/php/info.php"
| } errMsg]

Get rid of that 'eval' there,
set cannotRunPHP [catch {
exec php -q $root/scripts/info/php/info.php
} errMsg]
is enough and avoids problems with double-eval of $root.

| I have to do it this way as both the TCL script and the PHP script
| run as CLI. However, "info.php" requires user input to run; this
| causes the TCL script calling the PHP script to hose up and die.

Usually, if you exec, TCLs stdin becomes the stdin for the exec'd
process, so there is no immediate reason why the PHP script should
terminate.

If you have the input available inside TCL, you can redirect the stdin
of the exec'd command like this:

# get PHP input from some source
set php_input {some stuff}

# redirect stdin for PHP via <<
set cannotRunPHP [catch {
exec php -q $root/scripts/info/php/info.php << $php_input
} errMsg]

Now the PHP process will see the contents of the TCL php_input
variable on stdin. Check the TCL 'exec' manpage for more details on
input redirection.

HTH
R'

[SM Ryan]

"comp.lang.tcl" <ph**************@gmail.com> wrote:
# The TCL command I am using will do a command-line action on a PHP
# script:
#
# set cannotRunPHP [catch {
# eval "exec php -q $root/scripts/info/php/info.php"
# } errMsg]

As a side note, you don't need to use eval in this command,
and it can actually fail if $root has any spaces. Instead
you can

set cannotRunPHP [catch {
exec php -q $root/scripts/info/php/info.php
} errMsg]

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Where do you get those wonderful toys?

[comp.lang.tcl]

Please see below, thanx

Ralf Fassel wrote:

* "comp.lang.tcl" <ph**************@gmail.com>
| set cannotRunPHP [catch {
| eval "exec php -q $root/scripts/info/php/info.php"
| } errMsg]

Get rid of that 'eval' there,
set cannotRunPHP [catch {
exec php -q $root/scripts/info/php/info.php
} errMsg]
is enough and avoids problems with double-eval of $root.

For some reason that I never understood, leaving off "eval" on TCL exec
commands insured that the file included within eval "exec php -q
[myfile]" would never be run unless I added eval. No explanation at
all.
| I have to do it this way as both the TCL script and the PHP script
| run as CLI. However, "info.php" requires user input to run; this
| causes the TCL script calling the PHP script to hose up and die.

Usually, if you exec, TCLs stdin becomes the stdin for the exec'd
process, so there is no immediate reason why the PHP script should
terminate.

If you have the input available inside TCL, you can redirect the stdin
of the exec'd command like this:

# get PHP input from some source
set php_input {some stuff}

That would not work here that I understood. You are entering the data
yourself. The PHP script will prompt you to enter something:

Enter your username: [here is where you enter something in the command
line]
Etc.
# redirect stdin for PHP via <<
set cannotRunPHP [catch {
exec php -q $root/scripts/info/php/info.php << $php_input
} errMsg]

Now the PHP process will see the contents of the TCL php_input
variable on stdin. Check the TCL 'exec' manpage for more details on
input redirection.

HTH
R'

Maybe if you clarified it a bit more I would know how to implement, as
it is, I'm just as confused as before, I'm afraid and I'm sorry.

Phil

[comp.lang.tcl]

Please see below, thanx

Cameron Laird wrote:

In article <dl**********@ctb-nnrp2.saix.net>,
Ulrich Schöbel <ul****@outvert.com> wrote:

Hi Phillip,

if your php script needs input from stdin, try open.
If it needs input from the terminal, use expect. .
.
.

The TCL command I am using will do a command-line action on a PHP
script:

set cannotRunPHP [catch {
eval "exec php -q $root/scripts/info/php/info.php"
} errMsg]

I have to do it this way as both the TCL script and the PHP script run
as CLI. However, "info.php" requires user input to run; this causes
the TCL script calling the PHP script to hose up and die.

Is there a way I can do this so that the TCL script can call the PHP
script without any problems? Is there an alternate way of calling the
PHP script other than using exec were that to solve this issue?

.
.
.
Ulrich, I suspect this is easier than imagined; neither
[open] nor [expect] will be necessary.

Mr. Powell, I understand your description only partially.
It might take a few trips before you have what you want.

What kind of "user input" does info.php require? When
running info.php on a (Linux?) command-line, do you always
give it the same user input? Is the user input something
like
yes
14
no
? Can you automate info.php with the use of a conventional
shell, on the model of such an example as
php -q $root/scripts/info/php/info.php << HERE
yes
14
no
HERE
?

No, because you will be entering the input yourself via command line.
The PHP script itself will prompt you to enter things like your
username, password, etc, etc., on the command line, from there you will
manually enter the data yourself.

Phil
Incidentally,
eval "exec php -q $root/scripts/info/php/info.php"
does nothing for you that
exec php -q $root/scripts/info/php/info.php
doesn't do better.

[Cameron Laird]

In article <11*********************@o13g2000cwo.googlegroups. com>,
comp.lang.tcl <ph**************@gmail.com> wrote:

[Ralf Fassel]

* "comp.lang.tcl" <ph**************@gmail.com>
| For some reason that I never understood, leaving off "eval" on TCL
| exec commands insured that the file included within eval "exec php
| -q [myfile]" would never be run unless I added eval. No explanation
| at all.

You do not want double quotes there, use
catch {exec php -q myfile}
This will call the command 'exec' with 'php' as first argument, '-p'
as second and 'myfile' as third argument.

If you use
catch {"exec php -q myfile"}
TCL will try to call a 4-word command named
"exec php -q myfile"
with no arguments.

Adding an 'eval' splits this up, but adds a second round of
interpretation. This makes a difference if any of your variables have
special characters in them.
Eg:
set myfile {c:\windows\system32}
catch {exec ls $myfile} res
=> returns 0, directory listing is in $res

catch {"exec ls $myfile"} res
=> returns 1, invalid command name "exec ls c:\windows\system32"

catch {eval "exec ls $myfile"} result
=> returns 1, /usr/bin/ls: c:windowssystem32: No such file or directory

The 'eval' has interpreted the contents of $myfile a second time and
stripped off the backslashes, thus you end up with a wrong file name
when calling the 'ls' command.

Rule of thumb: if you want to use catch around some command
some_cmd arg1 arg2 arg3
just add 'catch {' before the command and '}' after it.
catch { some_cmd arg1 arg2 arg3 }
Do _not_ add additional quoting. From there on, build up further
set err [catch { some_cmd arg1 arg2 arg3 }]
if {$err} { ... }
Or directly
if {[catch { some_cmd arg1 arg2 arg3 }]} { ... }
| The PHP script will prompt you to enter something:
|
| Enter your username: [here is where you enter something in the
| command line] Etc.

Hmm, most probably this does not work because TCL captures the output
of the process and returns it as result of the exec call. So you
don't see the prompt etc.

Try to redirect stdout and stderr when calling the php script, like
this:
catch { exec php -q myfile >@stdout 2>@stderr }

This will redirect stdout of the PHP script to TCLs stdout, and stderr
of the PHP script to TCLs stderr. stdin should already have been
handled by TCL. Again, the manpage for exec describes the details.

| Maybe if you clarified it a bit more I would know how to implement,
| as it is, I'm just as confused as before, I'm afraid and I'm sorry.

I hope this has not added to the confusion :-/

R'

[comp.lang.tcl]

Please see below, thanx!

Cameron Laird wrote:

In article <11*********************@o13g2000cwo.googlegroups. com>,
comp.lang.tcl <ph**************@gmail.com> wrote:
.
.
.

What kind of "user input" does info.php require? When
running info.php on a (Linux?) command-line, do you always
give it the same user input? Is the user input something
like
yes
14
no
? Can you automate info.php with the use of a conventional
shell, on the model of such an example as
php -q $root/scripts/info/php/info.php << HERE
yes
14
no
HERE
?

No, because you will be entering the input yourself via command line.
The PHP script itself will prompt you to enter things like your
username, password, etc, etc., on the command line, from there you will
manually enter the data yourself.

.
.
.
Ah! Does
exec php -q $root/scripts/info/php/info.php >&@stdout <@stdin
get you closer to where you want to be?

Yes it does!! You will have to explain that one to me, though, way
beyond my able to figure it out, but cool!

Problem is that the PHP script contains an exit() function that dies if
user does not input something upon prompting. The TCL script does not
die, it keeps going, which is not the desired effect, but hey I'm
halfway there already, thanx!!

Phil

[Cameron Laird]

In article <11**********************@g14g2000cwa.googlegroups .com>,
comp.lang.tcl <ph**************@gmail.com> wrote:

.
.
.
Ah! Does
exec php -q $root/scripts/info/php/info.php >&@stdout <@stdin
get you closer to where you want to be?

Yes it does!! You will have to explain that one to me, though, way
beyond my able to figure it out, but cool!

[Cameron Laird]

In article <11**********************@g14g2000cwa.googlegroups .com>,
comp.lang.tcl <ph**************@gmail.com> wrote:

[Ralf Fassel]

* "comp.lang.tcl" <ph**************@gmail.com>
| 4) If you just hit the carriage return, it throws an error message "You
| must enter..." and dies
--<snip-snip>--
| However, when the same PHP script is now being accessed by the TCL
| script, it does 1), you do 2), 3) occurs, but if you do 4), instead
| of correctly throwing an error message and dying, it just keeps
| going and lets you enter more "nonentities".

TCL needs some way of knowing whether the PHP script was successful or
not. If the PHP script always exits with status 0 even if no valid
input was given, then TCL needs to check the output of the script.

Here you have the problem that on the one hand, the user needs to see
the prompt (redirect PHP stdout), on the other hand TCLs needs to see
the error message.

If you're lucky, you can change the PHP script to exit non-zero in
case of invalid input. Then the 'catch' in TCL will trigger.

If you're not *that* lucky, but still *somewhat* lucky, the "You must
enter..." message from the PHP script goes to stderr. In that case
just don't redirect stderr when exec'ing the PHP script. Then the
'catch' in TCL will trigger, since anything on stderr of a subprocess
is considered an error in TCL.

if {[catch {exec php -q $root >@stdout} err]} {
puts "error while calling PHP:"
puts "errorCode $::errorCode"
puts "message: $err"
}

If the 'error' message of PHP also goes to stdout, you will have to
use some other means (expect comes to my mind then), since then you
will need to separate the prompt from the rest of the output.

HTH & good luck!
R'

[comp.lang.tcl]

Ralf, at this point I will have to defer this to the PHP gurus out
there as this is beyond what I understand PHP to be able to do.

If I am interpreting correctly, you want the PHP script to write to
stderr the specific error message if the user inputs "nothing" (i.e.,
just hits the carriage return). I just want to be sure I'm clear on
this before I proceed any further with asking PHP folk out there.

I tried the following in TCL to no avail:

[TCL]
if {[catch {exec php -q $root/scripts/php/info.php >@stdout} errMsg]} {
writeErr "Could not run PHP Script: $errMsg"
}
[/TCL]

[Note to PHP people: I believe this might work although I prefer a more
experted opinion:]

[PHP]
if (is_resource(STDERR)) @fputs(STDERR, $errMsg);
[/PHP]

Phil
Ralf Fassel wrote:

* "comp.lang.tcl" <ph**************@gmail.com>
| 4) If you just hit the carriage return, it throws an error message "You
| must enter..." and dies
--<snip-snip>--
| However, when the same PHP script is now being accessed by the TCL
| script, it does 1), you do 2), 3) occurs, but if you do 4), instead
| of correctly throwing an error message and dying, it just keeps
| going and lets you enter more "nonentities".

TCL needs some way of knowing whether the PHP script was successful or
not. If the PHP script always exits with status 0 even if no valid
input was given, then TCL needs to check the output of the script.

Here you have the problem that on the one hand, the user needs to see
the prompt (redirect PHP stdout), on the other hand TCLs needs to see
the error message.

If you're lucky, you can change the PHP script to exit non-zero in
case of invalid input. Then the 'catch' in TCL will trigger.

If you're not *that* lucky, but still *somewhat* lucky, the "You must
enter..." message from the PHP script goes to stderr. In that case
just don't redirect stderr when exec'ing the PHP script. Then the
'catch' in TCL will trigger, since anything on stderr of a subprocess
is considered an error in TCL.

if {[catch {exec php -q $root >@stdout} err]} {
puts "error while calling PHP:"
puts "errorCode $::errorCode"
puts "message: $err"
}

If the 'error' message of PHP also goes to stdout, you will have to
use some other means (expect comes to my mind then), since then you
will need to separate the prompt from the rest of the output.

HTH & good luck!
R'

[Ralf Fassel]

* "comp.lang.tcl" <ph**************@gmail.com>
| If I am interpreting correctly, you want the PHP script to write to
| stderr the specific error message if the user inputs "nothing" (i.e.,
| just hits the carriage return).

The best thing would be a non-zero exit status of the PHP script in
this case. The second best thing would be a message to stderr.

| [TCL]
| if {[catch {exec php -q $root/scripts/php/info.php >@stdout} errMsg]} {
| writeErr "Could not run PHP Script: $errMsg"
| }
| [/TCL]

This 'catch' will trigger if:
- the PHP script exits with nonzero status
% catch {exec false}
1
% set ::errorCode
CHILDSTATUS 23911 1

- the PHP script writes anything to stderr:
% catch {exec sh -c {echo foo >&2}}
1
% set ::errorCode
NONE

You distinguish the two cases by looking at errorCode, it is NONE in
the case of normal exit (status 0) but some output on stderr.

| [PHP]
| if (is_resource(STDERR)) @fputs(STDERR, $errMsg);
| [/PHP]

Well, obviously this will not work as intended if
'is_resource(STDERR)' is false.

R'

[comp.lang.tcl]

It was easier than I thought! An extra PHP die() statement in the PHP
code was all it took for TCL to recognize the abruption and act
accordingly! I also took out the redirection to stderr and all was
fine!

Thanx to you and Cameron Laird (and Ulrich) for all of your help!

Phil

Ralf Fassel wrote:

* "comp.lang.tcl" <ph**************@gmail.com>
| If I am interpreting correctly, you want the PHP script to write to
| stderr the specific error message if the user inputs "nothing" (i.e.,
| just hits the carriage return).

The best thing would be a non-zero exit status of the PHP script in
this case. The second best thing would be a message to stderr.

| [TCL]
| if {[catch {exec php -q $root/scripts/php/info.php >@stdout} errMsg]} {
| writeErr "Could not run PHP Script: $errMsg"
| }
| [/TCL]

This 'catch' will trigger if:
- the PHP script exits with nonzero status
% catch {exec false}
1
% set ::errorCode
CHILDSTATUS 23911 1

- the PHP script writes anything to stderr:
% catch {exec sh -c {echo foo >&2}}
1
% set ::errorCode
NONE

You distinguish the two cases by looking at errorCode, it is NONE in
the case of normal exit (status 0) but some output on stderr.

| [PHP]
| if (is_resource(STDERR)) @fputs(STDERR, $errMsg);
| [/PHP]

Well, obviously this will not work as intended if
'is_resource(STDERR)' is false.

R'