| Age | Commit message (Collapse) | Author |
|---|
|
Previously you could not opt out on loading .erlang, change the
default to not load the resource file. The escript author
can invoke c:erlangrc(PathList) to find and load .erlang if needed.
|
|
|
|
|
|
escript failed to start Erlang systems with spaces in the
absolute path (when absolute path was used).
|
|
Erlang system found in PATH was used even when explicitly pointing out
the escript binary in another Erlang system.
|
|
|
|
Allows ps and htop to display the invoking program/script name
instead of beam[.smp].
|
|
The code has been rearranged to make use of the actual path
"get_default_emulator(scriptname)" to the escript instead of
the given one "get_default_emulator(argv[0])".
TL;DR
Assume a source system with some Erlang applications (app1, app2 etc.)
and an escript called "mytool". When generating a standalone target
system (with reltool for example), the escript(s) are located in the
same top bin directory as "erl". See mytool* below.
In such a system the original "mytool" escript is given the extension
".escript" and the file with the same name as the original escript is
a copy of the "escript" executable. One purpose of the escript
executable is to determine which "erl" to use to start the system.
In a standalone system we want it to find the runtime system bundled
with the escript(s). This is done by analyzing the path in order to
find the "erl" located in the same directory as the escript.
A dilemma here is that we do not want to put the top bin directory
in the execution path (PATH env var) as we then would cause other
Erlang applications to make use of our bundled run-time system.
One way of solving this is to choose some suitable bin directory in
the execution path (such as /user/local/bin) and put a symbolic link
there to our mytool executable.
Unfortunately this did not work as the escript executable (in this
case called mytool) would try to find "erl" in /usr/local/bin and when
it did not find such a file it resorted to use the command "erl" which
would find some (unwanted) "erl" in the execution path.
My fix solves that problem.
├── bin/
│ ├── erl* (dyn_erl.c)
│ ├── mytool* (escript.c)
│ ├── mytool.escript* (original mytool escript)
│ └── start_clean.boot
├── erts-vsn/
│ └── bin/
│ ├── beam*
│ ├── beam.smp*
│ ├── erl*
│ ├── erl_child_setup*
│ ├── erlexec*
│ └── inet_gethost*
└── lib/
├── app1-vsn
├── app2-vsn
└── ...
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
|
|
Fix the command line tools to abort on allocation failures when run
on Windows. Modify the malloc() wrapper to consistently return void*
across all the tools.
|
|
This reverts commit 731890f3b4ac62eed1221aa7d9fd2bfa6bf51d8c.
|
|
`ct_run.c`, `erlc.c`, `escript.c` and `typer.c` do not preserve space characters in the emulator
path. Thus, if a path containing space is passed via environment variables, such as
`ESCRIPT_EMULATOR`, or if `get_default_emulator(progname)` returns a path with space, the execution
of the programs fail. This patch fixes all occurrences found with `grep push_words -R $ERL_TOP`.
|
|
|
|
Fix erlc, escript, dialyzer, typer, ct_run, heart
and epmd should all be using widestrings on windows
|
|
|
|
According to the documentation, if the second or third line in a
script starts with %%!, then escript will use the rest of the line
as emulator options. However, previously this was only the case
if the first line started with #!. This change removes that check,
and unconditionally uses the %%! line if present.
|
|
|
|
On Windows, escript may be passed different arvg[0] values depending
on how it was started up.
This patch allows for escript to be started as "escript.exe"
(current behaviour) and also "escript" which is more likely when
called from the default Windows cmd.exe shell.
|
|
Check buffer operations on input from escripts, the command line and
environment variables.
|
|
|
|
|
|
|
