[Solved] Why such output of "./fpc"

[AlexTP]

user@PC:~/fpcupdeluxe/fpcupdeluxe32/fpc/bin/x86_64-linux$ ./fpc
Free Pascal Compiler version 3.2.1-r48494 [2021/02/02] for x86_64
Copyright (c) 1993-2020 by Florian Klaempfl and others
/home/user/fpcupdeluxe/fpcupdeluxe32/fpc/bin/x86_64-linux/fpc [options] <inputfile> [options]
 Only options valid for the default or selected platform are listed.

I suggest not to print the enture path of 'fpc' binary here:

/home/user/fpcupdeluxe/fpcupdeluxe32/fpc/bin/x86_64-linux/fpc [options] <inputfile> [options]

[Jonas Maebe]

It prints paramstr(0), which under Linux includes the full path if that's what you typed on the command line. It's also important, because an fpc binary in a different location may be a different version that supports different options.

[Warfley]

Thats not quite right, this is FPC specific behavior and has nothing to do with Linux.

On Linux usually the first argument (argv[0] in c, or $0 in bash) is the first argument given to the exec* call. In Bash this is exactly the path used in the command. The FPC however always compiles the code in a way that it will always return the absolute path (don't ask me why and how, I only observed this behavior from the outside). Example:
test.c:

Code: C  [Select][+][-]

1. #include<stdio.h>
2.  
3. int main(int argc, char const * const *argv) {
4.   printf("%s\n", argv[0]);
5.   return 0;
6. }

test.sh:

Code: Bash  [Select][+][-]

1. echo $0

test.pas:

Code: Pascal  [Select][+][-]

1. program Test;
2. {$Mode ObjFPC}{$H+}
3.  
4. begin
5.   WriteLn(ParamStr(0));
6. end.

Outputs:

Code: Bash  [Select][+][-]

1. user@ubuntu:~$ test/ctest
2. test/ctest
3. user@ubuntu:~$ test/pastest
4. /home/user/test/pastest
5. user@ubuntu:~$ bash test/test.sh
6. test/test.sh
7. user@ubuntu:~$ cd test
8. user@ubuntu:~/test$ ./ctest
9. ./ctest
10. user@ubuntu:~/test$ ./pastest
11. /home/user/test/pastest
12. user@ubuntu:~/test$ bash ./test.sh
13. ./test.sh
14.  

For C cli applications it is common pratice for help pages to simply print argv[0] [options] as first line, something the FPC also does with ParamStr(0). The thing is that ParamStr behaves differently then most other languages.

It should be noted that this means that information is actually lost, as you can see here:

Code: Bash  [Select][+][-]

1. test@ubuntu:~$ test/../test/../test/ctest
2. test/../test/../test/ctest

The complete path information of the call is stored, even the redundant one. I don't know of any possibility to access this information from fpc programs

[MarkMLl]

In any event, an inexperienced user shouldn't be messing around with a malformed command line.

OTOH I think that complaining that FPC doesn't support the --version and --help commands would be fair criticism.

MarkMLl

[trev]

I didn't think using paramStr(0), or any function which uses it, on any UNIX or UNIX-like platform to determine the location of an executable was advised.

[lucamar]

I didn't think using paramStr(0), or any function which uses it, on any UNIX or UNIX-like platform to determine the location of an executable was advised.

It isn't, because it has many potential pitfalls. The RTL tries to overcome most of them (which is probably why it returns an absolute path no matter what) but they are there nevertheless.

[marcov]

Did you try argv[0] ?