I think I see the problem here:
Any program that can read from stdin and write to stdout can be used as
a CGI, and this includes LC standalones...
- BUT -
LC Server scripts are incompatible with LC Script on the desktop.
In fact, it's that incompatibility that made me switch back to using
standalones for server work many years ago, so it's possible to test and
debug scripts locally without needing to run them in a server
configuration and pray that I never need to debug them. ;)
But switching back to what Jacque and I like to think of as "LC Classic
CGI" means updating scripts that had been written for LC Server's unique
syntax to be compatible with LC Script as implemented in the desktop.
The upside is that LC Script as implemented in the standalone engine is
of course fully compatible with the IDE, leading us to just one rule
that may clarify issues when porting scripts from LC Server:
If you can run it on your desktop, you can run it on your server.
And if you can't run in on your desktop, it won't run on your server.
Using the desktop engine facelessly on the server gives us all the
flexibility we enjoy with LC, which also means we have many ways things
can be set up to execute. Too many to write here.
If you have only one script you'll ever need, you can put it in a
startup handler in the standalone itself.
But I find I use LC standalones so often that I prefer to make a
standalone that's very slender, containing only enough code to read
whatever library stack file is specified in the CGI file called, and
then the standalone runs "start using" with that, and the library
handles everything from there in a libraryStack handler.
Whether the code is in the standalone itself or in a separate stack
file, either way you can't use LC Server's "<?lc" and "?>" tags in any
normal LC Script execution other than in LC Server.
So one way to port your LC Server script below to normal LC Script which
can be run from the IDE or a standalone would be:
--===========================================--
local sOutputBuffer
on startup
cgiStart
DoTheDeed
cgiEnd
end startup
on cgiStart
-- Here you load any libs you need, read any CGI environment
-- variables you might need, etc.:
end cgiStart
on DoTheDeed
set the shellCommand to "CMD"
put "<html>" into sOutputBuffer
put the time after sOutputBuffer
put "<br />" after sOutputBuffer
put Quote & "thes.exe" & Quote &&"-ui" into tShell
try
get shell(tShell)
put "Result:" && the result & cr &"It:" && it after sOutputBuffer
put "<br />" after sOutputBuffer
open process tShell for binary read
read from process tShell until EOF
put "Result:" && the result & cr &"It:" && it after sOutputBuffer
put "<br />" after sOutputBuffer
catch theErr
put theErr
end try
put cr after sOutputBuffer
put the time after sOutputBuffer
put "</html>" after sOutputBuffer
end DoTheDeed
on cgiEnd
put len( sOutputBuffer ) into tLen
-- Send header:
put "Content-Type: text/html" & cr &\
"Date:" && the internet date & cr &\
"Host:" && $SERVER_NAME & cr &\
"Content-Length:"&& tLen &cr&cr into tHeader
put tHeader
-- Send body:
put sOutputBuffer
-- All done:
quit
end cgiEnd
Note a couple of key difference between normal LC Script here and the
specialized form usable only in LC Server:
- Here the "put" command writes immediately to stdout, whereas
in LC Server it writes to an internal buffer.
- LC Server writes the required HTTP header for us, whereas we need
to write that ourselves when using the desktop engine.
So as you see above, rather than using naked "put" commands we instead
put into sOutputBuffer, and then write our header before sending it.
There are other differences as well, such as the enhanced implicit merge
operation done automatically with LC Server files vs. the need to
explicitly call the more limited merge function when processing files
that mix code and HTML. But since you're not doing that we can leave
that for another time.
Keep us posted with how it goes. I use standalones on a wide range of
systems, including one that needs to exchange data with a client's auth
server, so I know the sorts of things you want to do are quite
achievable once you get oriented to moving back to normal LC Script for
standalones.
Tip: For local development it takes only a couple minutes to create a
sort of "server emulator", which sets up any environment variables your
script will be able to get from Apache by just loading them with useful
values yourself. In my setup I use a global in lieu of a socket
connection in my emulator, so I can pass in POST data and get back the
reply all within the IDE, and with complete debugging capabilities.
--
Richard Gaskin
Fourth World Systems
Malte Brill wrote:
has anybody successfully done this? Especially on Windows? I would
like to launch a livecode built application from a liveCode server
script and get the output back (on a Server that I control) Is that
possible? If so, how?
I tried a couple of things to no avail:
<?lc
set the shellCommand to "CMD"
put "<html>"
put the time
put "<br />"
put Quote & "thes.exe" & Quote &&"-ui" into tShell
try
get shell(tShell)
put "Result:" && the result & cr &"It:" && it
put "<br />"
open process tShell for binary read
read from process tShell until EOF
put "Result:" && the result & cr &"It:" && it
put "<br />"
catch theErr
put theErr
end try
put cr
put the time
put "</html>"
?>
the helper app: In the stack script:
on startup
send "boo" to me in 500 millisecs
— to make sure all libs are loaded
end startup
on boo
quit
end boo
on shutdown
write "boo" to stdout
end shutdown
Thanks for all input I can get…
Malte
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
