Poke a Shell Variable with xTalk?

[Jim Ault]

Just as an idea for a different tack to solve this problem.
Can Rev write a file of info and the CGI receive a command to use that file

 >>>*without* saving or reading a file from the hard drive
>>> (why? some new security thing in OSX, Postfix preventing more than
>>> 1024 chars input without introducing a CRLF... even right in the
>>> middle of a word, I'm getting a space in the middle of a word in the
>>> HTML version a complete bad line break in the middle of a word (every
>>> 1024 chars) in the text alternative)
I guess I am thinking that you could save a file from Rev that had
eveything, then pipe a command to use it.

I am not a *nix or Windows guy so I am way out of my depth here.

Jim Ault
Las Vegas

On 9/14/05 6:37 PM, "Sivakatirswami" <katir at hindu.org> wrote:

> Jim, interesting, though I'm not much closer to a solution with this,
> it did prompt me to "think different" find another way to state the
> question.  In OSX we have "open process" but we can't do that for
> Unix process on the same box except through shell..
> 
> Now on our Linux web server I use this CGI for sending mail from
> remote rev Apps, where those apps have no mail services, but simple
> POST a msg to the web server... Now, if I could just "translate" this
> to work from inside a stack on OSX, we would have it.  Or I might
> just use this CGI as is and put this CGI on an internal web site on
> our inhouse OSX Serve... but such a hack!   I would rather be able to
> do this directly from any box...
> 
> ########
> 
> #!/usr/local/bin/revolution
> 
> ## This little CGI simply avoids the need to install an SMTP library
> ## on any client rev app. Instead, I just have the client app build a
> post
> ## string, parse that and let my server's send mail do the rest.
> ## the TO is hard coded, but obviously doesn't need to be.
> ## this saves a lot of headaches debugging email services in a rev
> client app.
> ## and you can do other stuff with this if you want, log it, poke a
> dbase etc.
> 
> on startup
> if $REQUEST_METHOD is "POST" then
>    repeat until length(tDataIn) >= $CONTENT_LENGTH
>      read from stdin until empty
>      put it after tDataIn
>    end repeat
> split tDataIn by "&" and "="
> 
> ## the following is what I've been trying to emulate from the
> "console" version of Rev
> ##  without success...
> 
> put "/usr/sbin/sendmail -t" into mprocess
>          open process mprocess for write
>          write "From:" && (urlDecode (tDataIn["from"]))& cr to
> process mprocess
>          write "To:" &&   "katir at hindu.org"  &  cr to process mprocess
>          write "Subject:" &&   (urlDecode (tDataIn["subject"]))   &
> cr & cr to process mprocess
>         write    (urlDecode (tDataIn["body"])) &  cr to process mprocess
>         close process mprocess
>         put the result into tResponse
> 
> ## in case this is being done from a web form then send back the
> response to port 80
> 
>      put "Content-Type: text/html" & cr
>      put "Content-Length:" && the length of tResponse & cr & cr
>      put tResponse
> 
> end if
> end startup
> 
> 
> 
> 
> 
> On Sep 13, 2005, at 4:10 PM, Jim Ault wrote:
> 
>> This may help, then again, maybe it does not apply to your situation
>> 
>> http://developer.apple.com/technotes/tn2002/tn2065.html
>> 
>> Q: How long can my command be, really?
>> 
>> A: Calling do shell script creates a new sh process, and is therefore
>> subject to the system¹s normal limits on passing data to new
>> processes: the
>> arguments (in this case, the text of your command plus about 40
>> bytes of
>> overhead) and any environment variables may not be larger than
>> kern.argmax,
>> which is currently 262,144 bytes. Because do shell script inherits its
>> parent¹s environment (see the next question), the exact amount of
>> space
>> available for command text depends on the calling environment. In
>> practical
>> terms, this comes out to somewhat more than 261,000 bytes, but unusual
>> environment settings might reduce that substantially.
>> Note: This limit used to be smaller; in Mac OS X 10.2 it was about
>> 65,000
>> bytes. The shell command sysctl kern.argmax will give you the
>> current limit
>> in bytes.
>> 
>> On 9/13/05 6:36 PM, "Sivakatirswami" <katir at hindu.org> wrote:
>> 
>> 
>>> OK the above works, but I want to try now piping tMsg straight into
>>> Send mail *without* saving or reading a file from the hard drive
>>> (why? some new security thing in OSX, Postfix preventing more than
>>> 1024 chars input without introducing a CRLF... even right in the
>>> middle of a word, I'm getting a space in the middle of a word in the
>>> HTML version a complete bad line break in the middle of a word (every
>>> 1024 chars) in the text alternative)
>>> 
>> 
>> or maybe you need to interact with the process directly as in
>> 
>> Q: I have started a background process; how do I get its process ID
>> so I can
>> control it with other shell commands?
>> 
>> A: You can use a feature of sh to do this: the special variable $!
>> is the ID
>> of the most recent background command, so you can echo it as the last
>> command in your shell script, like this:
>> do shell script "my_command &> /dev/null & echo $!"
>> -- result: 621
>> set pid to the result
>> do shell script "renice +20 -p " & pid
>> -- change my_command's scheduling priority.
>> do shell script "kill " & pid
>> -- my_command is terminated.
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>> 
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution