322

When I run apt-get upgrade on my Ubuntu 17.04 machine, sometimes it starts Dwarf Fortress by itself.

It has happened already at least two times, so it was probably not just some sort of one time thing. Also, the execution ofapt-get upgrade seemed to be paused until I manually quit the Dwarf Fortress, so it most probably wasn't caused by something else running in that time.

The console at that time said Unpacking xxx. where xxx was something with mysql in name. I don't however know which package exactly, as today, apt-get upgrade upgraded a lot of mysql related packages.

I would like to know what happens and how to stop it from happening. Thanks for your ideas.

550
+500

With a question as weird as this, it's of course impossible to say for sure -- but I'll eat my hat if my first hunch isn't correct. :)

The only way I can think of, how such unrelated things could be linked is this: After installing (well, extracting) Dwarf Fortress, instead of going to the directory every time and running it with ./df, you wanted to be able to run it from anywhere, like any old command. You added the Dwarf Fortress directory to your $PATH, before the system directories, perhaps by chance, perhaps because you noticed it didn't work otherwise, and you'd instead just get information about your filesystems.

Dwarf Fortress's executable is named df, which is also the name of a system tool for displaying disk space usage of your filesystems, creating a collision. By making it so that when you type df, Dwarf Fortress starts, you've shadowed the system tool, so when a script wants to - let's say - check if you have enough free space for unpacking an archive, instead of invoking df - the system tool - it'll start Dwarf Fortress instead. And after you quit Dwarf Fortress, the poor little script will be very confused as to why it wasn't given the disk usage information it asked for.

Anyway, thanks for the laugh, this has to be among the funniest problems I've ever seen voiced on StackExchange. :)

| improve this answer | |
63

My hunch is similar to Aleksi's, but I suspect you might have moved the Dwarf Fortress binary to /usr/local/bin or /usr/bin (and hopefully not /bin).

Try running sudo which df in your terminal. If it doesn't say /bin/df, try moving the file specified in the which output to /usr/games/ (you'll be able to run the game in the future by running /usr/games/df). Apt should work again after that.

======

Otherwise, in the scenario where sudo which df says /bin/df, try running /bin/df. If that has been overwritten with the game, you'll need to move the game binary as mentioned above, and sudo apt-get install --reinstall coreutils.

If that fails because df is missing, you may need to resort to more drastic measures (like either creating a fake script to replace df temporarily, or manually downloading the package and extracting the df binary from it).

| improve this answer | |
  • 7
    It is ironic that a comment by the questioner to the accepted answer confirms that this is what the questioner did, with a symbolic link, rather than modifying PATH as in that answer. – JdeBP Aug 16 '17 at 11:42
  • 1
    @JdeBP: Not really, the main point is the naming conflict - I think how that was achieved is secondary, even if I say so myself. I also mentioned this in the comments of the other answer, in response to a comment that suggested the same thing as this answer, but I did originally consider mentioning this as another possibility, until I realized that moving/copying the binary (as opposed to symlinking, which I didn't think about) wouldn't have worked due to the way Dwarf Fortress works. (Ie. it's just extracted, not installed - it wouldn't find its own data files when not in the same directory) – Aleksi Torhamo Aug 16 '17 at 13:38
  • 2
    A better command might be sudo which -a df to see all df commands found in the path. – Doug Henderson Aug 16 '17 at 15:09
  • Wait it's 2017 and we use apt-get yet? – EKons Aug 18 '17 at 9:37
  • @AleksiTorhamo Just to clarify, the PATH variable that apt would see is overridden by the sudo command (/etc/sudoers has a secure_path variable to prevent security issues with users modifying their PATH). I agree that realizing that the Dwarf Fortress binary is taking precedence in the PATH resolution is the key insight though. – maccam94 Jan 18 '18 at 2:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.