5 ms·
Using aliases in `~/.bashrc` rather than putting scripts or symlinks in $PATH is a good mean to avoid those kind of problems, provided bashrc includes code to q
by oelmekki 9y ago
Using aliases in `~/.bashrc` rather than putting scripts or symlinks in $PATH is a good mean to avoid those kind of problems, provided bashrc includes code to quit if ran in non-interactive mode (default at least on ubuntu).
Many use aliases only to specify default command parameters, but it works just as well to provide an execution path, like, in this case:
alias df=/home/my_user/games/dwarf_fortress/df
It would only be executed in interactive sessions, this way, which should guard well enough against system code interpreting it.
Of course, this still means user can't use system's `df` easily, but I guess they don't use it anyway since they did not realize the problem until that upgrade.
- cpach 9y agoWhy not name the alias something else than “df”? :) dfortress or something like that. Then it won’t collide with df(1).
- oelmekki 9y agoThis is by far the best approach, yes :) My point was more to show a way this particular user could have achieved the same result without their problem. Plus, we can't expect users to know all the system tools, this is a good way to isolate "user space" from "system space", so I guess taking the habit to use aliases rather than putting things in `/usr/local/bin/` makes sense by itself (except when we want indeed to override an executable provided by system, or we want indeed to provide a new system tool).
- AndrewOMartin 9y agoThey could still type /bin/df, and they could also use: alias freespace=/bin/df Though then they'd have to uninstall FreeSpace 2.
- pwdisswordfish 9y ago> this still means user can't use system's `df` easily \df There you go.
- oelmekki 9y agoAwesome, didn't know about that. Thanks!