Alex Ross wrote:

On Jun 3, 2009, at 12:09 PM, Juho Makkonen wrote:

...

Hi,

Many of my Textmate commands are slow and take up to 15 seconds. My problem seems to be the same than the one described in this thread: http://lists.macromates.com/textmate/2006-January/007647.html. The top command shows that the bash seems to be taking up all available CPU cycles while TextMate is loading. This is really annoying, since this happens with even very basic bundle commands like bolding in LaTeX, which renders the commands in LaTeX bundle virtually unusable.

I tried the solution provided in this post: http://lists.macromates.com/textmate/2006-January/007705.html. However, I don't have fink or any other suspicious lines in my .bash_profile, .bash_login or .profile files. Does anyone have any idea on what might possibly cause the problem?

Any chance you could paste your .bash_profile / .profile ?

Sure. Actually neither of those files contains anything at the moment, but /etc/profile contains these lines (they are there by default after the installation, i believe):

# System-wide .profile for sh(1)

if [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi

if [ "${BASH-no}" != "no" ]; then [ -r /etc/bashrc ] && . /etc/bashrc fi

-juho

Allan Odgaard wrote:

On 3 Jun 2009, at 22:07, Juho Makkonen wrote:

...

[...] if [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi

With a long PATH this one can take a _loooong_ time to execute (I filed a performance bug against it), try disable/comment it.

This solved the problem, thanks! What is the point in those lines anyway, does commenting them cause any problems?

-juho

FWIW, I’ve applied the patch at http://gist.github.com/123525 to my system, which takes care of the slowdowns for me. Of course you should backup the path_helper script beforehand, patching system scripts is generally not a good idea, use at your own risk and so on.

Interesting. I didn't know that one. But why do I receive an egrep not found each time I start a bash after having applied this patch?

enas

On 4 Jun 2009, at 18:51, Martin Kühl wrote:

On 04.06.2009, at 19:27, enas wrote:

...

...

FWIW, I’ve applied the patch at http://gist.github.com/123525 to my system, which takes care of the slowdowns for me. Of course you should backup the path_helper script beforehand, patching system scripts is generally not a good idea, use at your own risk and so on.

Interesting. I didn't know that one. But why do I receive an egrep not found each time I start a bash after having applied this patch?

I’d guess that your PATH isn’t set up correctly :-D

Surely :)

(I thought /usr/bin was part of the default PATH bash defines on startup when it’s empty…)

I thought too, that's why I find it strange that this patch doesn't work on my system, which is by any means standard (and I had already come upon this problem), while it works for you (at the author of the patch too I guess). Anyway, that's out of the scope of this discussion (and I did replace egrep by /usr/bin/egrep); I just find it annoying not to understand why things don't work as I thought they should.

enas

On 4 Jun 2009, at 21:39, Scott Haneda wrote:

On Jun 3, 2009, at 11:42 PM, Allan Odgaard wrote:

...

On 3 Jun 2009, at 22:07, Juho Makkonen wrote:

...

[...] if [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi

With a long PATH this one can take a _loooong_ time to execute (I filed a performance bug against it), try disable/comment it.

Where is this code, in which bundle?

This is in /etc/profile — a standard system file.

On 9 Jul 2009, at 17:56, Daniel Sadilek wrote:

This seems to be a principle problem with TextMate. Maybe it should not start a new bash process for every command but keep one running in the background and reuse it!? To prevent interferences, there could also be one process per bundle.

We setup stdin/out and the environment before we launch the interpreter (which is different for each invocation), and we use the return code from the interpreter, changing to a long-living interpreter would be rather problematic/challenging (and one command could easily pollute the environment).

This is clearly an OS problem that can easily be addressed either by the user or Apple.