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" <[EMAIL PROTECTED]> 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:" && "[EMAIL PROTECTED]" & 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" <[EMAIL PROTECTED]> 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 >> [email protected] >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-revolution >> > > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
