Forum > macOS / Mac OS X
Difference in ParamStr(0) between running with Debugger and running without
carl_caulkett:
* Mac Mini M1
* macOS 14.6.1
* Lazarus 3.99
* FPC 3.3.1
While investigating an error posted by @Chiong in https://forum.lazarus.freepascal.org/index.php/topic,69173.msg536968.html#msg536968, I noticed that ParamStr(0) behaves differently when run with the debugger and without. Basically, without the debugger, ParamStr(0) reports the location of the actual Unix executable, whereas with debugging enabled (Dwarf 3 (beta)), the location of the symlink within the App bundle is reported.
To demonstrate, run the attached project (tweaked) with and without the debugger. The ShowMessage(ParamStr(0)); will display different messages. I've quickly knocked up a utility unit caPaths which ensure that @Chiong's program works in either debugging mode...
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---unit capaths; {$mode objfpc}{$H+} interface uses Classes, SysUtils; {$IFDEF DARWIN}const APP_BUNDLE_SUFFIX = '.app/Contents/MacOS';{$ENDIF} type Paths = class private class function Sep: string; public class function AppPath: string; class function AppFolder: string; end; implementation class function Paths.Sep: string;begin Result := DirectorySeparator;end; class function Paths.AppPath: string;var Path: string; AppPos: integer;begin Path := ParamStr(0); {$IFDEF DARWIN} AppPos := Pos(APP_BUNDLE_SUFFIX, Path); if AppPos > 0 then Path := Copy(Path, 1, AppPos - 1); {$ENDIF} Result := Path;end; class function Paths.AppFolder: string;begin Result := ExtractFileDir(AppPath);end; end.
This may be a known problem, for all I know. But it does cause problems if one is trying to use the app folder to load accompanying data files, and suchlike :o
rvk:
--- Quote from: carl_caulkett on November 07, 2024, 12:30:48 am ---I've quickly knocked up a utility unit caPaths which ensure that @Chiong's program works in either debugging mode...
--- End quote ---
Does that still result in retrieving an actual existing unix executable and not just a path??
I don't have Mac so I can't test... but I thought the .app is not the executable but that's in one of the subfolders in Contents/MacOS.
Note that paramstr(0) should actually return the executable and not a path.
What does Application.Exename return?
https://forum.lazarus.freepascal.org/index.php/topic,52585.msg388004.html#msg388004
--- Quote ---Application.Exename uses the official function for that. The fact that it returns a symbolic link's location if that's how the application is started, is therefore by design. It also enables the Lazarus trick of creating an application bundle that contains a symbolic link to an executable outside the bundle.
--- End quote ---
Martin_fr:
On Mac => So presumingly you are using the lldb + fpdebug backend?
Then you can look at: menu > IDE internals > debug output
to see what command lldb is given. What is set as the exe.
Can you run lldb from command line and set a different exe to get the behaviour you want?
carl_caulkett:
--- Quote from: rvk on November 07, 2024, 09:47:16 am ---Does that still result in retrieving an actual existing unix executable and not just a path??
--- End quote ---
Seems to !
--- Quote from: rvk on November 07, 2024, 09:47:16 am ---I don't have Mac so I can't test... but I thought the .app is not the executable but that's in one of the subfolders in Contents/MacOS.
--- End quote ---
Not quite! The .app is the folder itself, but macOS treats it as an executable. When Lazarus produces such a .app package, there will also be be a Unix executable alongside that .app. Within the .app folder is this structure...
UPDATE: Sorry @rvk, I misread your comment. You're saying exactly what I then went on to explain!
--- Code: Text [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---~/Code/fpc/SchuellersBook tree SchuellersRepertory.app SchuellersRepertory.app└── Contents ├── Info.plist ├── MacOS │ └── SchuellersRepertory -> ../../../SchuellersRepertory ├── PkgInfo └── Resources Note the SymLink within the MacOS folder, linking to the aforementioned Unix executable parallel to the .app bundle.
--- Quote from: rvk on November 07, 2024, 09:47:16 am ---Note that paramstr(0) should actually return the executable and not a path.
--- End quote ---
It does!
--- Quote from: rvk on November 07, 2024, 09:47:16 am ---What does Application.Exename return?
--- End quote ---
Same problem...
Without debugging... /Users/carlcaulkett/Code/fpc/SchuellersBook/SchuellersRepertory - referring to the Unix executable alongside the .app bundle.
With debugging... /Users/carlcaulkett/Code/fpc/SchuellersBook/SchuellersRepertory.app/Contents/MacOS/SchuellersRepertory - Referring to the SymLink to the Unix executable.
--- Quote from: rvk on November 07, 2024, 09:47:16 am ---https://forum.lazarus.freepascal.org/index.php/topic,52585.msg388004.html#msg388004
--- Quote ---Application.Exename uses the official function for that. The fact that it returns a symbolic link's location if that's how the application is started, is therefore by design. It also enables the Lazarus trick of creating an application bundle that contains a symbolic link to an executable outside the bundle.
--- End quote ---
--- End quote ---
But surely Application.ExeName should return the same information regardless of whether or not debugging is in operation!
carl_caulkett:
--- Quote from: Martin_fr on November 07, 2024, 10:11:16 am ---On Mac => So presumingly you are using the lldb + fpdebug backend?
--- End quote ---
I am.
--- Quote from: Martin_fr on November 07, 2024, 10:11:16 am ---Then you can look at: menu > IDE internals > debug output
to see what command lldb is given. What is set as the exe.
--- End quote ---
Process 49760 launched: '/Users/carlcaulkett/Code/fpc/SchuellersBook/SchuellersRepertory.app/Contents/MacOS/SchuellersRepertory' (arm64)
--- Quote from: Martin_fr on November 07, 2024, 10:11:16 am ---Can you run lldb from command line and set a different exe to get the behaviour you want?
--- End quote ---
I could, but the fact remains that with debugging, the SymLink is being treated as the executable, whereas, without debugging, the actual Unix executable is being treated as the executable. Since these have different path locations, it means that any code that tries to use that path location for, say locating, data files, is either going to have to cope with the difference, or is going to fail :o
Navigation
[0] Message Index
[#] Next page