You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 817 Reporter: administrator Status: closed Resolution: fixed Priority: normal Severity: minor Category: ~DO NOT USE (was: OCaml general)
Bug description
In reference to the fix for finding the program name on linux:
This causes a problem for me with both byte-code and native-code Ocaml
problems, they can no longer tell how the user invoked them, and the
user may have put something in argv[0] on purpose as I wish to.
I found this while trying to work on my trampoline program that allows
scripting by transparently doing a compile under the covers, and using
the cached executable binary when available.
I wanted the argv[0] to be the name of the original script, which the
programmer might expect, so my trampoline set argv[0] in the call to
execv for the cached binary to be the path to the original script.
Instead of what I set, the "script" sees the pathname of the cached
executable, which I see is obtained from /proc.
If the desire is to only find the full path to the program, instead of
the relative path that linux provides, and I believe linux puts the
relative path to the program in arg[0], would it not be possible to
just prepend getcwd() to argv[0], if arg[0] does not begin with '/' to
achieve what you want?
That would be my preferred solution, anyway. Please let me know what
you think. Thanks.
cheers,
doug
The text was updated successfully, but these errors were encountered:
This causes a problem for me with both byte-code and native-code Ocaml
problems, they can no longer tell how the user invoked them, and the
user may have put something in argv[0] on purpose as I wish to.
Right.
If the desire is to only find the full path to the program, instead of
the relative path that linux provides, and I believe linux puts the
relative path to the program in arg[0], would it not be possible to
just prepend getcwd() to argv[0], if arg[0] does not begin with '/' to
achieve what you want?
In general, no. For one thing, argv[0] may refer to an executable
that is in $PATH, so we have to do path searching (ocamlrun already
does this). Still, this breaks if argv[0] is a relative name and not
in the path, which can happen under Linux as shown in bug #557.
Moreover, both ocamlrun and the toplevel ocaml must know
the exact name of their own executable!
The solution I'm currently implementing is to leave Sys.argv.(0)
equal to argv[0] as provided at program start-up, but add a new string
Sys.executable_name containing the name of the executable as ocamlrun
determined it (by reading /proc/self/exe and searching argv[0] in the
path). This seems to satisfy all requirements.
Original bug ID: 817
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)
Bug description
In reference to the fix for finding the program name on linux:
http://caml.inria.fr/bin/caml-bugs/fixed?id=557
This causes a problem for me with both byte-code and native-code Ocaml
problems, they can no longer tell how the user invoked them, and the
user may have put something in argv[0] on purpose as I wish to.
I found this while trying to work on my trampoline program that allows
scripting by transparently doing a compile under the covers, and using
the cached executable binary when available.
I wanted the argv[0] to be the name of the original script, which the
programmer might expect, so my trampoline set argv[0] in the call to
execv for the cached binary to be the path to the original script.
Instead of what I set, the "script" sees the pathname of the cached
executable, which I see is obtained from /proc.
If the desire is to only find the full path to the program, instead of
the relative path that linux provides, and I believe linux puts the
relative path to the program in arg[0], would it not be possible to
just prepend getcwd() to argv[0], if arg[0] does not begin with '/' to
achieve what you want?
That would be my preferred solution, anyway. Please let me know what
you think. Thanks.
cheers,
doug
The text was updated successfully, but these errors were encountered: