Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Partially fix z -x command #159

Closed
wants to merge 1 commit into from
Closed

Partially fix z -x command #159

wants to merge 1 commit into from

Conversation

DannyNemer
Copy link

The command z -x still does not work, despite the change in #125.

Previously, the command sed -i -e was used (incorrectly) and made a backup file named ~/.ze. Using sed -i '' prevents this backup file from being created (on OS X).

Previously, after running z -x, the datafile would be printed as if z failed to find results for a query. But, because z -x would never be used with arguments (i.e., a query), it is best to return like the z -h command.

Despite my attempt at a fix, z -x still does not work because of precmd, which adds the current directory to the datafile after every z run regardless of the arguments. z -x correctly modifies the datafile, but after, z adds the current directory right back (with a reset score).

Previously, on OS X, the command `sed -i -e` was used incorrectly and made a backup file named ".ze". Using `sed -i ''` prevents this backup file from being created (on OS X).

Previously, after running `z -x`, the datafile would be printed as if `z` failed to find results for a query. But, because `z -x` would never be used with args (i.e., a query), it is best to `return` like the `-h` command.

However, the `z -x` still does not work because of `precmd`, which adds the current directory to the datafile after every `z` run regardless of the arguments. `z -x` correctly modifies the datafile, but after, `z` add the current directory back.
@DannyNemer DannyNemer changed the title Partially fix '-x' command Partially fix z -x command Aug 27, 2015
@bean5
Copy link

bean5 commented Oct 20, 2015

Can this be closed? This PR says that the branch is up-to-date with the base branch.

@DannyNemer
Copy link
Author

@bean5 No. That message does not mean the PR has been merged; rather, it means there have not been any changes to the base branch that conflict with this PR.

@bean5
Copy link

bean5 commented Oct 20, 2015

I see. So no rebase or merge necessary. Good to know. Thanks.

@DannyNemer
Copy link
Author

@bean5 Not quite. This PR's changes have not been integrated and still need to be merged to take effect. The message means there will be no merge conflicts when the PR is merged. There will be changes, just not merge conflicts.

@bean5
Copy link

bean5 commented Oct 20, 2015

*no rebase or merge necessary into the request branch.

@DannyNemer DannyNemer closed this Nov 23, 2016
@ahamid
Copy link

ahamid commented Jul 24, 2017

For me it was the Bash PROMPT_COMMAND that was breaking this. Setting _Z_NO_PROMPT_COMMAND fixes the removal, but apparently this is the way z is collecting/adding entries, so z stops doing that automatically. Perhaps -x could take an argument?

@rupa
Copy link
Owner

rupa commented Jul 25, 2017

  • yeah this usage of sed isn't portable and I'll have to come up with something else. this proposal kinda works on lunix but throws an error
  • in terms of the directory getting added again, it's what i'd expect and I'm not inclined to go through hoops to prevent it. you are in that directory. It does lower the ranking.

This feature is tacked on to begin with, the point of z is to be useful without configuring it, using it is more of a conversation than an ordering it about (if it doesn't do what you expect you might do well to phrase the question differently).

maybe some more arguments about why it's important to have this feature that can't be solved some more cromulent way would help

@ahamid
Copy link

ahamid commented Jul 25, 2017

@rupa My problem was that I have a directory which I z to very frequently, many times daily. I don't think I cd to it at this point any longer. Then one day, for one specific case, I cd to /a/very/annoyingly/long/path/somewhere/i/will/never/go/again/in/my/life/but/shares/a/single/word, and now my convenient z shortcut is broken and as far as I can tell there is nothing I could do to get it back. I tried the obvious first thing of changing to the common directly several times to bump it in the ranking, but I could never get rid of the annoying dir :( z -x didn't seem to lower its ranking enough that my common dir was ever used. Solution? (I think my pr #207 is reasonably straightforward, although I suppose I could just hand-edit the .z db file at that point) Should simply cding to the common dir be bumping its ranking? Maybe it's a casing issue (annoying path substring matches case, desired target matches path component but not case)? If so then something is broken. I guess i'll test again. I can try to reproduce and post the frecency scores/z db if you'd like.

Oh, I suppose I should moderate this minor complaint with my thanks - z is great and has saved me a ton of typing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants