AROS World Exec
Support => Free Pascal => Topic started by: MarcusF on July 15, 2022, 04:16:24 PM
-
Hello!
I am trying to figure out how to execute a binary or scripts from FPC, like we do with for example RunCommand()
Tried to find information but have not succeeded :( hoping someone here will have a snippet or link for how to do it.
My goal is to launch installer scripts from my program.
-
Hi
Aros uses InstallerLG, commodore installer replacement in this package there is a guide file maybe for make a script
http://aminet.net/util/sys/InstallerLG.i386-aros.lha
-
Hello!
HI, and sorry for the delay. I'm quite busy atm...
I am trying to figure out how to execute a binary or scripts from FPC, like we do with for example RunCommand()
I assume RunCommand isn't working for you ? It does for me but perhaps not as you want it to (feel free to let me know).
devil's code:
program running_with_the_devil;
{$MODE OBJFPC}{$H+}
uses
sysutils, process;
function DQuote(const s: string): string; inline;
begin
result := sysutils.AnsiQuotedStr(s, '"');
end;
function GetAppPath: string; inline;
begin
result := ExtractFilePath(ParamStr(0));
end;
procedure RunACommand;
const
name = 'hello_command';
var
fn : string = '';
ret : integer;
begin
writeStr(fn, GetAppPath, name);
writeln('Run A command ', DQuote(fn));
ret := ExecuteProcess(fn, '', []);
writeln('A command ', name, ' was run and returned ', ret)
end;
procedure RunBCommand;
const
name = 'hello_command';
var
fn : string = '';
ret : string;
begin
writeStr(fn, GetAppPath, name);
writeln('Run B command ', DQuote(fn));
if RunCommand(fn, [], ret, [])
then writeln('B command ', name, ' was run and returned ', DQuote(ret))
else writeln('Failed running B command');
end;
procedure RunAScript;
const
name = 'hello_script';
var
fn : string = '';
ret: integer;
begin
writestr(fn, GetAppPath, name);
writeln('Execute A script ', DQuote(fn));
ret := ExecuteProcess('C:execute', fn, []);
writeln('A script ', name, ' was executed and returned ', ret)
end;
procedure RunBScript;
const
name = 'hello_script';
var
fn : string = '';
ret : string;
begin
writeStr(fn, GetAppPath, name);
writeln('Execute B script ', DQuote(fn));
if RunCommand('C:execute', [fn], ret, [])
then writeln('B script ', name, ' was executed and returned ', DQuote(ret))
else writeln('Failed executing B script');
end;
begin
RunACommand;
RunAScript;
RunBCommand;
RunBScript;
end.
Commando's executioner:
program hello_command;
begin
writeln('hello from command');
exitcode := 1234;
end.
Scriptology:
echo "Hello from script"
quit 4321
All put to rest, next to each other.
There is an issue with piping on AROS, but you can solve that by re-routing to a file, f.e. with using TProcess (https://www.freepascal.org/docs-html/fcl/process/tprocess.html) (see also https://wiki.freepascal.org/Executing_External_Programs (https://wiki.freepascal.org/Executing_External_Programs) )
Also here EdiSyn uses a workaround (https://github.com/alb42/fpc-tests/blob/master/lcl/SynEditTest/startprogunit.pas) implementation.
Note that whenever you get stuck with Free Pascal RTL or packages, that you can also fall back to AROS RTL, see documentation from ALB42 (http://www.alb42.de/fpc-docu/) and AROS autodoc reference (http://www.aros.org/documentation/developers/autodocs/index.php)
In this particular case of running a command you could also take a peek at AROS RTL function Systemtags (http://www.alb42.de/fpc-docu/amigados/systemtaglist.html)
If something is missing and/or not working as expected for you then please let us know.
-
Thanks a bunch!
Ok so it does work, but it's not working the way I was expecting.
Your sample works and I get the returned data. But when I try this, it returns immediately with a blank string
if RunCommand('AROS:Utilities/Installer', ['APPNAME','test','SCRIPT','AROS:Marcus/Downloads/Installer-43_3/Installer-43_3/SampleScripts/install-test'], ret, [poWaitOnExit])
If I run the command in a shell it works fine and pops up the installer window, but I don't get anything when trying to launch it myself.
-
That is peculiar. As in: it works for me (tm)
Could you share a simple example that fails for you ? It's ok if you wish to do so in a pm.
There are situations where both ExecuteProcess and RunCommand fail, but that has to do with the parameter separation (or actually wrongfully combining), but you do not do so in the example you showed.
Target is aros-i386 ? and which AROS distro/version do you test this on/for (Icaros Desktop/TinyAros/AROSone/Nightly) (please don't forget version/date) ?
First thing that comes to mind is that it is perhaps something stack related, but I tested with running on fumes... so I guess it fails somewhere else. BTW note that runcommand can return immediately depending on what command exactly is executed. Also the return boolean can sometimes be a bit misleading.
-
It should not matter but do you have the same issue when you change the device name from AROS: to SYS: ?
BTW note that runcommand can return immediately depending on what command exactly is executed. Also the return boolean can sometimes be a bit misleading.
A bit more clarification as that sounded a bit vague. There are AROS/Amiga (shell) commands that return immediately, no matter what. The installer is not one of them.
I did notice though that installer returns a zero value (when aborted) but runcommand still reports that as failing (return value false). I've noted it down as needs further investigation.
-
Sorry for the delayed response magorium.
I'm compiling on Windows 11 Pro, FPC 3.2.2, Lazarus 2.2.0
Target is AROS-i386
AROS is AROSone running in a virtualbox VM.
Transfer program with FTP from inside VM (Works great)
If I run the command in a regular shell like the screenshot, it works just fine and shows the installer window as it should.
But when I run it through runcommand with this exact line it doesn't work if RunCommand('AROS:Utilities/Installer', ['APPNAME','test','SCRIPT','AROS:Marcus/Downloads/Installer-43_3/Installer-43_3/SampleScripts/install-test'], ret, [poWaitOnExit])
-
Thank you MarcusF for using my AROS One x86 for your tests, if you encounter any problem on AROS One that I can fix please report it.
In scripts I cannot help you because I am not a developer, but I can help you on AROS/Amiga OS where I am quite experienced.
-
It's working really well!
I do have some questions, but I'll do that in a separate thread.
Ignore that it says "script" and such, the code is this:
-
Ignore that it says "script" and such, the code is this:
Was about to ask about that and was preparing a rewind/reset for this issue ;)
Ok, that is indeed strange because funny or not, i used the exact same installscript you downloaded for testing purposes. The only thing i really do different is using SYS: instead of AROS: and i use variables to 'contain' the locations for the installer executable and the actual installer script.
PS: i think you already noted it but there is a difference between starting your compiled executable from the shell or when double clicked using the workbench icon. However for both situations i get the installer to run correctly. Could you try raising the stack just before running your executable from the shell ? (command = STACK numbersize). Stack without providing a number should (if i remember correctly) return the current used stack-size (thus increase the number where you can go really wild depending on how much memory you gave your vm).
-
magorium, On AROS there is StackMon that shows the Stack used, on AROS you would need a program like "StackAttack (http://aminet.net/package/util/boot/StackAttack2)" which automatically adds the required stack
-
Ignore that it says "script" and such, the code is this:
Was about to ask about that and was preparing a rewind/reset for this issue ;)
Ok, that is indeed strange because funny or not, i used the exact same installscript you downloaded for testing purposes. The only thing i really do different is using SYS: instead of AROS: and i use variables to 'contain' the locations for the installer executable and the actual installer script.
PS: i think you already noted it but there is a difference between starting your compiled executable from the shell or when double clicked using the workbench icon. However for both situations i get the installer to run correctly. Could you try raising the stack just before running your executable from the shell ? (command = STACK numbersize). Stack without providing a number should (if i remember correctly) return the current used stack-size (thus increase the number where you can go really wild depending on how much memory you gave your vm).
I'll try changing the stack soon as I get back to my computer. Can you paste your exact runcommand code?
-
I'll try changing the stack soon as I get back to my computer. Can you paste your exact runcommand code?
Zip with example source-code, compilation log, compiled i386-aros executable and screenshots running the executable from shell and workbench can be found at: https://ufile.io/ncflsu4n
-
magorium, On AROS there is StackMon that shows the Stack used, on AROS you would need a program like "StackAttack (http://aminet.net/package/util/boot/StackAttack2)" which automatically adds the required stack
Thank you AMIGASYSTEM.
I am aware there are such programs that can help simplifying stack usage.
At the moment I am/we are trying to figure out what is wrong programming technically.
I have made the advise regarding stack because it could be that tinyaros default settings have it configured wrongly/weirdly, which (in the end) could be an issue. I want to prevent that it is actually the last thing I'm trying to advise because that causes a lot of headaches in between :-)
I am also aware that the programs you mention are especially made for that purpose (to automatically adjust the stack according to the needs of the running program) but I prefer to not rely on such programs in my own code because they can mask a real issue that is part of the programmed code (and thus would hide this from the developer/user).
-
Are there any problems with Tinyaros? I create the system of system on Windows with Ultraiso I don't touch any configuration file :-\
-
It works, I'm just an idiot.
I ran your example and it works fine. Comparing to my own code it looks about the same, should work...
Didn't get any error message when I ran my code, just an empty result.
I had a typo in the path to the installer script, and I had to switch to SYS:. I fixed it and now it runs just fine :(
-
It works, I'm just an idiot.
Your words.... not mine :P
I ran your example and it works fine. Comparing to my own code it looks about the same, should work...
Thank you for reporting back and glad to hear you got that working.
I had a typo in the path to the installer script, and I had to switch to SYS:. I fixed it and now it runs just fine :(
The typo to the script path would probably let installer silently fail at doing its job. Runcommand returning the wrong boolean result value isn't very helpful in that regards.
The use of SYS: instead of the volume name of your boot-device AROS: shouldn't really matter but, could perhaps fail (if it is then it is probably something technical that has to do with file locking as I have seen that fail before).
I apologise for not having shown a defensive programmed example in the first place. This problem could have been solved a lot sooner or perhaps even non-existent if I would have. Perhaps something to keep in mind for yourself as well when you continue your endeavours.
-
Are there any problems with Tinyaros? I create the system of system on Windows with Ultraiso I don't touch any configuration file :-\
Nope, there are no problems with Tiny Aros.
Sorry salvo, it was just a false alarm but for completeness something I had to mention. When you program software there are many things one has to consider, this was just one of those things.
-
ok i understand Magorium :)
-
PS: i think you already noted it but there is a difference between starting your compiled executable from the shell or when double clicked using the workbench icon. However for both situations i get the installer to run correctly.
magorium, regarding this topic did you read my post QUI (https://ae.amigalife.org/index.php?topic=922.270) (Last post), if it is not understandablewhat I have written see "the whole" the attached video.
https://drive.google.com/file/d/1adeeaqvFnp1Qi8e5SgrurrivqBt1bl_s/view?usp=sharing
-
magorium, regarding this topic did you read my post QUI (https://ae.amigalife.org/index.php?topic=922.270) (Last post), if it is not understandablewhat I have written see "the whole" the attached video.
I understood the issue that you mentioned but that is not a problem when it comes to Free Pascal and this particular matter as mentioned by MarcusF.
Free Pascal knows when it is started from workbench or shell and take the necessary precautions in order to accommodate this situation. However, and that is also true for Free Pascal, if you need a shell environment to pop up in order to invoke a command then you are required to add the tooltype CLI as mentioned in your post.
Not to mention that gcc is a special command in the way that it is actually meant to be run with sh and not a normal Amiga shell/CLI. You can of course but, i would not recommend it. It is ok if the only this you do is show gcc's version number.
-
Not to mention that gcc is a special command in the way that it is actually meant to be run with sh and not a normal Amiga shell/CLI.
Ok thanks, I wasn't referring to Pascal anyway, I was talking in general, the problem I mentioned happens also with other applications running via Icons on Wanderer, where to work properly you have to add the "CLI" parameter in the Icon Tooltype.
All this must also be done on Amiga OS 3.x, only OS 3.5/3.9 does not need because it has a special Tab that automatically adds the CLI parameter to the icon, see screenshot
You can of course but, i would not recommend it. It is ok if the only this you do is show gcc's version number.
No GCC but also g ++ work perfectly from Shell in AROS x86, although I am not expert I have compiled some C sources without problems