nu -i -c does not source config.nu

[justinlovinger]

Describe the bug

nu -i -c does not source config.nu.

How to reproduce

1. Add alias test = echo "test" to config.nu.
2. Run nu -i -c test.

Expected behavior

I expected nu to start an interactive shell with configuration from config.nu, run commands from -c, and exit after those commands finished.

Screenshots

No response

Configuration

key	value
version	0.72.0
branch
commit_hash
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.64.0
cargo_version	cargo 1.64.0
pkg_version	0.72.0
build_time	1980-01-01 00:00:00 +00:00
build_rust_channel	release
features	database, default, trash, which, zip
installed_plugins

P.S. ignore build_time. This is NixOS.

Additional context

You can work around the bug by adding --config.

I believe env.nu is not sourced either, but I did not test this as thoroughly.

[fdncred]

Thanks for the report. However, this is by design which is why we give you --config and --env-config parameters if you want this information sourced.

[justinlovinger]

Is it a bug then that -e does source config.nu? It seems inconsistent.

[fdncred]

No, because the intent of -e is to run a command and then remain in the repl. This was specifically engineered to start nushell, in normal fashion, but in a particular directory.

[justinlovinger]

I see the intent, but I think it would be more intuitive if -i started an interactive shell with config.nu sourced by default, and the user could optionally source another config or no config.

[fdncred]

nu -i does load the config files, at least on the latest main

[justinlovinger]

At least on 0.72.0, nu -i does not load the config if given alongside -c. It seems the -i option is silently ignored.

[fdncred]

Agreed. It seemed like combining those two flags ignores loading the config files. I'm not sure if that's by design or not. I'll ask the core-team to chime in.

[rgwood]

I suspect this is unintentional and the combination of -i and -c flags has not been tested before (but I did not write that code, that's just my guess).

@justinlovinger can you provide a little context as to why you're trying to do this? That will help us prioritize the issue.

[justinlovinger]

@justinlovinger can you provide a little context as to why you're trying to do this? That will help us prioritize the issue.

I use this with a script to open terminal applications in a window, as if they were non-terminal applications, exec alacritty -t "''${PWD/#$HOME/'~'}:$*" -e $SHELL -i -c "$*" > /dev/null 2>&1 & disown, used like t vi path/to/file. The script is supposed to work with alias, functions, and everything else you would expect from an interactive shell, so you can simply prepend a command with t. This script works with others shells I tested.

[schmitzli]

with 0.27 i was running my definitions with a command like
nu -c my-def-cmd

as it is no longer loading the definitions, with the hint about -e i found this workaround
nu -e "my-def-cmd ; exit"

[schmitzli]

for me it is useful when triggering my commands from outside the shell, like a scheduler job or from a gui front end

[schmitzli]

oh my workaround is only working from a cmd shell...

Error:
× Nushell launched as a REPL, but STDIN is not a TTY; either launch in a
│ valid terminal or provide arguments to invoke a script!

[schmitzli]

nu -c xxx with the optional script parameter does not seem to work also.
So for my case i'll pass my_def.nu to the nu as --config which seems to work

nu -c my-def-cmd --config complete\path\to\my_defs.nu

[melMass]

I think most of the behaviours explained here changed since, posting @fdncred 's explanation from discord:

EDIT: The data I posted earlier is currently being double checked and the updated info will be gathered there