Godot: Change Linux export extension to reflect architecture

[insomniacUNDERSCORElemon]

Currently, with Godot 3.X the Linux export defaults to .bin as the extension. I have seen this for many files (emulator ROMs/BIOS, install packages, and generally files the user is never supposed to see that programs use in different ways), however I've never seen them used for Linux executables... so I'm not really sure why this was chosen. Also, for some reason .bin defaults to VLC, I'm guessing because .bin is also used for some obscure video format.

I have seen many Linux executables with no extension (or, due to including a software version in the name, a number extension that luckily my system ignores), including Godot 2.X games (because that was the old default). And honestly this is better than .bin.

However the best is using the extensions .x86 or .x86_64 (for 32-bit or 64-bit respectively) so 32-bit users can easily see that an executable is incompatible with their system, and so 64-bit can know that they won't be getting full memory support.

[reduz]

That's kinda up to you to name it that way, not sure if there is any reason
to force it

On Sat, Dec 9, 2017 at 5:15 PM, insomniac_lemon [e-mail]
wrote:

Currently, with Godot 3.X the Linux export defaults to .bin as the
extension. I have seen this for many files (emulator ROMs/BIOS, install
packages, and generally files the user is never supposed to see that
programs use in different ways), however I've never seen them used for
Linux executables... so I'm not really sure why this was chosen. Also, for
some reason .bin defaults to VLC, I'm guessing because .bin is also used
for some obscure video format.

I have seen many Linux executables with no extension (or, due to including
a software version in the name, a number extension that luckily my system
ignores), including Godot 2.X games (because that was the old default). And
honestly this is better than .bin.

However the best is using the extensions .x86 or .x86_64 (for 32-bit or
64-bit respectively) so 32-bit users can easily see that an executable is
incompatible with their system, and so 64-bit can know that they won't be
getting full memory support.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/14470, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2z5MPcEbhZ_EU5alcnFMgTTIgu1Rks5s-upKgaJpZM4Q8O3q
.

[insomniacUNDERSCORElemon]

I just don't get the reasoning behind .bin. As I've said, never seen that with a Linux executable (though plenty of other things to muck up file association rather than properly executing), so it makes more sense to go with a common and descriptive extension.

Even if you don't want to do this for some odd reason, using no extension is better.

[leoddd]

.bin is for binary by the way, which can be a whole slew of things and is sort of an incredibly generic name, which is why you see it everywhere.

I have .bin files associated with a specific program as well because it's the extension that dumped SNES games use for their graphic files, but really, you just have to rename it if you don't want this.

[insomniacUNDERSCORElemon]

@leoddd I did mention that in the opening post, and I personally think it's bad to use a common extension like this when there's absolutely no reason to and when it goes against common practice.

Something that requires the user to run via terminal or rename the executable shouldn't be default.

[NathanWarden]

I agree with @insomniacUNDERSCORElemon, it would be nice to default to something that reflects the architecture. More importantly, if I remember correctly, the .bin extension seems to cause the executable to not actually execute even though it's marked as executable (default MIME settings?). So, at the very least on Linux I would suggest to drop the .bin extension.

[akien-mga]

I'm not sure how set .bin as default extension, but indeed it makes no sense for Linux. No extension would be better (as it was in 2.x). Or yeah, an arch suffix could be fine too.

[Web-eWorks]

The relevant code is here. Consider me on the side of optional or x86/x86_64 extensions.

[eon-s]

@NathanWarden the extension is not the one who affects the executable mode but the compiler settings creating shared objects by default on most distributions.

[NathanWarden]

@eon-s Ah thanks, good to know. I completely forgot the error that popped up and yep, it was something like, "No program found for opening a shared object" or something like that.

I believe this is the default setup on Ubuntu and other mainstream distros, so I'm sure many other users who don't know about this, and change the setting, will also run into this error :)

[NathanWarden]

Is anybody working on this yet? If nobody is on it yet and nobody wants it in the meantime I can probably find some time tomorrow. :)

[insomniacUNDERSCORElemon]

@eon-s @NathanWarden I have mentioned it before, but .bin files aren't runnable on my system (without running from terminal or removing the extension) but it has nothing to do with the compiler AFAIK.

Actually I think that because I'm using NTFS for my 'storage' drive, that means that ALL files are marked executable (by default it's either on or off, you need to set up NTFS to handle Linux permissions, which I have not bothered to do). So my issue is purely with .bin, which as I've said my system defaults to trying to run using VLC (yes, even if I try to reset the file association).