lsvirtualenv -b on Solaris 11

[Gabriel Carrillo]

Hi,

I installed virtualenvwrapper on my Solaris 11 instance via pip, and noticed that running workon with no arguments fails to list my existing virtual envs.  The source of the problem in my case is:

 558 function virtualenvwrapper_show_workon_options {

<...snipped...>

 577     (virtualenvwrapper_cd "$WORKON_HOME" && echo */$VIRTUALENVWRAPPER_ENV_BIN_DIR/activate) 2>/dev/null \

 578         | command \tr "\n" " " \

 579         | command \sed "s|/$VIRTUALENVWRAPPER_ENV_BIN_DIR/activate |/|g" \

 580         | command \tr "/" "\n" \

 581         | command \sed "/^\s*$/d" \

 582         | (unset GREP_OPTIONS; command \egrep -v '^\*$') 2>/dev/null

 583 }

On Solaris 11, GNU sed is not the default, and the three commands highlighted in red produce an empty result with the default sed.  I'm not sure why this is, but I can reproduce this and simulate it with:

$ echo "bar/bin/activate baz/bin/activate foo/bin/activate" | tr "\n" " " | sed 's!/bin/activate !/!g'

For some reason, the above command produces an empty result, while GNU sed works as expected:

$ echo "bar/bin/activate baz/bin/activate foo/bin/activate" | tr "\n" " " | /usr/gnu/bin/sed 's!/bin/activate !/!g'

bar/baz/foo/

A simple workaround for this is:  export PATH="/usr/gnu/bin:$PATH"...  however, I am curious about why the default sed invocation doesn't work.  The tr(1) call preceding it seems to break the pipeline somehow, but I haven't figured it out.  Any ideas?

Thanks,

Gabriel

[Doug Hellmann]

> On Aug 2, 2015, at 4:50 PM, Gabriel Carrillo <erik.g....@gmail.com> wrote:
>
> Hi,
>
> I installed virtualenvwrapper on my Solaris 11 instance via pip, and noticed that running workon with no arguments fails to list my existing virtual envs. The source of the problem in my case is:
>
> 558 function virtualenvwrapper_show_workon_options {
> <...snipped...>
> 577 (virtualenvwrapper_cd "$WORKON_HOME" && echo */$VIRTUALENVWRAPPER_ENV_BIN_DIR/activate) 2>/dev/null \
> 578 | command \tr "\n" " " \
> 579 | command \sed "s|/$VIRTUALENVWRAPPER_ENV_BIN_DIR/activate |/|g" \
> 580 | command \tr "/" "\n" \
> 581 | command \sed "/^\s*$/d" \
> 582 | (unset GREP_OPTIONS; command \egrep -v '^\*$') 2>/dev/null
> 583 }
>
> On Solaris 11, GNU sed is not the default, and the three commands highlighted in red produce an empty result with the default sed. I'm not sure why this is, but I can reproduce this and simulate it with:
>
> $ echo "bar/bin/activate baz/bin/activate foo/bin/activate" | tr "\n" " " | sed 's!/bin/activate !/!g’
>
> For some reason, the above command produces an empty result, while GNU sed works as expected:

What is the output of that command without the sed part, with just the tr?

Does the sed command word if you pass a single value to it:

echo “bar/bin/activate” | sed 's!/bin/activate !/!g’

>
> $ echo "bar/bin/activate baz/bin/activate foo/bin/activate" | tr "\n" " " | /usr/gnu/bin/sed 's!/bin/activate !/!g'
> bar/baz/foo/
>
> A simple workaround for this is: export PATH="/usr/gnu/bin:$PATH"... however, I am curious about why the default sed invocation doesn't work. The tr(1) call preceding it seems to break the pipeline somehow, but I haven't figured it out. Any ideas?

What makes you think it is the tr call? You might be right, but if it is fixed by replacing the sed with a different version, it seems like the problem is with sed not tr.

Doug

>
> Thanks,
> Gabriel
>
> --
> You received this message because you are subscribed to the Google Groups "virtualenvwrapper" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to virtualenvwrap...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Gabriel Carrillo]

On Sunday, August 2, 2015 at 2:34:42 PM UTC-7, Doug Hellmann wrote:

> On Aug 2, 2015, at 4:50 PM, Gabriel Carrillo <erik.g....@gmail.com> wrote:
>
> Hi,
>
> I installed virtualenvwrapper on my Solaris 11 instance via pip, and noticed that running workon with no arguments fails to list my existing virtual envs.  The source of the problem in my case is:
>
>  558 function virtualenvwrapper_show_workon_options {
> <...snipped...>
>  577     (virtualenvwrapper_cd "$WORKON_HOME" && echo */$VIRTUALENVWRAPPER_ENV_BIN_DIR/activate) 2>/dev/null \
>  578         | command \tr "\n" " " \
>  579         | command \sed "s|/$VIRTUALENVWRAPPER_ENV_BIN_DIR/activate |/|g" \
>  580         | command \tr "/" "\n" \
>  581         | command \sed "/^\s*$/d" \
>  582         | (unset GREP_OPTIONS; command \egrep -v '^\*$') 2>/dev/null
>  583 }
>
> On Solaris 11, GNU sed is not the default, and the three commands highlighted in red produce an empty result with the default sed.  I'm not sure why this is, but I can reproduce this and simulate it with:
>
> $ echo "bar/bin/activate baz/bin/activate foo/bin/activate" | tr "\n" " " | sed 's!/bin/activate !/!g’
>
> For some reason, the above command produces an empty result, while GNU sed works as expected:

What is the output of that command without the sed part, with just the tr?

egc@fallover:~$ echo "bar/bin/activate baz/bin/activate foo/bin/activate" | tr "\n" " "

bar/bin/activate baz/bin/activate foo/bin/activate egc@fallover:~$

 

Does the sed command word if you pass a single value to it:

        echo “bar/bin/activate” | sed 's!/bin/activate !/!g’

It does if I add the expected space to the echo argument (otherwise it matches and replaces nothing):

egc@fallover:~$ echo "bar/bin/activate " | sed 's!/bin/activate !/!g'

bar/

 

>
> $ echo "bar/bin/activate baz/bin/activate foo/bin/activate" | tr "\n" " " | /usr/gnu/bin/sed 's!/bin/activate !/!g'
> bar/baz/foo/
>
> A simple workaround for this is:  export PATH="/usr/gnu/bin:$PATH"...  however, I am curious about why the default sed invocation doesn't work.  The tr(1) call preceding it seems to break the pipeline somehow, but I haven't figured it out.  Any ideas?

What makes you think it is the tr call? You might be right, but if it is fixed by replacing the sed with a different version, it seems like the problem is with sed not tr.

Well, if either tr or sed is removed, then the pipeline does the expected thing in either case, but if the both commands are included in the pipeline, then the pipeline breaks.

So, I'm just curious to know what would explain this behavior.  It seems tricky to me, and might be due to a quirk of the original tr or sed.

Also, just as aside, Solaris 11 has several different subtrees containing variants of the typical Unix commands, e.g. /usr/bin (with the original comands), /usr/xpg4/bin and /usr/xpg6/bin for various POSIX specs, and finally /usr/gnu/bin for the GNU versions of commands.  A default installation will give users the original commands, but they can update PATH as I have to get the GNU versions earlier in the search.