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
> >
> > _______________________________________________
> > 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
> >
> _______________________________________________
> 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
_______________________________________________
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
