I'm trying to launch my default browser under Linux. When Icode OpenURL('https://www.noip.com/');, nothing happens.
This works for me in Ubuntu 18.04 LTS and now 20.04 LTS
Your way of execution assumes that xdg-open is a binary, and not a script.Why does that matter?
Your way of execution assumes that xdg-open is a binary, and not a script.Why does that matter?
Scripts are executed by a shell. It is the one that interprets the shebang (#!) at the start to determine the correct interpreter.
TProcess however uses fork/exec and thus the kernel to start binaries and the kernel itself does not handle scripts. Thus you need to start a shell and pass it the command to ensure that it is executed.
(* If the file is executable then assume that this is a script or program that *)
(* checks the content of the file of interest, and if it fails to return a zero *)
(* result return false. Otherwise assume that the name is that of the file of *)
(* interest and return false if the age is greater than was specified on the *)
(* command line. ExecuteProcess() might misbehave under gdbserver, if in doubt *)
(* use "old school" debugging techniques. *)
if fpStat(mon[i].name, buff) <> 0 then (* Probably same as FileExists() above *)
exit(false);
if buff.mode and &001 = &001 then begin (* Executable by "other" *)
try
age := ExecuteProcess(mon[i].name, IntToStr(mon[i].mins))
except
age := $ffff
end;
if age <> 0 then (* Visible for debugging *)
exit(false)
else
smallest := 2 (* See comment on result/sideffect below *)
end else begin
(* There's a misnomer here that always catches me out: this returns a timestamp *)
(* rather than an age (relative timestamp). *)
age := FileAge(mon[i].name); (* Visible for debugging *)
scratch := DateTimeToStr(FileDateTodateTime(age));
age := Round((UTC_Now() - FileDateTodateTime(age)) * MinsPerDay);
if age > mon[i].mins then
exit(false)
end
end;
#!/usr/bin/perl
$MAINLOG = '/var/log/exim4/mainlog';
$MAINLOG1 = $MAINLOG . '.1'; # Optional "last" logfile
$LIMIT = 90;
...
Scripts are executed by a shell. It is the one that interprets the shebang (#!) at the start to determine the correct interpreter.
TProcess however uses fork/exec and thus the kernel to start binaries and the kernel itself does not handle scripts. Thus you need to start a shell and pass it the command to ensure that it is executed.
The kernel most definitely used to, and I have no reason to believe that this has changed: i.e. the shebang is specifically processed by code in the Linux kernel rather than relying on a shell, which is different from some other unix implementations.
Historically, there have been two ways that implementations can exec shell scripts.
One common historical implementation is that the execl(), execv(), execle(), and execve() functions return an [ENOEXEC] error for any file not recognizable as executable, including a shell script. When the execlp() and execvp() functions encounter such a file, they assume the file to be a shell script and invoke a known command interpreter to interpret such files. This is now required by POSIX.1-2017. These implementations of execvp() and execlp() only give the [ENOEXEC] error in the rare case of a problem with the command interpreter's executable file. Because of these implementations, the [ENOEXEC] error is not mentioned for execlp() or execvp(), although implementations can still give it.
Another way that some historical implementations handle shell scripts is by recognizing the first two bytes of the file as the character string "#!" and using the remainder of the first line of the file as the name of the command interpreter to execute.
This might not work on every *nix system however as POSIX states this about the exec* (https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html) family of calls:
I finally found the reason, which is due to the rights policy under Linux. I run a Lazarus as 'root',
In such a case, is there a way to code, with Lazarus, in the program, a workaround to this kind of problem :-\ ?
Don't run as root, you're a disaster waiting to happen.
If your program needs a specific right over and above those held by ordinary users, then you should be using POSIX capabilities.
And while gdb has problems debugging that, gdbserver works perfectly well except - as I noted earlier - when trying to run something with a shebang (see PascalDragon's comments for the probable reason).
I am 'root' in development only. I always test afterwards, regularly, the software as 'user01'.
The IDE is an extremely complex piece of software, which activates an enormous number of libraries handling rendering etc.
There is no reason to do this, and you shouldn't be doing it.