Thanks Mike and Peter, that's indeed got me to the next stage.
Using this technique I can get curl to work correctly (and by using
env/printenv as the command, I can see the differences in the environment) -
as you suspected, the difference is in PATH.
Now the next question (which brings it back on topic): given that I can now
get curl-through-shell to work this way; how can I get LC's native URL
functions to work?
TIA,
Ben
On 21/01/2015 18:05, Mike Bonner wrote:
yeah, same thing as source, I forgot you could . it
On Wed, Jan 21, 2015 at 10:06 AM, Peter Haworth <p...@lcsql.com> wrote:
Courtesy of Dariusz Miedzianogora a while back on this list:
"You could try the following command in the shell call:
. ~/.profile;<your unix command>
The first dot (.) executes the next file. The ~ (tilde) is a shortcut to
the home directory of the user. Since .profile is a shell script that is
executed when the user logs in, this will rerun the .profile script in the
local shell, and you should get the updated path. The semi-colon means that
the command continues, so you can then execute your shell command in the
process instance (and thus the shell instance) that you just refreshed. "
On Jan 21, 2015 8:42 AM, "Mike Bonner" <bonnm...@gmail.com> wrote:
You might check to see the environment variables from the command line,
and
via lc shell, and do a comparison. If I recall correctly, lc shell
environment and the environment you get in a terminal or console can
differ. If the lc shell is using bash, and you know which files are
processed when a terminal session starts, you can "source" them. Source
is
a built in command that processes the file you give it. So if you have a
file .bashrc in your home directory that has the required env variables
set
up you could get shell("source /path/to/my/home/.bashrc; the rest of your
commands here" )
If you can figure out what env variables are missing, but required for
what
you want to do, you can probably include them at the top of your curl ssl
script file
On Wed, Jan 21, 2015 at 8:39 AM, Bob Sneidar <
bobsnei...@iotecdigital.com>
wrote:
Use the sudo command. Sudo allows an administrator account to
masquerade
as root. You will need to provide the current login password when you
do
this. I have successfully put the password as a second line in a
terminal
command. The current login must be an administrator.
Bob S
On Jan 21, 2015, at 07:17 , Ben Rubinstein <benr...@cogapp.com>
wrote:
Bob,
Thanks for replying - I suspect you're right as to the immediate
cause
and where something has changed (it might just be about a new
certificate,
for example).
However, my real question is why it works in terminal but not using
LC
"shell"; although calling the same service does work via LC "shell" on
my
dev machine (including as a standalone).
Where can one affect the context in which a shell command is
executing?
thanks,
Ben
On 20/01/2015 19:12, Bob Sneidar wrote:
I suspect whatever system you are connecting to has modified in some
way how it encrypts data using SSL. Sounds crazy, but Microsoft
recently
did something to their TLS in their cloud offerings that summarily
prevented an entire series of Konica brand copiers from sending email
through Exchange Online. Other series Konicas were fine, and other
manufacturers didn’t seem to have a problem either. I was the only one
saying Microsoft had made changes to their TLS. No one would listen,
citing
all the other copiers that still worked.
Finally Konica released a bulletin telling us to install special
firmware and make some changes in the security settings on the affected
machines. What settings you ask? Why, the TLS settings of course!
Bob S
On Jan 20, 2015, at 10:59 , Ben Rubinstein <benr...@cogapp.com>
wrote:
An app built in LC, sitting on an old box (PPC Mac Mini running
10.4.11) has for several years happily been running a few times a day
to
perform a batch job involving retrieve some data from a remote system,
processing it, and pushing a report to a new location.
Recently, it's not been updating correctly, and investigation has
shown that the cause is a failure to retrieve the remote data.
The remote system (a third-party SaaS product) has a REST
interface,
accessed with simple basic authentication over HTTPS. I'm not aware
that
anything has changed in their API recently.
When I first wrote this app, I found that LC didn't correctly deal
with the SSL portion (I forget the details); so I recoded it to use the
shell function to invoke curl to retrieve each element.
This has worked fine for a long time. But now the shell command
is
returning code 35, which according to man curl is:
35 SSL connect error. The SSL handshaking failed.
So the weird thing is:
- if I run this app on my dev machine (Intel Mac running 10.8.5),
it
works fine, happily invoking curl and getting the result
- if I run the curl command in Terminal on the target machine, it
works fine and retrieves the data
- if I create a shell script to run the curl command on the target
machine, and invoke that shell script in Terminal, it works fine and
retrieves the data
- if I modify the app to use 'shell' to run that shell script,
instead
of calling curl directly, it fails with code 35 again.
So curl, and shell, are happy on that machine; but using shell in
an
LC app to either invoke curl directly, or run a batch script which
invokes
curl, makes SSL fail.
I've marked this possibly OT because I don't think it's necessarily
an
LC problem. I get the same result with a version of the app built in
2011
from LC 4.6.4 as with one built now with LC 6.5.2. But then again, I'm
not
aware that anything has changed on the machine where this runs.
Something must have changed; my guess is that it is something in
the
setup of the remote service. But the nature of that change doesn't
disturb
curl or shell running under Terminal on my target machine; nor when
invoked
from LC on my dev machine.
I'm guessing it must be something to do with the environment in
which
the shell command operates when invoked from LC, as opposed to
launching
a
terminal window. This goes considerably outside my knowledge area, so
I'm
appealing for suggestions as to where to investigate...
TIA
Ben
_______________________________________________
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
