lsvirtualenv -b on Solaris 11

13 views
Skip to first unread message

Gabriel Carrillo

unread,
Aug 2, 2015, 5:23:21 PM8/2/15
to virtualenvwrapper
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

unread,
Aug 2, 2015, 5:34:42 PM8/2/15
to virtuale...@googlegroups.com

> 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

unread,
Aug 4, 2015, 11:10:37 PM8/4/15
to virtualenvwrapper


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.
Reply all
Reply to author
Forward
0 new messages