Just always use /bin/bash and don’t care about distros/BSDs that don’t care enough about their users to place bash there. Problem solved for 99% of users. ;)
or you know, ignore developers that don’t care about their downstream packagers and users to learn about /usr/bin/env? Problem solved for 99% of users caring about cross platform software.
Not all distros may have env in /usr/bin, so not necessarily an improvement over the extremely common /bin/bash. Then there’s the problem of what /usr/bin/env df might return…
IME, globally /usr/bin/env is more likely to exist than /bin/bash. The person who has this dwarf fortress issue seems to have done foolish things to get df to be dwarf fortress so I don’t think this situation is a valid motivator for something that is closer to being a standard (/usr/bin/env) than something that’s not (/bin/bash).
As long as neither /bin/bash nor /usr/bin/env are standards, there can be issues. In addition to this, there is no agreed upon registry for reservation of the names of the executables.
Keep in mind, for this to happen, the user probably changed the system default PATH to put Dwarf Fortress first. sudo usually scrubs the environment to default settings unless you’ve taken steps.
The original df is in /bin. He placed another df to /usr/local/bin. The default PATH on Ubuntu has /usr/local/bin before /bin, so his df gots executed instead of the system one.
Why would they use df? Did they not know of the other df? Or did they just not care? I don’t care if someone else set the PATH variable and it isn’t your fault, at best it is confusing, at worst someone messes up an install/copy/backup script, with potential to hose their system.
Not all the world is Unix. I can’t confirm with cursory searches, but given the character set choice (CP437) I strongly suspect that Windows was the original platform.
The ANSI C standard, at least the 1989 version, had
#pragmainvoke implementation-defined behavior.Early versions of GCC would, upon seeing an unknown
#pragmain a source file, launch Nethack.It was inevitable.
If only it made him complete a quest with a random character in adventure mode before continuing to update his system. :D
This is one good reason why I always use full, explicit paths in my scripts.
but then they are not portable
Just always use /bin/bash and don’t care about distros/BSDs that don’t care enough about their users to place bash there. Problem solved for 99% of users. ;)
or you know, ignore developers that don’t care about their downstream packagers and users to learn about /usr/bin/env? Problem solved for 99% of users caring about cross platform software.
Not all distros may have env in /usr/bin, so not necessarily an improvement over the extremely common /bin/bash. Then there’s the problem of what
/usr/bin/env dfmight return…On NixOS, env is the only thing in /usr/bin, so that’s at least one distro that developers can avoid breaking by using it.
IME, globally
/usr/bin/envis more likely to exist than/bin/bash. The person who has this dwarf fortress issue seems to have done foolish things to get df to be dwarf fortress so I don’t think this situation is a valid motivator for something that is closer to being a standard (/usr/bin/env) than something that’s not (/bin/bash).As long as neither /bin/bash nor /usr/bin/env are standards, there can be issues. In addition to this, there is no agreed upon registry for reservation of the names of the executables.
Keep in mind, for this to happen, the user probably changed the system default PATH to put Dwarf Fortress first. sudo usually scrubs the environment to default settings unless you’ve taken steps.
Read the comments on the answer. He dropped a symlink into
/usr/local/binto make the command available to him./usr/local/bin/df?I don’t get this. Did he override the linux df in /usr/local/bin?
The original
dfis in/bin. He placed anotherdfto/usr/local/bin. The default PATH on Ubuntu has/usr/local/binbefore/bin, so hisdfgots executed instead of the system one.Why would they use df? Did they not know of the other df? Or did they just not care? I don’t care if someone else set the PATH variable and it isn’t your fault, at best it is confusing, at worst someone messes up an install/copy/backup script, with potential to hose their system.
Not all the world is Unix. I can’t confirm with cursory searches, but given the character set choice (CP437) I strongly suspect that Windows was the original platform.
It was
I do love how this is weird bollocks causing Dwarf Fortress to run, instead of the usual way round.
The game wants to be played!