Storing symlinks about z

[rupa]

I've tested this, changed pwd -P to pwd, and visited /var/run, which is a symlink to /run on my system. The symlink was not resolved, was listed in the datafile and the output of z -l correctly, and used correctly.

Keep in mind that removing the -P is not going to remove existing entries in the datafile (where symlinks were previously resolved). I ended up with entries for both /var/run and /run in my datafile, so typing z run went to whichever one had the highest ranking.

As far as which behavior should be default, I can't remember what led me to want to resolve symlinks - in my current use I don't have a strong feeling one way or the other. I'm tempted to make the behavior configurable, but then we'd still want the default to be what's best for most people. I'm open to comment, argument, suggestion on this topic.

[denis-sokolov]

Thank you for a quick response.

I've just tested it on two more machines. On my Ubuntu 12.04 and bash it does, indeed work.
However, on an older Ubuntu 11.04 and on a FreeBSD box it has problems as I mentioned in the first post.

It's likely to be my issue, but if you would be kind as to not close the issue until I confirm that.
I'll test some more and let you know the results next week.

I do think that it would be nice to make the behaviour configurable.
My main use case for not resolving symlinks is this:
I create many helper links in my home directory or anywhere else.
It might be a ~/sites -> /var/opt/httpd/var/www/sites/ or something similar.
I might be using that link all the time and I'd love to z sites to go there.
But symlink resolving creates a few usability problems:

• My prompt looks like hell: local /var/opt/httpd/var/www/sites/ $
• I can't access my other links and locations with cd ../servers anymore.
• I can't rename my symlinks. For instance, I might have ~/servers/apache and ~/servers/nginx, with both leading to specific locations. Apache might even be installed in httpd directory and not have "apache" in it's name.

[denis-sokolov]

I don't think the problem is with my setup.
But I've investigated and I have found the whereabouts of the bug.

I have the bug on two boxes:
*bash 4.2.24(1) on FreeBSD 8.3-RELEASE
*bash 4.2.8(1) on Ubuntu 11.04 (Linux 2.6.38-15-generic-pae).

I have found that if I comment line 179 in z.sh (if( notdir($1) ) next),
everything works as expected.
So I guess the logic in notdir (line 134) is not completely perfect.

Unfortunately, I can't help debug that, as I have no clue how that works.
I am willing, however, to follow your instructions, if any, to help pinpoint the problem.

[rupa]

OK, notdir() is a terrible hack to avoid doing a system call in awk (slow) to determine whether a path is a directory. It works by constructing a relative path to a known file from a given absolute path. If it can read a line from the file given the relative path, you must've passed a directory.
I don't see a way to 'fix' the function, as its behavior obviously varies on different platforms, but I'll try to find a possible alternative.

[rupa]

I've pushed a branch eliminate_notdir that does directory testing in shell before piping the results to awk. Try that one out and see if results are more consistent (you'll still have to edit to make pwd -P just pwd.

[clvv]

@rupa yes, it was an ugly hack. I came up with the same solution not too long after I submitted the pull request. I tried to let you know (#41 (comment)). But I guess you did not see my later comment.

By the way, the shell method should work on all modern shells. The only exception I've had is for /bin/sh on FreeBSD <= 8.2 and Solaris. But I think that's not big problem since z does not really target bare /bin/sh.

[denis-sokolov]

Thanks, rupa, I'll test this out on Monday and let you know.

[denis-sokolov]

Tested and confirmed.
Version on eliminate_notdir branch with -P option removed works perfectly on all machines I have been having an issue before. Thank you, rupa!

Do you plan to integrate it to the main branch or just keep it there as an independent version?
Also, do you have any decision about removing -P?

[rupa]

Yeah, I plan to merge the changes to master soon ... just gonna wait a bit in case anyone comes across any issues.

In, my informal polling, most people seem to want the current behavior (resolving symlinks), so I'll probably leave it that way, and probably make it configurable via an environment variable.

[rupa]

Ok, the eliminate_notdir branch (soon to be merged) will respect an environment variable $_Z_NO_RESOLVE_SYMLINKS if it is set before sourcing z.sh.

[rupa]

Also, @cllv thanks - I did see the changes you had suggested but didn't bother to use them until this reason came up. Note that your fork has some 'useless use of cat' in it that you may enjoy removing.

[denis-sokolov]

Thank you, rupa!

[clvv]

@rupa thanks for the heads up. I checked all the use of cat in my script and all of them seem necessary. Or maybe there is a better way to output heredocs without cat?

By the way, I have a question about j and z's mathcing algorithm. Is there a specific reason why the order of the arguments is ignored? I checked out autojump's matching algorithm yesterday. It seems that autojump's matching scheme fits more to the principle of least surprise. In z, and my fork fasd, two arguments can match a path in reverse order. Further more, a query can match a path even if it does not match anything in the last segment of the path, which is the most significant part of a path. It seems that autojump respects the order of the arguments and the last argument must match the last part of the path.

Say, we have two paths

/code/project/shell/whatever/main.sh
/code/project/python/test/main/whatever.py

and if we were to query with arguments whatever main, z and fasd's algorithm will not differentiate between the two paths well. Autojump, however, will only match the shell script. Same thing happens if we were to query with main whatever, z and fasd's will return the same result while autojump returns only the python file.

I've been playing around with a new implementation that's similar to autojump's approach. The code is in clvv/fasd@The code is in clvv/fasd@9649498 Also with a small tweak, it seems possible to implement fuzzy matching without too much performance cost.

I would like to hear your take on this.

[rupa]

@clvv, the heredocs are fine, there's one place where there's essentially echo $(cat <datafile>)| while read ... that is probably not worth optimizing but could use a redirect ...

Regarding the matching algorithm, I do think the idea of making order matter in arguments is worth looking into (it would probably simplify the matching code), but I don't like the idea of making the last part of the path special - in your example above, ordering matches would give the 'correct' result without any need to give any special importance to the last part of the path.

[rupa]

I've merged these changes into master, since the behavior is configurable I'm going to consider this closed.

[denis-sokolov]

Thank you!

[clvv]

@rupa
OK, I've worked out a new implementation with grep (clvv/fasd@9e62ed7). It also features a fuzzy matching that serves as a last matching resort.
I'm not going to argue which implementation is better. I'll let you decide on whether or not to change z's current behavior.

[rosshadden]

What are we supposed to set $_Z_NO_RESOLVE_SYMLINKS to?

I have tried _Z_NO_RESOLVE_SYMLINKS=true, _Z_NO_RESOLVE_SYMLINKS="-P", and _Z_NO_RESOLVE_SYMLINKS, to no avail. I realize this almost certainly comes down to my lack of knowledge, but I would appreciate a nudge in the right direction.

[rupa]

It can be set to anything 'truthy' so 1 or true or anything non-empty should work. It needs to be set before you source z.sh, as it is only evaluated once.

[rosshadden]

I am setting it to true before referencing z.sh. Maybe I am confused about what it should be doing.

I have a symlink in home called 'Dropbox'. With z.sh (using a blank ~/.z file to be sure) if I cd into ~/Dropbox, it actually adds the full path /media/windows/Users/ etc to the .z file. And sure enough when I execute z drop, it takes me to the full path, but what I would expect (and desire) is for it to take me to ~/Dropbox.

[rupa]

Hmm, that should work. Only thing I can think of is either you're using an older version of z or are on a system where bare pwd resolves symlinks. if you do echo $PROMPT_COMMAND do you still see pwd -P in it? With no resolve symplinks the -P should be gone.

[rosshadden]

I am using the latest version of z. Also, I receive a blank line when I output $PROMPT_COMMAND.

Thanks for helping me, by the way!

[rupa]

if $PROMPT_COMMAND is empty, I don't see how z can be working at all ... that's how it adds entries to the data file.

[rosshadden]

Weird... it works great. I am using zsh, if that makes a difference (but I don't see why it would).

[rupa]

Aha yeah, that would do it.

zsh uses a different mechanism - you had to add the precmd function manually, and thats where the pwd -P that you want to get rid of lives.

So just change pwd -P to pwd in that function, and don't worry about setting $_NO_RESOLVE_SYMLINKS.

[rosshadden]

Thanks so much! That did the trick.

[rupa]

Note that the lastest commit fixes my irritation with how you have to do this stuff manually for zsh, With it, you have to remove the precmd you manually put before, but z now respects the _Z_NO_RESOLVE_SYMLINKS variable.