The datatypes would be flagged as executable, obviously.
My suggestions are aimed squarely at making the system less "stupid" and "just work" for the average user out there, not the typical power users that inhabit these boards.
If we ever want to grow a userbase the operating system has to be improved to deal with some of its quirks. In my opinion, needing to set a special executable bit (or even more "special" executable bits suggested above) which often get messed up by archivers and other tools is a bad design.
What about a system like DOpus Magellan's filetypes? I liked that very much. You could have files identified by extension or content. In the case of scripts, perl and python scripts have this at the beginning to identify them #!/usr/bin/perl #!/usr/bin/python so use that to associate the script to perl, python or arexx and run it in shell when double-clicked.
That could be extended to shell usega I think. If the S bit is set, then the shebang will cause the script to run in the proper interpreter, right? If not set, the filetype system should detect the type and run it using the associated deficon and tool.
And it could be also nice if then, automatically, sets the S bit for the script and/or creates an icon for it (for the tool and to run in shell).
You need either a #! or similar header OR the script/execute bits, or there'll be no safe way for the system to separate a script from just any text file (datatypes can't help you there). Relying on #! of course would break practically every AmigaOS script in existence, but requiring either #! or script/execute ought to be safe enough.
I'm not sure where I'd stand on not requiring it to be set executable - but I agree a separate script bit isn't really necessary.
If a script is missing the execute bit, the determination of its executable status would come from datatypes looking at: - the file extension (i.e. .rx, .rexx, .py, .r) - a magic file first-line header (such as the /* COMMENT */ tag used by Arexx)
If a script file does not have a matching file extension or first-line header then it will not be considered a script.
To recap, I am not advocating for the removal of the execute bit. What I am advocating for is not relying on this bit for every script and binary ever loaded onto a user's machine.
Even if you do set an executable bit for a script the interpreter must still be determined. Back to datatypes again, anyway. As a bonus deficons could work for scripts in workbench.
And apologies if I am throwing this thread off-topic, but this issue has struck a nerve.
You could have files identified by extension or content. In the case of scripts, perl and python scripts have this at the beginning to identify them #!/usr/bin/perl #!/usr/bin/python
How have not you guys ever noticed that already works in AmigaOS. (Or did I spoil the fun telling this and not let the guys find it themselves.) And btw we have DefIcons.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
But can DefIcons determine the file type by its content (as filetypes in DOpus Magellan)? I don't have a working AOS4.x machine now and don't remember that bit, but I do remember using filetypes by content extensively with Magellan.
So you can specify to search for a specific string (as you see in a hex editor) for a type of file to associate it with an icon and tool, using DefIcons in 3.x, without using datatypes?
Sorry, I missed that, I was spoiled by DOpus
If that is the case, then I don't see the problem. Predefined Filetypes (for DefIcons) with OS4 and anyone can define new ones as needed.
The datatypes would be flagged as executable, obviously.
But you wrote that this was not enough, that the datatype system was to determine _how_ to execute the files. Well, they will not be capable of doing that anyways when they're not loaded.
Quote:
My suggestions are aimed squarely at making the system less "stupid" and "just work" for the average user out there, not the typical power users that inhabit these boards.
If people cannot fathom the simplest concepts of the OS, then why on earth are they bothering with it in the first place? Why do we always have to use the non-existing feeble minded "most users" as the measure for usability? I find it highly annoying.
Quote:
If we ever want to grow a userbase the operating system has to be improved to deal with some of its quirks.
So you want to attract ignorants who have no real interest in learning the OS just to grow the user base, and in the process alienate actual long time existing users by messing up everything. What was the point again?
$> type ram:test echo myscript ram:test2 echo $RC quit 2
$> type ram:test2 echo test2 quit 7
$> ram:test myscript test2 7 $> echo $RC 2
This looks just like what was originally asked for, right?
As mentioned, Amiga "Execute" has supported hashbanging (#! /) for more than a decade already. It was added in either OS3.5 or 3.9, and existed long before that as various patches.
Basically, AmigaDOS loops based on the "SKIP BACK" command will not work if the loop contains a call to another script (sub-script).
I have to say that I never noticed this, so I am not sure if it is true anymore.
Quote:
Another side affect of the above info is that setting the "FAILAT" level in a sub-script will alter the failure level (FAILAT) of the calling script.
On the other hand, I know this is correct. Can be a bit annoying.
Quote:
Based of the above information and other weaknesses of AmigaDOS scripting you might be better off converting your MS-DOS scripts into ARexx or Python scripts.
If I was doing anything complex, I would do it in PortablE... (Plus I already learned the hard way that ARexx is totally unsuited to non-tiny programs..)
The datatypes would be flagged as executable, obviously.
But you wrote that this was not enough, that the datatype system was to determine _how_ to execute the files. Well, they will not be capable of doing that anyways when they're not loaded.
[/quote] The suggestions are for situations where there is no execute or script bit set. The file is an 'unknown'. If the datatype is flagged as an executable then there is nothing left to decide.
*Perhaps* in the future the system *could* be made smarter to recognize an executable and run it without the need for the "execute" bit.
What triggered my initial comments was the thought of adding more attribute bits to the file that tag it with the script flavour, be it classic script, or some new script engine. That is entirely the wrong direction IMO. This is where the data types could be used to determine if the file is a script and which interpreter is required.
Quote:
Quote:
My suggestions are aimed squarely at making the system less "stupid" and "just work" for the average user out there, not the typical power users that inhabit these boards.
If people cannot fathom the simplest concepts of the OS, then why on earth are they bothering with it in the first place? Why do we always have to use the non-existing feeble minded "most users" as the measure for usability? I find it highly annoying.
New users would find it equally annoying to deal with elitist attitutes.
Quote:
Quote:
If we ever want to grow a userbase the operating system has to be improved to deal with some of its quirks.
So you want to attract ignorants who have no real interest in learning the OS just to grow the user base, and in the process alienate actual long time existing users by messing up everything. What was the point again?
"Ignorants" are first time users. You were one at one point. People don't buy a computer for the O/S, they buy it for what it can do for them. As much as possible the O/S should get out of the way and just do the right thing.
I believe that power users would find a system smart enough to recognize new types of scripts via the data type system to be quite smart and not a detraction as you posit. You may even find it useful for other reasons.
In the big scheme of things this isn't a huge issue, but if the system can be made "smarter" then why not at least entertain the idea?
@gregthecanuck FWIW, I think your idea is the right one. Certainly adding MORE flags/bits is totally the wrong direction, and in fact I'd like to see some of the special ones got rid of if possible. e.g. Get rid of P (not really useful these days & no-one uses it), and get rid of H (never seen this used, but it was often misused as a Hide flag). Would definitely be nice if we could get rid of S too.
Flags just cause problems, especially when backing-up & restoring programs or the OS partition using a non-Amiga filingsystem. I've also seen the situation where OS4 refuses to run an executable that was built on a non-Amiga system, because it was missing the E bit. Similar problems for the S bit in archives build on foreign systems.
Although I'd love to see the H flag officially repurposed as a Hide flag, since this was quite handy on OS3 with Directory Opus 5.
On Windows, there is no execute bit you need to set.
We all know that's a poor system. People invent extensions without checking to see which ones are already used. Extensions have different meanings on different OS's etc. etc. Quote:
In other words, executable bits could flag as file as: - executable - not executable - unknown (fall back to datatypes)
Datatypes are not magic. Datatypes would still have to look at the contents to differentiate script types ( Conmments using /*comment */ for ARexx & ;comment for AmigaDOS & #comment for Python. Datatypes would be examing the file for the same identification that Execute already looks for when determining if a file is ARexx or AmigaDOS. It would just add another layer of functions to do the job. Protection bits would be direct and fast. In fact, such a system would make Datatypes quicker at identifying executables and scripts. There would be no need to open the file and look at the comments to see what type of script it is. Datatypes would only need to check the protection bits. The current system of looking at the comments at the top is crude and easily confused by the fact that C source also has "/*comment*/ " comments like ARexx and makefiles have "#comment" comments like Python.
FWIW, I think your idea is the right one. Certainly adding MORE flags/bits is totally the wrong direction, and in fact I'd like to see some of the special ones got rid of if possible. e.g. Get rid of P (not really useful these days & no-one uses it), and get rid of H (never seen this used, but it was often misused as a Hide flag). Would definitely be nice if we could get rid of S too.
Flags just cause problems, especially when backing-up & restoring programs or the OS partition using a non-Amiga filingsystem. I've also seen the situation where OS4 refuses to run an executable that was built on a non-Amiga system, because it was missing the E bit. Similar problems for the S bit in archives build on foreign systems.
Although I'd love to see the H flag officially repurposed as a Hide flag, since this was quite handy on OS3 with Directory Opus 5.
Why not just adopt an MSDOS filesystem for Amiga to eliminate all incompatailities and clone the Winders GUI etc. etc. I don't own a PC, only Amiga and like to do things for Amiga on Amiga. The less Amiga differs from other OS's the less reason I have to use it. What happens to Linux files that are backed up to an MSDOS filesystem? Do they work right when you restore them to Linux? I'm not sure because I don't use Linux but I'm guessing that permissions or something might not transfer correctly. No. I prefer the idea of expanding an existing Amiga system (the protection bits) to altering it to make another OS happy with it's files.
Why not just adopt an MSDOS filesystem for Amiga to eliminate all incompatailities and clone the Winders GUI etc. etc.
Sounds like a straw-man argument to me. I never suggested such ridiculous things, but rather to just get rid of some basically unused flags. Plus I agreed that making AmigaOS more intelligent would make it better handle files exchanged with non-Amiga systems. I really don't see how that could be bad.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
