Previously, `cheat` would exit if run by `root`. The rationale was:
If `cheat` was run by an unprivileged user (`chris`, for example), the
`$DEFAULT_CHEAT_DIR` would default to `/home/chris/.cheat`. If cheat was
run via `sudo`, however, the `$DEFAULT_CHEAT_DIR` would suddenly be
`/root/.cheat`.
Presuming that those individual user cheat dirs actually contained cheat
sheets, this could cause confusion, because cheat sheets accessible to
one user (`chris`) would not be accessible to the other (`root`). Thus,
cheatsheets would appear and disappear, depending on which user was
running `cheat`. (This would only be an issue, of course, for cheat
sheets that existed within the respective users' cheat dirs. System-wide
cheat sheets would be unaffected.)
`cheat` was thus programmed to gracefully fail when run as `root` to
prevent that possible confusion.
However, I'm backing away from that reasoning, because:
1. It's causing a headache for real users who'd like to run `cheat` as
root
2. Other venerable programs (`vim`, etc.) suffer from the same problem,
but nobody seems to mind enough to do anything about it. Thus, I suppose
the laissez-faire approach is essentially the sanctioned "solution" to
this problem.
3. Users sufficently troubled by this confusion may rememdy the problem
manually by setting environment variables (`$DEFAULT_CHEAT_DIR`, etc.)
Thus, `cheat` no longer complains if run by `root`.
Version-bumped to 2.1.0.
The `setup.py` script no longer attempts to install files to privileged
system directories. (Previously, it attempted to do this in order to
enable command-line autocompletion.) In lieu of doing this within the
installer directly, I have simply included brief instructions explaining
how to configure this manually.
Version bumped accordingly.
Previously, `sheets.print()` would query the filesystem every time it
was invoked. This was inelegant, because it is called multiple times
every time `cheat` is executed. Thus, unnecessary calls were being made
out to the filesystem.
Now the result of that function is being buffered into a module variable
when it is executed the first time, and served from there thereafter. I
broke the "functional" paradigm to a degree by doing this, but it wasn't
worth the complexity of implementing proper memoization (decorators,
etc) for such a trivial case.
Bumped the version number accordingly.
