mirror of
https://github.com/cheat/cheat.git
synced 2025-01-19 01:49:30 +01:00
e391cf2f01
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. |
||
|---|---|---|
| .. | ||
| autocompletion | ||
| cheatsheets | ||
| test | ||
| __init__.py | ||
| sheet.py | ||
| sheets.py | ||
| utils.py | ||