So does it follow the assign (ie always point at ENVARC:) or does it resolve to whatever ENVARC: is assigned to at the time the link is created?
And if what it points at is a file, or a directory that later is replaced with a file? Will it still just look like a directory?
It follows the usual rules hardlinks follow. A lock is created on the target, and the external link goes to this lock (or rather, a duplicate of it). The RAM will resolve an external object to whatever that object is at the time of the resolution.
Of course - but surely there are better ways to share code between components?
As in using the entire code of RAM twice for two handlers? In which world does that make sense?
You cannot really do this on HappyEnv variants, as they create a dedicated device env:
It will still work exactly like this. RAM:Env is a directory, not a device, but other than that...
So is there _any way_ at all to _see_ after the creation of the link, that is is not a regular directory made with Makedir?
No, there is not.
If not - how do you know if it is a link or a directory?
You don't.
echo hah to sys:myfile
makelinke ram:test to sys:myfile force
rename sys:myfile sys:myfile2
copy ram:test to ram:test2
delete ram:test ram:test2
type sys:myfile2
Delete deletes the link, not the source file. In line 3, the reference is whatever the external link points to at the time of access. The link is established as a lock to the object, so the lock remains intact as the file is renamed. With delete, the link goes away, and the copy of its contents, and in the last line, the original file is opened again. It is never touched.
So, all is fine here.
The above should in my opinion work just fine without any errors - does it?
Yup.
Maybe we have different understanding of "code duplication" - it should be quite possible for two handlers to share code, and still have different functionality - it should be quite possible to have env-handler that uses code share from ram-handler, or at least two devices, ENV: and RAM:, that both use the same ram-handler, yet have different functionality. I really just find the "new type of magic link that only works in RAM:" rather... counter intuitive. ESPECIALLY so if there is no way to tell apart a link and a directory in RAM: using List.
Again the old Kolla. It's your system, I won't stop you to use what you want. I believe it's a good idea not to load the same code twice into the system.
So System-Startup will be in the 3.2 kickstart? I ask, of course, because in the screenshot you load it with LoadModule...
Well, if we get a 3.2 kickstart ROM, which I do not know, it will be in there. If not - not. It's probably going to be the same options as for 3.1.4: Probably a ROM and modules disks. This "related" to the common startup sequence for both. As system-startup is certainly not part of the old ROMs, it need to go on the command line explicitly.
I don't use it, and by now, I reckon most "power users" have already replaced it with LoadMonDrivers, BindMonitors or similar program.
I would prefer something akin to AddDadatype or AHI's AddAudioModes, that would be capable of more than just "run whatever is there". But that is just me, I get it.
What's so different between a binary that loads everything in a directory, and a short command sequence that does the same? After all, there is no magic "hello, I'm a monitor driver" indicator in an executable. It is an executable like any other executable, so "LoadMonDrivers" is just a way of hiding the details - in the end, it cannot do anything different.
Of course, now tell that to all the Amiga users in the world. The benefit of Execute, is that it can now take a string of commands from the outside, and just do them. FORMAT and DELETE are destructive and will most likely be discovered quickly, COPY is not so useful... but if you trigger someone to regularly execute a script from an online resource, you can be stealthy and really infect a system without the owner even knowing about it.
Sorry, I don't get your point. Oh, yes, I do, but that's the old Kolla finding reasons for complaining. In case you didn't know, you can *already* execute a script from a remote location. The syntax looks different. How scary.
Tea spoon mode again? I take your answer to mean that "action is taken" at each EOL, and when conditions (If, EndIf) are solved.
Execute does not resolve "if" or "endif". Really. It doesn't do anything fancy. All it does is stupid argument substitution by a rather simple-minded string substitution, and it does only do that in case there are arguments to substitute. The only *real* function of execute is that it fiddles with "struct CommandLineInterface" and the streams therein. If there wouldn't be argument substitution, execute would be a ten-liner. Maybe less. Execute should really use shell variables for that, but it doesn't. This is exactly what makes execute and the shell syntax so fragile.
The handling of line reading is up to the shell, really. The shell expects lines to be terminated by LF, or it does not execute them. The reason is that ^\ or window close should terminate the input. Immediately. That is an EOF.