This was never supposed to work. I'm planning to include scl_source script that will handle the functionality a bit differently, take a look at bug 874417.

Should I file a new bug report regarding the manpage? X_SCLS is not documented, the behaviour with nested scl enable invocations is not documented, and this behaviour (and change in behaviour) caught us by surprise.

By the way, I am told the behaviour changed between scl-utils-20120927-2.el6.x86_64 (where scl enable behaved as expected and set PATH in nested invocations) and scl-utils-20120927-2.el6_4.6.x86_64 (where I see the problem I described in the initial report).

(In reply to Miciah Dashiel Butler Masters from comment #3)
> Should I file a new bug report regarding the manpage? X_SCLS is not
> documented, the behaviour with nested scl enable invocations is not
> documented, and this behaviour (and change in behaviour) caught us by
> surprise.

Could I ask what manpage do you have in mind? Scl's man page is intended for users, not for collection maintainers.

Regarding your next comments:
- X_SCLS is an internal of scl-utils, that will not be documented anywhere
- nested scl invocations are possible but the nesting needs to be done in the "command" you execute, not in the scriptlet. SCL starts a subshell so any nesting you make will be lost after the subshell exists. IIRC this is well documented in Software Collections Guide, which is the right place.
- forgive me for being blunt but if you depended on a bug in scl-utils (see below), it's not my fault that the bugfix caught you by surprise

> By the way, I am told the behaviour changed between
> scl-utils-20120927-2.el6.x86_64 (where scl enable behaved as expected and
> set PATH in nested invocations) and scl-utils-20120927-2.el6_4.6.x86_64
> (where I see the problem I described in the initial report).

The behavior did not change. The only change related to this was that enabling one collection multiple times doesn't work anymore. But considering that it was never meant to work, it is not a behavior change, it is a bugfix.

I read scl's manpage as a user, and that is where I would expect to see a caveat about nested invocations.  I use the ruby193 collection; I do not maintain it.

I do not understand the distinction from what I am doing when you say that "the nesting needs to be done in the 'command' you execute, not in the scriptlet." As I understand it, the nesting _is_ occurring in the command I execute.

To go over what happens,

1. when I run /bin/a, its shebang causes the operating system to run /bin/ruby-wrapper /bin/a, which runs scl enable ruby193 'ruby /bin/a', which forks a new ruby process;

2. this new ruby process for /bin/a runs /bin/b;

3. when /bin/a runs /bin/b, it forks a new shell process;

4. this new shell process for /bin/b runs /bin/c;

5. when /bin/b runs /bin/c, the shebang for /bin/c has a shebang that causes the operating system to run /bin/ruby-wrapper /bin/c, which runs scl enable ruby193 'ruby /bin/c'.

I am referring to the execution of scl enable ruby193 'ruby /bin/c' in Step 5 as a nested invocation of scl enable ruby193 because it was done in a process that forked from a process (in Step 3) that was forked from a process (in Step 1) that invoked scl enable ruby193.  I have may have simplified the details, but it seems clear to me that the nesting is being done in the command that I execute.  I am not modifying any scl scriptlets anywhere.

(In reply to Miciah Dashiel Butler Masters from comment #5)
> I read scl's manpage as a user, and that is where I would expect to see a
> caveat about nested invocations.  I use the ruby193 collection; I do not
> maintain it.

As a user you shouldn't have any clue that there is some nested invocation going on. If you do, than that's probably maintainer's fault and I suggest talking to the maintainer of the collection in question.


> I do not understand the distinction from what I am doing when you say that
> "the nesting needs to be done in the 'command' you execute, not in the
> scriptlet." As I understand it, the nesting _is_ occurring in the command I
> execute.

My example was:
bash$ scl enable ruby193 bash
bash_2$ scl enable python27 bash
bash_3$ # now you have python27 and ruby193 enabled


Now this gets a bit tricky, I'm a bit confused by your description, so let's try to make it a bit clear:

> 1. when I run /bin/a, its shebang causes the operating system to run
> /bin/ruby-wrapper /bin/a, which runs scl enable ruby193 'ruby /bin/a', which
> forks a new ruby process;

So step 1 is simply to run "scl enable ruby193 /bin/some_script", right?

> 2. this new ruby process for /bin/a runs /bin/b;
> 3. when /bin/a runs /bin/b, it forks a new shell process;
> 4. this new shell process for /bin/b runs /bin/c;

Ok

> 5. when /bin/b runs /bin/c, the shebang for /bin/c has a shebang that causes
> the operating system to run /bin/ruby-wrapper /bin/c, which runs scl enable
> ruby193 'ruby /bin/c'.

This is a part that I'm confused about. Sounds like /bin/c is recursively executing itself but I'm probably (hopefully) mistaken.

> I am referring to the execution of scl enable ruby193 'ruby /bin/c' in Step
> 5 as a nested invocation of scl enable ruby193 because it was done in a
> process that forked from a process (in Step 3) that was forked from a
> process (in Step 1) that invoked scl enable ruby193.  I have may have
> simplified the details, but it seems clear to me that the nesting is being
> done in the command that I execute.  I am not modifying any scl scriptlets
> anywhere.

Well, this should work *in general* but there are some exceptions. It is for example possible the one of the processes on the way doesn't preserve the environment and tries to compensate for that by enabling one collection twice which is forbidden. Try to communicate that with the maintainer of the collection.

In any case, I still don't see the need to mention the recursive enabling of collections in the man page, it's something that users really shouldn't know about and won't know about if collections built on scl-utils work properly.

I had not seen that example before.  Where does it come from? I do not see it in your earlier comments to this bug report, in the Release Notes[1], or in the manpage for scl, and I am not aware of any other documentation (there is no other official documentation in the scl-utils RPM or on access.redhat.com).

1. https://access.redhat.com/site/documentation/en-US/Red_Hat_Software_Collections/1/html-single/1.0_Release_Notes/index.html

Expanding on your example, the following illustrates the essence of what we are trying to do:

    $ ruby -v
    ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
    $ scl enable ruby193 bash
    $ ruby -v
    ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-linux]
    $ PATH=/usr/bin:/bin
    $ scl enable ruby193 bash
    $ ruby -v
    ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
    $

The above example is silly, so I gave a more realistic example based on real-world usage of Software Collections in a product that we ship where we want the Ruby 1.9.3 interpreter and use a wrapper that scripts can use instead of /usr/bin/ruby (which will be the Ruby 1.8.7 interpreter on RHEL6) in order to enable the ruby193 software collection on RHEL systems in order to ensure that scripts that use that wrapper run with the Ruby 1.9.3 interpreter.  (On Fedora systems, where Ruby 1.9.3 is the default Ruby interpreter, the wrapper is essentially a no-op.)

In your most recent comment regarding our scenario, you speculate that "one of the processes on the way doesn't preserve the environment and tries to compensate for that by enabling one collection twice which is forbidden," and that is exactly is happening.  I now understand where our expectations of scl enable differ from the intentions for its usage, and that it is improper usage of scl enable to use it in a wrapper script for shebangs.  Based on what you are saying now, it seems that we should be using something other than scl enable in our wrapper script.  Perhaps we must hardcode the PATH and LD_LIBRARY_PATH settings in the wrapper script.  If you can suggest a better approach, please let us know! In any case, thank you for explaining what is permissible usage of scl enable!

I'm still not satisfied regarding the documentation.  Your statements that "enabling one collection twice [...] is forbidden" and that you "still don't see the need to mention the recursive enabling of collections in the man page, it's something that users really shouldn't know about" are confusing.  In what sense is enabling one collection twice "forbidden" if the documentation doesn't even mention it?

Furthermore, Software Collections (in particular the scl-utils RPM) ships this nifty tool called "scl" that looked to us like the appropriate tool to use.  In scl-utils-20120927-2.el6.x86_64, scl enable did what we wanted when we told it to enable a collection that had previously been enabled in the same environment.  In scl-utils-20120927-2.el6_4.6.x86_64, scl enable did something else.  (I called this a change in behaviour; you say it is not a change in behaviour and call it a bug fix.) If the documentation had explained what the tool was supposed to do and how it could be used, we might have saved a lot of our time debugging the problem in our wrapper, and we would have saved you the time of dealing with this bug report—and it might save you time in the future by decreasing the probability of people similarly misusing scl enable in the future.  As it is, scl-utils includes a tool that looks like what we want, but isn't.  I'm suggesting that a little more documentation on how scl enable behaves and is intended to be used would have saved us all a lot of time.  We would have known that scl enable was not useful to us.  As it is, it's worth than useless.

By the way, although you said earlier that "X_SCLS is an internal of scl-utils, that will not be documented anywhere," I _did_ find one mention of X_SCLS in the Release Notes[2] when I scanned through it again today:

    The list of Software Collections that are enabled in the current session is stored in the $X_SCLS environment variable, for instance:

    ~]$ echo $X_SCLS
    python27 postgresql92

2. https://access.redhat.com/site/documentation/en-US/Red_Hat_Software_Collections/1/html-single/1.0_Release_Notes/index.html#sect-Installation_and_Usage-Use-Session

Presumably you will want to remove that information from the the documentation (the Release Notes document is the only documentation for Software Collections on access.redhat.com).

Thanks for your time!

s/worth/worse/

>     $ ruby -v
>     ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
>     $ scl enable ruby193 bash
>     $ ruby -v
>     ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-linux]
>     $ PATH=/usr/bin:/bin
>     $ scl enable ruby193 bash
>     $ ruby -v
>     ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]

There is your problem. You are destroying the environment by setting different PATH that scl set before. This kind of tampering with the environment is not anticipated by scl-utils and is also *not* supposed to happen in collection-based packages.

-- snip --

> I'm still not satisfied regarding the documentation.  Your statements that
> "enabling one collection twice [...] is forbidden" and that you "still don't
> see the need to mention the recursive enabling of collections in the man
> page, it's something that users really shouldn't know about" are confusing. 
> In what sense is enabling one collection twice "forbidden" if the
> documentation doesn't even mention it?

Fair enough. But that's SCL maintainers' documentation you are talking about. Feel free to file a bug against that, that's a proper place where this should indeed be mentioned.

> Furthermore, Software Collections (in particular the scl-utils RPM) ships
> this nifty tool called "scl" that looked to us like the appropriate tool to
> use.  In scl-utils-20120927-2.el6.x86_64, scl enable did what we wanted when
> we told it to enable a collection that had previously been enabled in the
> same environment.  In scl-utils-20120927-2.el6_4.6.x86_64, scl enable did
> something else.  (I called this a change in behaviour; you say it is not a
> change in behaviour and call it a bug fix.) If the documentation had
> explained what the tool was supposed to do and how it could be used, we
> might have saved a lot of our time debugging the problem in our wrapper, and
> we would have saved you the time of dealing with this bug report—and it
> might save you time in the future by decreasing the probability of people
> similarly misusing scl enable in the future.

I definitely agree. Again, the maintainers' documentation is a proper place where this should be documented.

-- snip --

> We would have known that scl enable
> was not useful to us.  As it is, it's worth than useless.

That's where you are wrong. It may be useless to your very specific use case but in general it works for most people. If you need a different tool, feel free to drop me an email with specification of what you need and I'll see what I can do about it.

> By the way, although you said earlier that "X_SCLS is an internal of
> scl-utils, that will not be documented anywhere," I _did_ find one mention
> of X_SCLS in the Release Notes[2] when I scanned through it again today:

Fair enough. Not my idea to put it there though, probably someone from documentation team. I still stand by my previous statement that it is an internal and should be treated that way. I'm not sure if it can be removed from the release notes at this point though.