On 09/01/2016 10:12 AM, Dejan Muhamedagic wrote:
> There is no other way to tell the UNIX/Linux system which
> interpreter to use. Or am I missing something?
Yes: I'm not talking about how it works, I'm talking about how it
doesn't. You can tell the system which interpreter to use, but the
On Wed, Aug 31, 2016 at 10:39:22AM -0500, Dmitri Maziuk wrote:
> On 2016-08-31 03:59, Dejan Muhamedagic wrote:
> >On Tue, Aug 30, 2016 at 12:32:36PM -0500, Dimitri Maziuk wrote:
>
> >>I expect you're being deliberately obtuse.
> >
> >Not sure why do you think that
>
> Because the point I was
On Wed, Aug 31, 2016 at 12:29:59PM +0200, Dejan Muhamedagic wrote:
> > Also remember that sometimes we set a "local" variable in a function
> > and expect it to be visible in nested functions, but also set a new
> > value in a nested function and expect that value to be reflected
> > in the outer
On Tue, Aug 30, 2016 at 06:53:24PM +0200, Lars Ellenberg wrote:
> On Tue, Aug 30, 2016 at 06:15:49PM +0200, Dejan Muhamedagic wrote:
> > On Tue, Aug 30, 2016 at 10:08:00AM -0500, Dmitri Maziuk wrote:
> > > On 2016-08-30 03:44, Dejan Muhamedagic wrote:
> > >
> > > >The kernel reads the shebang
On Tue, Aug 30, 2016 at 12:32:36PM -0500, Dimitri Maziuk wrote:
> On 08/30/2016 11:15 AM, Dejan Muhamedagic wrote:
>
> > I suppose that it is explained in enough detail here:
> >
> > https://en.wikipedia.org/wiki/Shebang_(Unix)
>
> I expect you're being deliberately obtuse.
Not sure why do you
On 08/30/2016 11:15 AM, Dejan Muhamedagic wrote:
> I suppose that it is explained in enough detail here:
>
> https://en.wikipedia.org/wiki/Shebang_(Unix)
I expect you're being deliberately obtuse.
It does not explain which program loader interprets line 1 of findif.sh:
"#!/bin/sh" when it is
On Tue, Aug 30, 2016 at 06:15:49PM +0200, Dejan Muhamedagic wrote:
> On Tue, Aug 30, 2016 at 10:08:00AM -0500, Dmitri Maziuk wrote:
> > On 2016-08-30 03:44, Dejan Muhamedagic wrote:
> >
> > >The kernel reads the shebang line and it is what defines the
> > >interpreter which is to be invoked to
On Tue, Aug 30, 2016 at 10:08:00AM -0500, Dmitri Maziuk wrote:
> On 2016-08-30 03:44, Dejan Muhamedagic wrote:
>
> >The kernel reads the shebang line and it is what defines the
> >interpreter which is to be invoked to run the script.
>
> Yes, and does the kernel read when the script is source'd
On 2016-08-30 03:44, Dejan Muhamedagic wrote:
The kernel reads the shebang line and it is what defines the
interpreter which is to be invoked to run the script.
Yes, and does the kernel read when the script is source'd or executed
via any of the mechanisms that have the executable specified
--
Da: Dejan Muhamedagic
A: gbul...@sonicle.com Cluster Labs - All topics related to open-source
clustering welcomed
Data: 30 agosto 2016 12.20.19 CEST
Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables
Hi,
On Mon, Aug 29, 2016 at 05:08:35PM +0200, Gabriele
ielebulfon
--
Da: Dejan Muhamedagic
A: Cluster Labs - All topics related to open-source clustering welcomed
Data: 30 agosto 2016 10.44.49 CEST
Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables
Hi,
On Mon, Aug 29, 201
> http://www.cdbaby.com/cd/gabrielebulfon
> --
> Da: Dejan Muhamedagic
> A: kgail...@redhat.com Cluster Labs - All topics related to open-source
> clustering welcomed
> Data: 29 agosto 2016 16.43.52 CEST
> Oggett
Hi,
On Mon, Aug 29, 2016 at 10:13:18AM -0500, Dmitri Maziuk wrote:
> On 2016-08-29 04:06, Gabriele Bulfon wrote:
> >Thanks, though this does not work :)
>
> Uhm... right. Too many languages, sorry: perl's system() will call the login
> shell, system system() uses /bin/sh, and exec()s will run
Hi,
On Tue, Aug 30, 2016 at 09:32:54AM +0200, Kristoffer Grönlund wrote:
> Jehan-Guillaume de Rorthais writes:
>
> > On Mon, 29 Aug 2016 10:02:28 -0500
> > Ken Gaillot wrote:
> >
> >> On 08/29/2016 09:43 AM, Dejan Muhamedagic wrote:
> > ...
> >>> I doubt
Jehan-Guillaume de Rorthais writes:
> On Mon, 29 Aug 2016 10:02:28 -0500
> Ken Gaillot wrote:
>
>> On 08/29/2016 09:43 AM, Dejan Muhamedagic wrote:
> ...
>>> I doubt that we could do a moderately complex shell scripts
>>> without capability of limiting the
On 08/29/2016 03:27 PM, Vladislav Bogdanov wrote:
> Maybe #!/bin/ocfsh symlink provided by resource-agents package?
... and that's how lennartware ended up implementing its own syslog...
--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On August 29, 2016 11:07:39 PM GMT+03:00, Lars Ellenberg
wrote:
>On Mon, Aug 29, 2016 at 04:37:00PM +0200, Dejan Muhamedagic wrote:
>> Hi,
>>
>> On Mon, Aug 29, 2016 at 02:58:11PM +0200, Gabriele Bulfon wrote:
>> > I think the main issue is the usage of the "local"
On Mon, Aug 29, 2016 at 04:37:00PM +0200, Dejan Muhamedagic wrote:
> Hi,
>
> On Mon, Aug 29, 2016 at 02:58:11PM +0200, Gabriele Bulfon wrote:
> > I think the main issue is the usage of the "local" operator in ocf*
> > I'm not an expert on this operator (never used!), don't know how hard it is
>
On Mon, 29 Aug 2016 10:02:28 -0500
Ken Gaillot wrote:
> On 08/29/2016 09:43 AM, Dejan Muhamedagic wrote:
...
>> I doubt that we could do a moderately complex shell scripts
>> without capability of limiting the variables' scope and retaining
>> sanity at the same time.
>
>
On 2016-08-29 04:06, Gabriele Bulfon wrote:
Thanks, though this does not work :)
Uhm... right. Too many languages, sorry: perl's system() will call the
login shell, system system() uses /bin/sh, and exec()s will run whatever
the programmer tells them to. The point is none of them cares what
Hi,
On Mon, Aug 29, 2016 at 08:47:43AM -0500, Ken Gaillot wrote:
> On 08/29/2016 04:17 AM, Gabriele Bulfon wrote:
> > Hi Ken,
> >
> > I have been talking with the illumos guys about the shell problem.
> > They all agreed that ksh (and specially the ksh93 used in illumos) is
> > absolutely
opics related to open-source
> clustering welcomed
> Data: 29 agosto 2016 14.36.23 CEST
> Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables
> Gabriele Bulfon
> writes:
> Hi Ken,
> I have been talking with the illumos guys about the shell problem.
> The
On 08/29/2016 03:47 PM, Ken Gaillot wrote:
> On 08/29/2016 04:17 AM, Gabriele Bulfon wrote:
>> Hi Ken,
>>
>> I have been talking with the illumos guys about the shell problem.
>> They all agreed that ksh (and specially the ksh93 used in illumos) is
>> absolutely Bourne-compatible, and that the
On 08/29/2016 04:17 AM, Gabriele Bulfon wrote:
> Hi Ken,
>
> I have been talking with the illumos guys about the shell problem.
> They all agreed that ksh (and specially the ksh93 used in illumos) is
> absolutely Bourne-compatible, and that the "local" variables used in the
> ocf shells is not a
om Cluster Labs - All topics related to open-source
clustering welcomed
kgail...@redhat.com Cluster Labs - All topics related to open-source clustering
welcomed
Data: 29 agosto 2016 14.36.23 CEST
Oggetto: Re: [ClusterLabs] ocf scripts shell and local variables
Gabriele Bulfon
writes:
Hi Ken,
I
Gabriele Bulfon writes:
> Hi Ken,
> I have been talking with the illumos guys about the shell problem.
> They all agreed that ksh (and specially the ksh93 used in illumos) is
> absolutely Bourne-compatible, and that the "local" variables used in the ocf
> shells is not a
Hi Ken,
I have been talking with the illumos guys about the shell problem.
They all agreed that ksh (and specially the ksh93 used in illumos) is
absolutely Bourne-compatible, and that the "local" variables used in the ocf
shells is not a Bourne syntax, but probably a bash specific.
This means
On 2016-08-26 08:56, Ken Gaillot wrote:
On 08/26/2016 08:11 AM, Gabriele Bulfon wrote:
I tried adding some debug in ocf-shellfuncs, showing env and ps -ef into
the corosync.log
I suspect it's always using ksh, because in the env output I produced I
find this: KSH_VERSION=.sh.version
This is
I tried adding some debug in ocf-shellfuncs, showing env and ps -ef into the
corosync.log
I suspect it's always using ksh, because in the env output I produced I find
this: KSH_VERSION=.sh.version
This is normally not present in the environment, unless ksh is running the
shell.
I also tried
29 matches
Mail list logo