Context
Investigated 2026-08-11: whether AmiPilotServer could be dropped into WBStartup with all its parameters (SERIAL, TCP, TCPPORT, BAUD, FSROOT, TCPALLOW, TCPPASSWORD, ...) set as icon ToolTypes, so it comes up headless and pre-configured on boot with no Shell involved.
Turns out it can't, today. RealMain() (server/src/amipilotserver/main.c) parses its own startup args with a single unconditional ReadArgs() call against AMIP_ARG_TEMPLATE (main.c:1614-1622, called at main.c:1679) -- nothing else. There is no GetDiskObject()/FindToolType() call anywhere that reads the server's own .info file. The only tooltype-reading code in this codebase at all is WBLAUNCH's (server/src/wblaunch.c), and that's for building a scratch icon for a different, target program AmiPilotServer launches -- it has nothing to do with configuring AmiPilotServer itself.
Concretely: double-clicking the server's own icon, or placing it directly in WBStartup, runs it via a genuine Workbench start with no console-derived argument string. ReadArgs() in that case has nothing to parse, so every argument defaults -- no SERIAL, no TCP, no FSROOT grants. Any ToolTypes set on the icon are silently ignored, not a soft warning.
Proposal
When started from Workbench (WBenchMsg rather than a CLI), read the server's own icon via GetDiskObject() and translate its ToolTypes into the same AMIP_ARG_TEMPLATE keys ReadArgs() already understands (SERIAL, SERDEVICE, SERUNIT, BAUD, TCP, TCPPORT, FSROOT, TCPALLOW, TCPPASSWORD), so a WBStartup drawer icon with ToolTypes like:
TCP=1
TCPPORT=1234
FSROOT=T: RAM:
configures it exactly as the equivalent Shell command line would. FSROOT's existing /M (multi-value) semantics need a documented ToolTypes-side convention (e.g. one FSROOT=T: entry per root, mirroring how AmigaOS ToolTypes normally express repeatable values, since ToolTypes are naturally one-entry-per-line unlike ReadArgs' space-separated /M).
Scope notes
- Today's workaround (verified as the real answer for now, see the AmiPilot conversation this issue came from): put a script/CLI-launcher icon in
WBStartup instead, running Run <>NIL: SRC:build/server/AmiPilotServer TCP TCPPORT=1234 FSROOT=T: RAM: -- a genuine console-derived args string, unaffected by this gap. Worth keeping documented in server/README.md regardless of whether this issue is picked up.
- Should degrade the same way
AmipWbLaunch()'s own icon.library-absent path already does if icon.library can't be opened -- not fatal, just no ToolTypes to read.
- CLI (
ReadArgs()) stays the primary/authoritative path; this only adds a second source of the same arguments for the Workbench-start case, not a replacement.
Context
Investigated 2026-08-11: whether
AmiPilotServercould be dropped intoWBStartupwith all its parameters (SERIAL,TCP,TCPPORT,BAUD,FSROOT,TCPALLOW,TCPPASSWORD, ...) set as icon ToolTypes, so it comes up headless and pre-configured on boot with no Shell involved.Turns out it can't, today.
RealMain()(server/src/amipilotserver/main.c) parses its own startup args with a single unconditionalReadArgs()call againstAMIP_ARG_TEMPLATE(main.c:1614-1622, called at main.c:1679) -- nothing else. There is noGetDiskObject()/FindToolType()call anywhere that reads the server's own.infofile. The only tooltype-reading code in this codebase at all isWBLAUNCH's (server/src/wblaunch.c), and that's for building a scratch icon for a different, target programAmiPilotServerlaunches -- it has nothing to do with configuringAmiPilotServeritself.Concretely: double-clicking the server's own icon, or placing it directly in
WBStartup, runs it via a genuine Workbench start with no console-derived argument string.ReadArgs()in that case has nothing to parse, so every argument defaults -- noSERIAL, noTCP, noFSROOTgrants. Any ToolTypes set on the icon are silently ignored, not a soft warning.Proposal
When started from Workbench (
WBenchMsgrather than a CLI), read the server's own icon viaGetDiskObject()and translate its ToolTypes into the sameAMIP_ARG_TEMPLATEkeysReadArgs()already understands (SERIAL,SERDEVICE,SERUNIT,BAUD,TCP,TCPPORT,FSROOT,TCPALLOW,TCPPASSWORD), so a WBStartup drawer icon with ToolTypes like:configures it exactly as the equivalent Shell command line would.
FSROOT's existing/M(multi-value) semantics need a documented ToolTypes-side convention (e.g. oneFSROOT=T:entry per root, mirroring how AmigaOS ToolTypes normally express repeatable values, since ToolTypes are naturally one-entry-per-line unlike ReadArgs' space-separated/M).Scope notes
WBStartupinstead, runningRun <>NIL: SRC:build/server/AmiPilotServer TCP TCPPORT=1234 FSROOT=T: RAM:-- a genuine console-derived args string, unaffected by this gap. Worth keeping documented inserver/README.mdregardless of whether this issue is picked up.AmipWbLaunch()'s own icon.library-absent path already does ificon.librarycan't be opened -- not fatal, just no ToolTypes to read.ReadArgs()) stays the primary/authoritative path; this only adds a second source of the same arguments for the Workbench-start case, not a replacement.