Thanks everybody for replying, and happy holidays by the way
Well, the logs show that the compiler isn't having trouble finding the Process unit (+ Library + Object), so the "unit not found" bug is just isolated in the Source viewer in Lazarus
[1.010] (10000) Unitsearch: /usr/lib/fpc/3.2.0/units/x86_64-win64/fcl-process/process.ppu
[1.010] Searching file /usr/lib/fpc/3.2.0/units/x86_64-win64/fcl-process/process.ppu... found
[1.010] (10001) PPU Loading /usr/lib/fpc/3.2.0/units/x86_64-win64/fcl-process/process.ppu
[1.010] (PROCESS) (10002) PPU Name: /usr/lib/fpc/3.2.0/units/x86_64-win64/fcl-process/process.ppu
[1.010] (PROCESS) (10011) PPU Source: process.pp not available
[1.010] (PROCESS) (10011) PPU Source: processbody.inc not available
[1.010] (PROCESS) (10011) PPU Source: process.inc not available
Which brings me back to square 1 -- RunCommand seems to work on Linux when:
1. provided with a TStringArray of parameters
& 2. provided with an "array literal" so to speak
(as in RunCommand('liesel', SomeTStringArray, ReturnString) vs. RunCommand('liesel', ['-h', '-q', '-c'], ReturnString) for example)
Where on Windows, RunCommand only seems to work when provided with an "array literal,"
+ the TProcess fails (again only on Windows) and I can't tell why (with Parameters.Add() and then Execute). (I also tried with TProcess.CommandLine just to check, and that fails as well)
Is there maybe a problem on Windows just with
programmatically determining those parameters as
variables instead of being statically-fixed parameters (having the parameters determined at
runtime instead of
compile time)? The idea is for the user to select parameters from the GUI and then execute
If that's it, is there a way to force the compiler to recognize that a particular variable will only be set at runtime rather than compile time?