Remove shell rc eval step about dtags HOT 5 CLOSED

Hi acrisci,

As far as I know, there is no way to change the working directory without using the shell built-in command cd. And the only way to call cd in your current process is to do it "through the shell" (e.g. alias, function). In other words, there is no way to achieve this with a python (or any other) executable. We would have to use a shell script instead. Even if we did have this d shell script, in order to add it to PATH would still result in the user having to add a line in his/her runtime configuration (not 100% sure). If you can find a way to avoid this I would be more than happy to consider it.

Jay

from dtags.

I didn't think of that. It turns out you are correct.

There is another way that might be a bit cleaner though. You can also change directories by sourceing a shell script that changes directories. So for instance, if chdir.sh contains

cd $1

I can do source chdir.sh ./some-dir to go to the directory. So an alternative to the shell-specific eval, you could distribute /usr/bin/dtags-chdir.sh:

cd $(/usr/bin/dtags-chdir.py $1)

Where dtags-chdir.py is a python script that will echo where to go based on the input.

The benefit of that would be that you could put all your logic in the python script to avoid repeating your logic in many different places. It also has the benefit of simplifying the instructions to telling people to put this in their shellrc file:

alias d="source /usr/bin/dtags-chdir.sh"

for every shell (including the ones you don't support now). Backwards compatability could be achieved by evaling that alias when dtags shell [shell] is evoked.

This is just a thought on how to make things easier. If you like things the way they are, that's fine :).

from dtags.

First of all thanks a lot for all your input. I really appreciate it.

I have considered what you are suggesting (a shell function/script piggybacking on a python executable) in the past, and you are right it definitely has its advantages. The only thing I didn't like about the approach was the fact the python interpreter would be invoked every single time. I've actually tested both methods and as small as it may be, I noticed a small difference in speed (especially on slow VMs). I decided to sacrifice a little bit of convenience during set up in exchange for better overall performance. In fact, in the future I may leave Python altogether and convert the whole tool into a set of shell functions for this very reason.

from dtags.

That is actually a good point. Every milisecond counts when running a command like cd and I'm sure I would notice the difference.

There can be a solution to that, however, that you should consider before you ditch python. It is possible to compile the python files so that they load faster. You should see a big difference in startup times. Whether or not that's good enough I'll leave up to you.

https://docs.python.org/release/1.5.1p1/tut/node43.html

from dtags.

The conversion will probably take a lot research and time to carry out. So it won't happen any time soon, if at all. I've never considered .pyo files. I will try it out when I have time. Thanks!

from dtags.