Partially fix z -x command

[DannyNemer]

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).

[bean5]

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

[DannyNemer]

@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]

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

[DannyNemer]

@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]

*no rebase or merge necessary into the request branch.

[ahamid]

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]

• 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]

@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!