I think the better option is to change the rust code to be exit_code = false so it silences more errors.

Actually I don't quite sure, it seems to me that @IanManske want to make it more explicit

People disliked the extra error messages, so actually I think it should be false everywhere.

@IanManske I get why you default to true when not using a config.nu, since users probably do want that extra error information when running a script.

I'm just not sure they realize where it will be useful yet. It may be that what we are seeing right now is just backlash against the verbose messages in the REPL, which is caused by having existing config.nu, of course.

i'm fine with either way, thanks @WindSoilder 🙏

This is an example of true and false.

with true

❯ $env.config.display_errors.exit_code = true
❯ let status = try {
❯❯❯   git status
❯❯❯ } catch {|e| print -n ""}
fatal: not a git repository (or any of the parent directories): .git
Error: nu::shell::non_zero_exit_code

  × External command had a non-zero exit code
   ╭─[entry #25:2:3]
 1 │ let status = try {
 2 │   git status
   ·   ─────┬────
   ·        ╰── exited with code 128
 3 │ } catch {|e| print -n ""}
   ╰────
❯ $env.LAST_EXIT_CODE
128

with false

❯ $env.config.display_errors.exit_code = false
❯ let status = try {
❯❯❯   git status
❯❯❯ } catch {|e| print -n ""}
fatal: not a git repository (or any of the parent directories): .git
❯ $env.LAST_EXIT_CODE
128

my vote is for false everywhere

@fdncred Isn't the fact that try isn't handling the error a separate bug?

As for the defaults, the example you give is already the default today. The only reason you are seeing the expanded errors in the REPL is because you have an outdated config.

Don't you want to see the line number the error occurred on when running it in a script?

nu script.nu
Error: nu::shell::non_zero_exit_code

  × External command had a non-zero exit code
    ╭─[/home/ntd/testing/script.nu:90:2]
 89 │ print -n ""
 90 │ ^which foobaz
    ·  ──┬──
    ·    ╰── exited with code 1
 91 │
    ╰────

If it's false in the Rust defaults, then we lose the debugging information (line number) from the Nushell error message. This is good info when debugging a script. You typically want to know that you have an unhandled non-zero exit code in your script. (And I think a handled, via try, error shouldn't be printing the error message anyway).

We can also change the "with config" default for all users if we implement #13671. That gives us the best of both worlds:

• Running nu script.nu skips loading the config, so it will still be true, and we'll get debugging errors
• Running an external command from the REPL that creates a non-zero exit code will fail silently (or with the command's own error message if applicable). This would occur for all users, unless they explicitly set it to true in their own config.

@fdncred Isn't the fact that try isn't handling the error a separate bug?

probably

As for the defaults, the example you give is already the default today. The only reason you are seeing the expanded errors in the REPL is because you have an outdated config.

correct. i was just linking to where the code was that needed to be changed.

Don't you want to see the line number the error occurred on when running it in a script?

only when i set it to true, so it's opt-in

do you think we can get this into shape before the release?

Don't you want to see the line number the error occurred on when running it in a script?

only when i set it to true, so it's opt-in

You would have to set it to true in the script itself though, not just your config. I would definitely prefer if we didn't display errors in the REPL by default, but I think it would be really, really unfortunate if you have to set $env.config.display_errors.exit_code = true at the top of every script in order to make it explain what went wrong, instead of silently exiting.

If it's possible to make scripts and REPL w/o config have different default behavior, that would be perfect, but I'm not sure if it's feasible. It looks like @IanManske alluded to doing so in #13515, maybe he has some insight.

Yep @132ikl, that's exactly what I was thinking 😉. After, #13802, a config env var with all fields initialized is present at launch without a config file loaded¹. It should be easy after this, to change a few default values in the config based on whether nushell was launched as a REPL or a script. IMO this solution is the best of both worlds.