Start script

[lrascao]

could you elaborate on the context behind this?

[msantos]

The second patch matches the behaviour of escripts. It changes the program name to the application name to make it a little easier to differentiate operationally when multiple beam process are running.

Let me know if you want it removed. Same behaviour can be done by explicitly setting ESCRIPT_NAME in the environment before starting the app.

[tsloughter]

Oh, so when you do a ps you get a more useful name than the long erl command that you have to find the release directory in to know what it is running?

[msantos]

Right, exactly. So running rebar3 nowadays shows up in ps output something like this:

msantos  11154  3404  0  2017 pts/27   00:00:09 /home/msantos/bin/rebar3 -B -sbtu -A0 -- -root /usr/local/lib/erlang -progname erl -- -home /home/msantos -- -kernel shell_history enabled -boot start_clean -noshell -run escript start -extra /home/msantos/bin/rebar3 shell

[lrascao]

this is when running rebar3 shell right? what do you get when running the release start script?

[msantos]

Today starting a release will call exec() with argv[0] set to beam:

msantos  10428  9554 49 10:33 pts/25   00:00:01 /usr/local/lib/erlang/erts-9.2/bin/beam.smp -Bd -- ...

The change sets argv[0] to the release start script, e.g., if the application is "appname"

msantos  10054  9554 32 10:33 pts/25   00:00:01 /home/msantos/src/erlang/appname/_build/default/rel/appname/bin/appname -Bd -- ...

[tsloughter]

Sorry, forgot about tihs.

I like the goal. I just don't understand how this possibly works... $ESCRIPT_NAME isn't set to anything, and is it just a confusing name, since there is no escript involved?

[msantos]

erlexec overwrites argv[0] with the ESCRIPT_NAME env var:

https://github.com/erlang/otp/blob/e2a760e691d1b08a2396233fb50cefd98199ba12/erts/etc/common/erlexec.c#L541

[tsloughter]

@msantos but ESCRIPT_NAME isn't set before it is used in the bin script:

export ESCRIPT_NAME="${ESCRIPT_NAME-$SCRIPT}"

won't that just always end up being, dash scriptname? -$SCRIPT

[msantos]

The ${VAR-DEFAULT} expression is a sh-ism: if the variable is unset, it is replaced with a default value.

$ SCRIPT="foo"
$ echo ${ESCRIPT_NAME-$SCRIPT}
foo
$ ESCRIPT_NAME="bar"; echo ${ESCRIPT_NAME-$SCRIPT}
bar

[tsloughter]

Oh, I thought it was :- but yea, just tried it and just - works. Interesting :)

[tsloughter]

@msantos sorry but can you rebase and push again? travis isn't picking up that it shouldn't be trying to run on R15 and 16 anymore, guessing because this was created before we removed those.

[msantos]

They basically do the same thing:

In the parameter expansions shown previously, use of the colon in the
format shall result in a test for a parameter that is unset or null;
omission of the colon shall result in a test for a parameter that is
only unset. The following table summarizes the effect of the colon:

                   Set and Not Null       Set But Null      Unset
${parameter:-word} substitute parameter   substitute word   substitute word
${parameter-word}  substitute parameter   substitute null   substitute word

http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html

I can switch to using :-.

Will try to rebase and push!

[tsloughter]

Thanks. - is fine, I was just very confused about the PR until knowing it worked like :- :)

[tsloughter]

@msantos looks like something got messed up with your rebase and it created a bunch of new commits out of old commits. Maybe just cherry pick your commits to a fresh branch and push that here?

[msantos]

Should be fixed now, thanks!