# Erlang/OTP 26.0-rc1 (Release Candidate 1) is released **URL:** \ **Category:** Erlang News\ **Tags:** erlang-release\ **Created:** [February 15, 2023, 10:34am UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361 "2023-02-15T10:34:17Z")\ **Posts on this page:** 12\ **Page:** 2
**Author:** ![frazze](https://erlangforums.com/user_avatar/erlangforums.com/frazze/32/1324_2.png) [@frazze](https://erlangforums.com/u/frazze)\ **Post date:** [February 27, 2023, 12:41pm UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/21 "2023-02-27T12:41:38Z")
> [@dominic](#): > > The new shell is cool! > > ```erlang > 1> erlang:group_leader( > typespecs > erlang:group_leader(GroupLeader, Pid) > pid() > > ``` > > if it’s nicer that shell telling me there is an `erlang:group_leader/0` too That is a bug, the intended behavior is like you said, thanks! ---
**Author:** ![Led](https://erlangforums.com/user_avatar/erlangforums.com/led/32/1594_2.png) [@Led](https://erlangforums.com/u/Led)\ **Post date:** [February 27, 2023, 3:04pm UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/22 "2023-02-27T15:04:48Z")
```erlang erl -noshell -eval "io:format(\"hello\")." -s init stop ``` And it’s logical. ---
**Author:** ![mmzeeman](https://erlangforums.com/user_avatar/erlangforums.com/mmzeeman/32/467_2.png) [@mmzeeman](https://erlangforums.com/u/mmzeeman)\ **Post date:** [February 27, 2023, 3:21pm UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/23 "2023-02-27T15:21:00Z")
Yes I see. Another possibility is this: ```erlang erl -noshell -eval "io:format(\"hello\"), halt()." ``` ---
**Author:** ![starbelly](https://erlangforums.com/user_avatar/erlangforums.com/starbelly/32/209_2.png) [@starbelly](https://erlangforums.com/u/starbelly)\ **Post date:** [February 27, 2023, 5:10pm UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/24 "2023-02-27T17:10:21Z")
I had opened up a bug report on this, but figured that they way this was being done was simply not a great to go about it (i.e., had lucked out in the past), I have re-opened the issue : > > > \*\*Describe the bug\*\* > Up until erlang otp 26 using -s init stop with an -eval sw…itch would allow one to grab some info about erts, this was useful in that one could use this method such in Makefiles, shell scripts, etc. > > This now fails with a failed to eval error message. There is a work around for this, which is simply to call \`init:stop/0\` as part of the eval. This in fact may not be a bug and is intentional, but I didn't see it listed anywhere in release notes. > > \*\*To Reproduce\*\* > > \`\`\`shell > $ erl -noshell -eval "io:format(\\"~s\\/erts-~s/include/\\", \[code:root\_dir(), erlang:system\_info(version)\])." > Error! Failed to eval: io:format("~s/erts-~s/include", \[code:root\_dir(), erlang:system\_info(version)\]). > \`\`\` > > \*\*Expected behavior\*\* > > \`\`\`shell > $ erl -noshell -s init stop -eval "io:format(\\"~s\\/erts-~s/include/\\", \[code:root\_dir(), erlang:system\_info(version)\])." > /path/to/erlang/26.0-rc1/erts-14.0/include/ > \`\`\` > > Note that the output will of course differ from platform to platform and depending how exactly you installed erlang/otp. > > Work around : > > \`\`\`shell > $ erl -noshell -eval "io:format(\\"~s\\/erts-~s/include/\\", \[code:root\_dir(), erlang:system\_info(version)\]), init:stop()." > /path/to/erlang/26.0-rc1/erts-14.0/include/ > \`\`\` > > \*\*Affected versions\*\* > The OTP versions that are affected by this bug. > > OTP-26.0-rc1 > > \*\*Additional context\*\* > No additional context. ---
**Author:** ![frazze](https://erlangforums.com/user_avatar/erlangforums.com/frazze/32/1324_2.png) [@frazze](https://erlangforums.com/u/frazze)\ **Post date:** [February 27, 2023, 5:42pm UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/25 "2023-02-27T17:42:13Z")
Sorry, the confirmation of a bug was a respons to dominic’s shell completion feedback. I have now looked into the isues with -s init stop, its working as intended: According to [documentation](https://www.erlang.org/doc/man/init.html) **-eval expressions are evaluated sequentially with -s and -run function calls (this also in the order specified)**. ---
**Author:** ![mmzeeman](https://erlangforums.com/user_avatar/erlangforums.com/mmzeeman/32/467_2.png) [@mmzeeman](https://erlangforums.com/u/mmzeeman)\ **Post date:** [February 27, 2023, 8:16pm UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/26 "2023-02-27T20:16:35Z")
Interesting. This was in the Makefile of a dep. ([bcrypt/Makefile at master · erlangpack/bcrypt · GitHub](https://github.com/erlangpack/bcrypt/blob/master/c_src/Makefile#L9)). This was used since OTP 18 or 19. Anyhow, I opened a PR to fix this. ---
**Author:** ![starbelly](https://erlangforums.com/user_avatar/erlangforums.com/starbelly/32/209_2.png) [@starbelly](https://erlangforums.com/u/starbelly)\ **Post date:** [February 28, 2023, 2:07am UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/27 "2023-02-28T02:07:19Z")
Might have found a bug, it depends 😉 There’s some nifs out there in the world that make use of the file server (for determining the path a shared object as an example). This is broken in OTP-26, but it may be intentional, it’s not clear from the notes. It might be around this PR: [Update on\_load handling during boot by RaimoNiskanen · Pull Request #6817 · erlang/otp · GitHub](https://github.com/erlang/otp/pull/6817) Happy to open an issue if needed. ---
**Author:** ![raimo](https://erlangforums.com/user_avatar/erlangforums.com/raimo/32/867_2.png) [@raimo](https://erlangforums.com/u/raimo)\ **Post date:** [February 28, 2023, 9:30am UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/28 "2023-02-28T09:30:25Z")
The intention of that PR is, as it says, to simplify `on_load` handling during boot. Then we had to decide when, during boot, in embedded mode, to run the `on_load` handlers. The change in rc1 places them after the code server and stderr, but before distribution and the file server, hoping that NIF on\_load handlers could do with the code server’s features and maybe some `filelib` functions, but not need the file server. The problem is that the little known feature “remote file server” requires the file server to be started after the Erlang distribution. The distribution (when using SSL/TLS) needs the `crypto` NIF to be loaded so, distribution needs to be after `on_load`. Hence, for NIF:s using the file server we have a circular dependency. We aim to fix this to rc2 and start the file server before the `on_load` handlers when the remote file server is not used, meaning that _if_ using remote file server (the `-master`) command line argument, NIF:s needing the file server cannot be used in the system. I do not know yet how to solve this “properly”. Kenneth has asked for how many that use the remote file server, and there seem to be some, otherwise removing that feature would resolve this. Another solution would be to declare that NIF `on_load` functions cannot use the file server, and probably extend the code server with some file server like features they in that case would need. The area is … complicated …, we have the code server that uses the prim loader that can be the file prim loader which uses the local file system, or the net prim loader that loads over a simple network protocol towards some IP address (where an `erl_boot_server` uses _that_ node’s file server). Then, later the code server switches to using the file server that can be on a remote node, unrelated to the net prim loader and to the local file system. And NIF:s (today) have to be loaded from the local file system via dlopen() or similar. NIF:s have to be able to figure out a path suitable for dlopen(), and we need to figure out how that should be done in all supported setups, then define what API:s the NIF:s are allowed to use in their `on_load` handlers. ---
**Author:** ![starbelly](https://erlangforums.com/user_avatar/erlangforums.com/starbelly/32/209_2.png) [@starbelly](https://erlangforums.com/u/starbelly)\ **Post date:** [February 28, 2023, 2:48pm UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/29 "2023-02-28T14:48:53Z")
I had no idea how complicated this was. Thank you so much for that highly informative response! ---
**Author:** ![raimo](https://erlangforums.com/user_avatar/erlangforums.com/raimo/32/867_2.png) [@raimo](https://erlangforums.com/u/raimo)\ **Post date:** [February 28, 2023, 4:02pm UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/30 "2023-02-28T16:02:25Z")
I have merged a continuation of PR#6817, that starts the file server early if possible, into ‘master’ for OTP-26.0-rc2 ---
**Author:** ![starbelly](https://erlangforums.com/user_avatar/erlangforums.com/starbelly/32/209_2.png) [@starbelly](https://erlangforums.com/u/starbelly)\ **Post date:** [February 28, 2023, 4:05pm UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/31 "2023-02-28T16:05:49Z")
I’ll give that try today and report back results. ---
**Author:** ![starbelly](https://erlangforums.com/user_avatar/erlangforums.com/starbelly/32/209_2.png) [@starbelly](https://erlangforums.com/u/starbelly)\ **Post date:** [March 1, 2023, 12:40am UTC](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361/32 "2023-03-01T00:40:14Z")
This worked like a charm. [Previous page](https://erlangforums.com/t/erlang-otp-26-0-rc1-release-candidate-1-is-released/2361.md?page=1)