AmigaOS 3.x improvements

[matthey]

First up - C:List

C:List could really need a flag to drop "human readable" terms for days. There are times I want to use output from ´List file LFORMAT "%T"´ as variable in scripts for example, and then having words like "Today", "Friday", "Yesterday" - and even localized - is not at all useful. Pretty please, an update to C:List with a "code readable" option.

(if there are other ways to get timestamp from a file, I'm eager to know)

Just add the "dates" switch. It works with or without LFORMAT for dates but doesn't do anything for your "%T" (time) example.

>List dates LFORMAT "%D"

The icon of Ram Disk:

This is ThoR realm - Ram-Handler has been updated and improved, but still we need tricks and fiddling to make sure the icon - RAM:Disk.info - somehow ends up being saved on disk when we update it (change icon, snap shot). Since one of the updates done by ThoR involves soft links working on RAM:, I have a line in Startup-sequence that says "MakeLink RAM:Disk.info ENVARC:Sys/def_RAM.info", and this works nicely (softlinks are default too with C:MakeLink).

But - would it not be so much better if Ram-Handler also handled the Disk.info issue by itself, using ENVARC:Sys/def_RAM.info by default, updating it when user changes RAM:Disk.info?

Peter K's icon.library will use the ENVARC:Sys/def_RAM.info for ram disk by default and without using MakeLink. In more recent versions of his library, the ram disk icon will be ghosted as there is no real icon in the ram disk but he added a "NoGhost" ToolType which will keep any icon from being ghosted.

http://eab.abime.net/showthread.php?t=64079&page=69

The other option is to copy the ram disk icon to the ram disk on bootup but that uses memory.

[matthey]

It is not at all obvious that all this information is stored in RAM:Disk.info and that users are expected to copy Disk.info to ENVARC:Sys/def_RAM.info manually.

It could just automatically be saved in ENVARC:Sys/def_RAM.info by ram-handler, in fact RAM:Disk.info would not even need to exist at all.

It is also inconsistent with the way default icons work and requires special handling for one exception to save the  ENVARC:Sys/def_RAM.info every time the ram disk icon changes. These default icons in ENVARC:Sys can apply to many icons. It should be possible to have other units of ram disk which would use the same default icon. Maybe it would be possible to allow ENVARC:Sys/RAM.info to represent a particular icon device but it would still require some special handling to save and snapshot to it. It might end up being the OS performing MakeLink functionality for the icon. This could work for other icons like iconified application icons and perhaps FTPMount's active icon but I see little advantage for the work needed, larger code size and likely slow down needed (probably in workbench.library). If you want to snapshot your ram disk icon often or in different places and want it to survive reboots, MakeLink is simple and probably a good option for you.