
Z.lua – A new cd command that navigates faster by learning your habits - skywind3000
https://github.com/skywind3000/z.lua
======
tniemi
Hopefully they have read the Jargon File:

[http://www.catb.org/jargon/html/D/DWIM.html](http://www.catb.org/jargon/html/D/DWIM.html)

> Warren Teitelman originally wrote DWIM to fix his typos and spelling errors,
> so it was somewhat idiosyncratic to his style, and would often make hash of
> anyone else's typos if they were stylistically different. Some victims of
> DWIM thus claimed that the acronym stood for 'Damn Warren’s Infernal
> Machine!'.

> In one notorious incident, Warren added a DWIM feature to the command
> interpreter used at Xerox PARC. One day another hacker there typed delete *
> $ to free up some disk space. (The editor there named backup files by
> appending $ to the original file name, so he was trying to delete any backup
> files left over from old editing sessions.) It happened that there weren't
> any editor backup files, so DWIM helpfully reported * $ not found, assuming
> you meant 'delete * '. It then started to delete all the files on the disk!
> The hacker managed to stop it with a Vulcan nerve pinch after only a half
> dozen or so files were lost.

> The disgruntled victim later said he had been sorely tempted to go to
> Warren's office, tie Warren down in his chair in front of his workstation,
> and then type delete * $ twice.

~~~
strainer
We don't need to be quite as paranoid about the plainness of a directory
navigation tool, as needed for a command interpreters path selector. It would
need to be combined with potentially destructive operations in a script to be
dangerous, so then on thy own head be it.

~~~
jerf
Such things have happened: [https://www.slashgear.com/steam-on-linux-bug-can-
delete-all-...](https://www.slashgear.com/steam-on-linux-bug-can-delete-all-
users-files-16364945/)

The problem is that shell is so sloppy it's hard to know what will happen. Of
course, that's not unique to a new mechanism for navigating directories. It's
scary stuff no matter what.

~~~
unhammer
That was an unbound variable, not due to a tool for predicting what
directories you typically navigate to. Who in their right mind would use that
in a shell script? (Actually, nevermind, if github had decent code search I'll
bet you could find rm -rf --no-preserve-root `fasd somefile` somewhere in
there.)

------
jplayer01
I use the version available for zsh (cdr) for folders that I very recently and
infrequently accessed, as well as z
([https://github.com/rupa/z](https://github.com/rupa/z) works with bash and
zsh). It seems like this z.lua and z are in some way related?

It feels far more intuitive and it's so incredibly convenient to be able to
jump between folders I'm working in without having to traverse an entire tree.
The shell used to feel so constraining for me, but tools like this are making
me enjoy it so much more.

------
sephoric
This is an excellent layer on top of bash and has some overlap with concepts
in other tools like fish shell, but it has me wondering, are we really at the
end of the evolution of shells, so that we're now focused on making tools that
improve shells? Or can we evolve the very concept of shells even further,
making zsh and fish look like assembly language in comparison to Haskell?

~~~
ariabuckles
We can definitely evolve shells more.

Most shells offer a convenient syntax around a lot of (fantastic) utilities
that often mirror C libraries (notably posix). When we were working in C,
having our shell mirror parts of that at times while being a very dynamic
language at other times sounds great.

But we have a much more varied landscape of language and library options now,
and many developers haven’t ever used C or posix.

So my thought is: what if we had a shell that was designed to interop with JS
(or python, or ideally a language the user knows well), instead of C/posix.
What if, instead of having to remember bash’s for loop syntax (or xargs), you
could just write .map() and iterate over lines/execute commands that way?

~~~
evanmoran
Totally agree with this. We need to create shells based popular languages so
language syntax stops being a barrier to entry for new people. How many times
do we search for "if statement bash" or "function bash" because the if and
function syntax isn't modern and isn't easy to remember?

Transforming the shell is a great opportunity for a new project, and as you
said should probably should be done in Python or JS. Lua is a good option as
well for its elegance, though it's a bit less popular than the others.

As for Z.lua, this is an interesting project and I really like seeing modern
languages enriching what we do every day on the command line. Very cool!

~~~
chubot
That's the motivation behind my Oil project:

 _Why Create a New Unix Shell?_
[http://www.oilshell.org/blog/2018/01/28.html](http://www.oilshell.org/blog/2018/01/28.html)

I took a very long route to doing it though, first implementing OSH (which
will run existing shell scripts, which is close to done, but slow) and then
Oil (a new language, not implemented).

This is because POSIX shell/bash has a really strong network effect. zsh and
fish are better in many respects, but people are locked into bash because
that's what "everybody else uses".

It's analogous to how C has a really strong network effect because e.g. every
kernel is written in C. So C++ became a popular language in a large part
because it's compatible with C. (Though the analogy breaks down because the
Oil _language_ isn't a superset of bash, so we can break free of legacy. The
_project_ is though.)

In my mind, I think of Oil as a mix between Python and shell, with some
elements of Ruby and JS (blocks, function literals, etc.)

~~~
ariabuckles
I love what you're doing with Oil! Looking forward to trying the interactive
version in the future :)

And yes, network effects are so important—your C++ example is spot on. One
recent example that comes to mind is the adoption from python2 to python3,
showing just how big a barrier those network effects are to adopting something
incompatible.

~~~
chubot
Thanks! I'm writing a blog post now about how I got the majority of bash-
completion running, so I'm now using OSH myself. This is the biggest milestone
in a long time!

It exposed the slowness issue though. I have a plan for that, but it's a bunch
of work.

It will help me if people try it and give feedback -- I'll give details in the
post.

I definitely agree about Python 2/3\. I think you basically can't overestimate
the amount of inertia a popular language has. I'm sure there will be patches
floating around for Python 2 for a long time after the core team stops
maintaining it next year.

Another example is all the compile-to-JS languages. I think TypeScript is the
most popular in part because its transition path is the easiest, i.e. it's a
superset of JS.

~~~
ariabuckles
That’s awesome! I’d love to try it; details in an upcoming blog post?

------
euank
This looks nice! I'm especially interested in the claims of performance.

I've also written an autojumper[0] (in rust) after being frustrated by
performance issues in other autojumpers, among other reasons.

For mine, I've gone to the effort to write a test and benchmark harness, and I
also ended up with about 10x faster than fasd/autojump[1].

I'm excited to benchmark pazi against z.lua, and if needed take some ideas to
be even faster :)

[0]: [https://github.com/euank/pazi](https://github.com/euank/pazi)

[1]:
[https://github.com/euank/pazi/blob/v0.2.0/docs/Benchmarks.md...](https://github.com/euank/pazi/blob/v0.2.0/docs/Benchmarks.md#benchmarks)

~~~
the_duke
How does it differ from [https://github.com/xen0n/autojump-
rs](https://github.com/xen0n/autojump-rs) ?

~~~
euank
Fair question! I didn't know a rust rewrite of autojump existed!

I already benchmark pazi against autojump by itself, so adding in a benchmark
against autojump-rs will basically be drop-in, and I do expect pazi will still
be faster, but I'll see.

At a glance, the differences I see are the following:

* pazi has extensive integration tests and benchmark code

* pazi doesn't fork processes into the background like autojump's shell scripts do (and therefore autojump-rs does), which avoids a few races

* pazi's interactive selection (z -i) makes use of the terminal's alternate buffer to avoid blowing away your scrollback, which most jumpers don't bother with.

* pazi has a cooler name in my opinion :)

These differences are not all that major. pazi is definitely short on some
features, and I don't blame you if you wish to use one of the others. I'll
keep working on pazi because I like using it and I'm having fun working on it
/ optimizing it / testing it.

------
LifeLiverTransp
Shells could be even more powerfull if recipes- aka workflows and
troubleshooting would be shared as if learned.

You want to install something troublesome, and the shell suggests a solution
command- or even several solution commands, mechanical turked away from other
linux users.

~~~
alanbernstein
Here is a step in that direction: [https://github.com/tldr-
pages/tldr](https://github.com/tldr-pages/tldr)

------
BlackLotus89
Since op is the github owner I guess this should be a Show HN? I'm not sure if
this is anything for me. I guess I would have to put in more effort
remembering if I accessed a directory before than to simply be able to use
this... But have to take a look how fast this thing really is and what it can
do and how it compares to ctrl+r and globbing

------
stabbles
I tried it and it seems indeed faster than autojumper on my Macbook Air with
bash. However, visually I don't see any difference, probably because other
tools run on cd'ing to the next folder (probably git).

Also when I do `z doc` I expect to go to `~/Documents` like in autojumper, but
in z.lua it jumps to a subfolder `~/Documents/projects`, which is annoying.
Finally it does not seem to cycle through all matches when I repeatedly do `z
proj` -- I like that about autojumper.

~~~
skywind3000
z.lua has multiple matching algorithms, the default one is simiar to z.sh, in
your case, you may look into the enhanced matching mode, by:

    
    
        eval "$(lua /path/to/z.lua --init bash enhanced once)"
    

FYI: [https://github.com/skywind3000/z.lua#enhanced-
matching](https://github.com/skywind3000/z.lua#enhanced-matching)

~~~
stabbles
Ah, great!

I can confirm z.lua feels really snappy compared to autojumper after disabling
the git related stuff! :) So now I should find a way to make the git prompt
faster.

------
usgroup
I like this in principal. I’m pretty damn predictable at the command line and
far too lazy to make shortcuts.

~~~
gnulinux
Same. I do make some aliases like status instead of git status but use them
like 10% of the time. I mean I already know all the commands I need for my
work, it seems like memorizing their short forms is the same amount of mental
load. Also completions exist.

------
emerongi
zsh has named directories:

    
    
      somedir=~/Development/subdir1/subdir2
      cd ~somedir

