[windows] <app> console starts incorrectly

[artman41]

Version info

• erts 10.1
• elixir 1.7
• Distillery 2.0.12

Steps to reproduce

Run <app> console

Description of issue

When running <app> console I expect a local node to be started and the current console window to attach to that session. As it stands, an erlang window will appear momentarily before closing with the following appearing in the console

PS C:\Users\hught\GuitarSniffer\Core\bin> .\guitar_sniffer_core.bat console

Id     Name            PSJobTypeName   State         HasMoreData     Location             Command
--     ----            -------------   -----         -----------     --------             -------
1      post_start h... BackgroundJob   Running       True            localhost            ...


PS C:\Users\hught\GuitarSniffer\Core\bin>

[artman41]

After modifying the console.ps1 file so that it looks like the following

## Run the app in console mode
$bin = whereis-erts-bin
$erl = (join-path $bin "erl.exe")

$boot = (join-path $Env:REL_DIR "$Env:REL_NAME")

$argv = @("-boot", $boot)
$argv += @("-config", $Env:SYS_CONFIG_PATH)
$argv += @("-args_file", $Env:VMARGS_PATH)
$argv += @("-user", "Elixir.IEx.CLI")
$argv += @("-extra", "--no-halt", "+iex")

run-hooks -Phase pre_start

$post_start = {
    start-sleep -Second 2
    run-hooks -Phase post_start
}

# Run post-start hooks asynchronously
start-job -Name "post_start hooks" -ScriptBlock $post_start

Write-Host ""
Write-Host "Command: $erl $argv"
Write-Host ""

iex "$erl $argv"

I instead get the following error:

PS C:\Users\hught\GuitarSniffer\Core\bin> .\guitar_sniffer_core.bat console

Id Name PSJobTypeName State HasMoreData Location Command

---

1 post_start h... BackgroundJob Running True localhost ...

Command: C:\Users\hught\GuitarSniffer\Core\erts-10.1\bin\erl.exe -boot C:\Users\hught\GuitarSniffer\Core\releases\0.1.0\guitar_sniffer_core -config C:\Users\hught\GuitarSniffer\Core\var\sys.config -args_file C:\Users\hught\GuitarSniffer\Core\var\vm.args -user Elixir.IEx.CLI -extra --no-halt +iex

{"init terminating in do_boot",{undef,[{'Elixir.Mix.Releases.Runtime.Pidfile',start,[],[]},{init,start_in_kernel,5,[{file,"init.erl"},{line,1085}]},{init,eval_script,2,[{file,"init.erl"},{line,933}]},{init,do_boot,3,[{file,"init.erl"},{line,813}]}]}}
init terminating in do_boot ({undef,[{Elixir.Mix.Releases.Runtime.Pidfile,start,[],[]},{init,start_in_kernel,5,[{},{}]},{init,eval_script,2,[{},{}]},{init,do_boot,3,[{},{}]}]})

Crash dump is being written to: erl_crash.dump...done

PS C:\Users\hught\GuitarSniffer\Core\bin>

[bitwalker]

What version of Powershell is this on?

[artman41]

PS C:\Users\hught> $PSVersionTable                                                                                                                       
Name                           Value                                        ----                           -----                                          
PSVersion                      5.1.17763.134                                PSEdition                      Desktop                                      
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                      BuildVersion                   10.0.17763.134                               
CLRVersion                     4.0.30319.42000                              WSManStackVersion              3.0                                          
PSRemotingProtocolVersion      2.3                                          SerializationVersion           1.1.0.1    

[artman41]

using the master branch results in the erl window appearing and staying open until closed, however I still believe this to be unexpected behaviour as I would expect <app> console to result in a local session running within the current cmd/powershell window, rather than creating an erlang window

[bitwalker]

@artman41 The powershell scripts in Distillery are targeting PS core (which on my machine is v6.0.4, but I haven't updated recently). The reason for this is because it allows me to test the scripts on a non-Windows machine, as I do not have a dedicated Windows box. If you are encountering bugs in older versions of Powershell, it may work better on PS core. In general I'd like to make sure the scripts are kept compatible with PS core first, older versions second.

using the master branch results in the erl window appearing and staying open until closed, however I still believe this to be unexpected behaviour as I would expect console to result in a local session running within the current cmd/powershell window, rather than creating an erlang window

The reason we use werl is because it is a full featured Erlang shell, whereas erl on Windows is very primitive (it is missing quite a bit of functionality). I'm fine with making it an option to start one or the other, but I think it is important that the default be the more useful shell of the two, particularly if one is working with a running production release.

[artman41]

If that is the case then I would appreciate a flag to decide between the two on release, mainly due to the fact that it is out of my control the version of powershell my users will have and I personally am using the default powershell packaged with Windows 10

usage wise however, it makes more sense to be able to execute the batch and have the output run inside the current shell window, mirroring how it would on unix, however I can understand your hesitation if it's true that erl lacks features that werl contains

[infinityfye]

I can confirm that using the master branch results in werl not closing immediately.

[artman41]

@bitwalker can we have an update on this please?

[bitwalker]

@artman41 I'm unable to perform this work any time soon unfortunately, my win32 dev environment is not available, and both making the powershell scripts work with arbitrarily old versions of powershell, and supporting the use of erl over werl are both low priorities for me personally. I certainly understand why both things are useful/needed, but the first one especially is a significant amount of work to get right (it is a constant job just keeping the shell scripts semi-portable, let alone batch/powershell), and the second is a UX convenience.

If you or others in the community are able to assist via PRs, then I'll gladly merge such work, but unfortunately that's the best I can do for now.

I'm going to close this issue since the OP is addressed, but feel free to open new issues for the other things raised here.