A question has arisen recently, related to usage of Docker containers, but centering on the above Ashell start up argument (-mntsys).

Currently, it only supports the three prirmary system areas of BAS, CMD and SYS.

Does anyone else see a benefit in expanding this, perhaps from previous desire or need that has had to be worked around?

What possible options would be of most interest?

Perhaps just an extended list of Ersatz definitions (either in ERSATZ.INI or another specifed file), or a list of full Ashell/Native paths in a separate config file?

Any other ideas or suggestions?

I'll just add that this entire issue -- the intermixing of "system" and "application" files in common directories -- has been a thorn in a lot of developer's sides for a long time. Partly we can blame AMOS for embracing the idea of user or application-level customization of INI files in SYS:, CMD/DO files, and especially subroutines in BAS:, even though, if we're being honest, the quirky built-in search path allowed for non-DSK0 alternatives for the majority of cases. For example, it was never necessary to put your external subroutines (.SBR under AMOS or .SBX under A-Shell) in BAS:; you could store them in the application directory, or the [p,0] application library directory. LIkewise for any CMD/DO and LIT files. But still, as a matter of custom or convenience, and in a few cases perhaps necessity, it has become standard procedure for most applications to store a lot of files in DSK0: directories, mixed in with, or even replacing, files that are part of the standard release.

The question is how best to unravel that?

The -mntsys idea was a start. The reasoning behind only including 3 directories (SYS, CMD, BAS) was that those are the only directories that are part of built-in search paths. So the thinking was that you either put your own files that would otherwise go into those directories, into a separate device referenced by -mntsys, or vice versa, put yours in DSK0 but use -mntsys to reference a pristine set of A-Shell system files.

But I'll have to admit that the idea never caught on, so perhaps it's a good time to brainstorm a better solution (ideally to be hammered out at the Conference next month).

I should add that one misconception about how the built-in search paths work is that they don't actually use the ERSATZ table. We talk as if the search path included SYS:, CMD:, and BAS:, but in fact it really include DSK0:[1,4], DSK0:[2,2] and DSK0:[7,6]. I'm not really sure why -- possibly it was a hangover from the early days of insane efforts to eliminate CPU cycles. Maybe that's another detail to resolve in 7.0? But even there, it just passes the ball to another player without really scoring anything, since the ultimate problem is the combination of a more flexible search path along with better ways to separate your files from A-Shell's.