Currently, the bios.lua handling of startup files only supports a single "source" of user startup files. Specifically, all discovered user startup files are stored in a lua table, but each location that has any such files replaces the existing table, as can be seen on line 207. This means that if you have more than one drive with startup files, only the first such drive returned by peripheral.getNames() will have its files executed (since line 208 then terminates the loop, and if any disks have startup files then any local ones will not be run.

While this isn't actually a security concern, since users can simply disable the shell.allow_disk_startup setting, it does prevent users from having a normal startup file to do things like set completion for custom programs and allow disk programs to automatically set themselves up.

Currently, the only workaround is to disable shell.allow_disk_startup and write a local startup file that then emulates that functionality, searching for attached disks and checking for any startup files on any disks that are found. This is a little clunky and may be prone to error, or at least to edge-case unexpected behaviour, because if the computer itself has multiple startup files in a /startup directory and the disk loader is only one of them, then it becomes difficult to ensure that all local startup files will run before the disk ones do.

To that end, I propose changing the bios functionality to instead append startup files from disks (if enabled via shell.allow_disk_startup, of course) so that local files are always run, and then followed by any disk files present.

This would have side effect of making it so disk drive startup no longer overwrites normal startup. Which was a feature of it basically forever.

Then it could be implemented with a setting, like bios.disk_startup_overrides_local with a default of true. In that case, it would be possible to disable the override behaviour, per-computer at that, in cases where it's undesirable.

Currently, the bios.lua handling of startup files only supports a single "source" of user startup files.

Technicality here, the bios doesn't actually invoke that startup file, it's done in the shell when there's no parent shell. The routing is: bios -> multishell -> shell -> rom/autorun -> computer startup files -> (first selected) disk drive startup files -> shell input

TL;DR for below: The solution is we really shouldn't be using two booleans and instead should be using a string list of either paths to the startup files or drives with roots containing the startup files. I attempt to address them in a way that makes the two booleans backwards comptabile, but it's a downright headache.

One solution would be to define a shell.startup.path setting that gets interpreted by the shell between computer startup files and disk drive startup files, assuming allow_startup is true in the first place. The most similar setting like this would be motd.path:

Another idea would be something like shell.startup_boot_order, which lists the order in which drives that could have startup files are ran. The default value would be something like "rom:hdd:drive_x" where drive_x is the first drive found by getNames(). Setting it to "" would be like setting shell.allow_startup and shell.allow_disk_startup to false, with the added ability that rom startup is skipped. This would require a couple of things happen:

1. An fs.getDriveRoot function that works in the inverse of getDrive, returning the root path for the given mount.
2. This part of the rom startup file should be moved into the shell (and modified to properly work with this idea).