|
Description
Detect the needed runtime for an executable automatically. Ask if the user wants to install this runtime.
For example I want to execute a shell script, a Windows executable, a CLI executable, a python executable, etc.
http://people.freedesktop.org/~hughsient/temp/gpk-install-mime-type.png (OK, PDF is no executable, but when you replace the mime type, this is what I mean)
Tags:
(none)
Attachments
No attachments.
Duplicates
Comments
|
Auzy wrote on the 19 Jun 08 at 15:06
|
Actually, I think the main problem is that Gnome doesn't support associations by extensions. That would be the easiest way of implementing this idea, and would fix other problems too.
Developers often forget to add the #!/blah statement, which is what I believe the current execution mechanism relies on. The problem is, that other operating systems don't look for that, instead using the file extension, so developers dont always add them (I personally never do even in linux, I keep forgetting). And we can still use both to make the best assessment of the file type.
So +1. The same mechanisms to fix this also fix serious shortcomings in gnome/ubuntu that prevent my MenuToGo program from functioning correctly.
|
|
natureflow wrote on the 19 Jun 08 at 16:13
|
> Actually, I think the main problem is that Gnome doesn't
> support associations by extensions. That would be the
> easiest way of implementing this idea, and would fix other
> problems too.
No. There's already association by extension support. But this is not the easiest way implementing this idea.
> Developers often forget to add the #!/blah statement, which
> is what I believe the current execution mechanism relies
> on. The problem is, that other operating systems don't look
> for that, instead using the file extension, so developers
> dont always add them (I personally never do even in linux,
> I keep forgetting). And we can still use both to make the
> best assessment of the file type.
I can run a windows or a cli executable file by simply typing their file name in the terminal. It seems you do not need this #!/blah statement.
|
|
vexorian wrote on the 19 Jun 08 at 22:49
|
Auzy: It is those developers' fault then.
Linux works by adding #! , not by extensions, making it depend on extensions will bastardize Linux by making it more windows like, please don't.
|
|
Auzy wrote on the 20 Jun 08 at 01:54
|
> No. There's already association by extension support. But
> this is not the easiest way implementing this idea.
It probably does, but its not exposed on the interface.
In terms of everything else, It appears you guys HAVE been mislead to the actual behavior that happens. Allow me to explain, and please read. I want every programmer AND every non-coder to understand this, because it affects everybody. And it seems many coders have got their head up their asses too far, because it is so obvious. Yet, it is a major problem. One which many people here ignore, because it uses a mechanism that microsoft users in specific cases (which people dont feel is cool).
In terms of windows and binary files. Since they are binary files, they are structured in a way that is easy to identify. If you type "file XXX.exe", it will pick it up as a MS-DOS executable. Easy. thats totally irrelevent and pointless, and easy to deal with. We already are!
What do perl, bash, README files, and other scripting languages all have in common though? They are all plaintext files!
I want everyone (ESPECIALLY VEX and Nature), to do this experiment.
1) Start a text file, name it xxx.pl
2) Place the following in it: print "Hello World"
3) Try to run it in gnome
This file will run, as is, on OSX and Windows fine. Try to run it from gnome though, and it will open as a text file. Why? Because the system only knows its a ASCII text file. We hack around it using a chmod +x. Gnome will then also offer to let you execute it. But, it will assume its a bash file. So now you must add the #! statement, which no other OS requires.
And whats wrong with the #!/PATH statements? #!/usr/bin/perl might be ok on one linux distro, but another may use #!/bin/perl. So its behavior isn't even consistant! In fact, its not linux-friendly because many different distro's have perl in a different place, so the switch wont work consistantly.
The execute bit doesn't make it any more secure, because it can still be run anyway with perl xxx.pl. All it does is hint to gnome (in the lamest possible way), that it should try to run it with bash by default, or if there is a #! statement, try that and fail if it was coded on a distro where perl is in a different location.
Because all scripts are Text files, there is no way to properly detect script files except by extension. Do you guys believe me now? Or should I spell out the problem with lego blocks?
And its an ubuntu problem I believe.. I think KDE4 does it properly. And most distro's would too. It wont inconvenience anyone either by doing it properly because
We should all start making noise about this, or it will NEVER get fixed. And if properly fixed, we wont have to manually set a +x bit on scripts to run them
|
|
Auzy wrote on the 20 Jun 08 at 01:56
|
PS, no way its the developers fault. It works perfectly on Windows and OSX. And probably many other distro's too (and I think KDE4).
And, the #! statement relies on perl remaining in a consistant place. Not all distro's have perl in /usr/bin/perl for instance, some may have it in /usr/lib/perl5/bin, it doesn't even work consistantly.
|
|
Warbo wrote on the 20 Jun 08 at 05:34
|
Auzy: As far as the inconsistent placement of interpreters, you should be using /usr/bin/env. For example:
#!/usr/bin/env python
That will ask the /usr/bin/env program (which is always in the same location, if it's not then it's a bug) where an interpreter for "python" is. This is nice as it doesn't depend on the path, doesn't depend on the version or even on the interpreter (a user can have CPython, Jython, IronPython and PyPy all installed at once and change defaults based on a preference rather than redirecting symbolic links).
BTW, the "structured in a way that is easy to identify" part is first and foremost based on the header/magic number (usually the first 2 bytes) of a file where certain filetypes have certain bytes (differentiating further, like the difference between an MPEG containing video and audio streams and an MPEG containing just an audio stream is done via more complex pattern matching), files without headers (ie. chunks of binary) are called "raw", which may be possible to identify via pattern matching depending on the data.
(See http://en.wikipedia.org/wiki/File_format#Magic_number )
Whereas changing a file extension can be done by anyone at any time without consequence to the file (the OS may break by not handling it correctly, but the file is fine), changing the header is literally corrupting the file and having it not execute anymore is the least of your problems, since the file itself needs fixing.
(See http://en.wikipedia.org/wiki/Shebang_(Unix) )
The "#!" is just the header (first 2 bytes) for "interpreted script", so not having it there for an interpreted script can either be seen as having a corrupted file, which would need fixing by adding the #! line, or it could be seen as handling raw data. Raw data handling, by its very essence, involves the user manually opening the data with an appropriate program since all raw data is interchangable (eg. in a music tracking program which handles raw samples, there is nothing stopping a raw image file from being used as a sample, although it will sound like static). In fact, ANY file at all can be opened by any raw-capable application, since all files can be represented as a binary dump. The only way to tell the type of data in a raw, headerless file is by either pattern matching (which wouldn't work in your 'print "Hello World"' example as you've noticed) or by explicity being told by the user what kind of format the data is in (Raw is essentially a huge bitmask) See http://en.wikipedia.org/wiki/File_format#Raw_memory_dumps.2Funstructured_format s
This brings us on to the idea at hand. Basically, the only way to automatically run an interpreted program without a shebang in the correct interpreter is through potentially unreliable pattern matching, so the correct solution is to give all interpreted programs a shebang header pointing to /usr/bin/env.
BTW, "chmod +x" isn't really a hack, since it isn't designed to get plain text to execute. It is designed to get ANYTHING to execute, so it's really an artifact of the permission and security model Ubutu uses rather than anything else.
|
|
Auzy wrote on the 20 Jun 08 at 06:51
|
Ok, looks like its time for me to stop brown nosing around and cut through the BS.
Summary of Why I'm right, and your Wrong:
=========================================
1) /usr/bin/env is a hardcoded location still. Hardcoding is lame!
2) Cant use something like #!$XDG_USRBIN_DIR/env (Maybe there are env vars, but I couldn't work them)
3) Cant rearrange filesystem structure safely. Gotta still have usr and bin's lying around. Lame!
3) Scripts which work anywhere else out of the box need to be fuxed with to work on linux.
4)Nobody goes around f0cking file extensions. And even if they did, they could still run it using your method. It just makes it easier.
5) You need the execute bit set so Gnome will try to execute it still.
6) You cant just download scripts/programs from somewhere and run them easily. You need to +x
7) Your statements PRETEND, that my way cant work with yours. That is bullshit.
8) Scripts from other platforms need file editing to run from the gui at all in linux.
9) Your regex crap is irrelevant. File associations don't need that.
10) Your method requires 3 steps for files which should be 1 click
Seriously, I'm not asking you to bend down in front of Microsoft and break what works already. All I am asking for is to set up some simple file associations such as
.pl -> /usr/bin/perl
.sh -> /bin/sh
.py -> /usr/bin/python
Then:
1) I dont need to edit scripts coded in other OS's to run them in the linux GUI. Just ensure they are .pl
2) I don't need to set execute bits.
3) I dont need to edit EVERY script just so it works on linux. Dumbest fix i have heard all day.
4) And your proprietary unix/linux method for running scripts works just as fine. Just we dont have perl files keep opening as text files.
Are you guys that arrogant that you cant see where the system totally fails? Or do you not care anymore that it takes 3 actions to run 1 script (scripts are meant to be easy and quick)?
I thought Linux was about freedom. I thought Ubuntu was about Linux for Humans! Instead I need to write essay's to explain why Scripts work like arse. Do you guys even want Linux to be usable?
|
Post your comment
|
