Unintended loading `xonshrc` file in script mode about xonsh HOT 15 CLOSED

I think this is the result of #5099 (@cosineFish @bestlem).

@gforsyth I think we need to fix/revert this in 0.17.0 because:

• All xonsh scripts are affected.
• If you have many libs in xonshrc and want to run xonsh script in env you will face with unintended errors about missing libs. It's bad experience.

The user own xonshrc that is mostly for using it in prompt must NOT be loaded in script mode.

from xonsh.

The user own xonshrc that is mostly for using it in prompt must NOT be loaded in script mode.

I mean, that's the bash approach, but zsh and fish do load those files in script mode.

A user can run using --no-rc to avoid loading their xonshrc file

from xonsh.

@gforsyth

1. zsh does not do this (see example in the first message).
2. I believe that if I have CLI xonsh script.xsh with shebang I should not do anything with --no-rc. I expect that it just works. See also xonsh-awesome-cli-app.

So I'm completely for disabling load ~/.xonshrc for scripts accordingly with expectations and bash, zsh behavior.
If user wants to create xonshrc to load forever on user base level we already have ~/.config/xonsh/rc.xsh (doc).

from xonsh.

ah, right, zsh does load zshenv though -- I don't want to get into having a million special cased startup files, though.

I'm fine with this either way. If we do disable loading rc files in script mode, then we should ensure that a user can force loading them by passing -i

from xonsh.

I understand the idea from here to have this in every xonshrc file:

if $XONSH_INTERACTIVE:
    # ...

It looks clear BUT you forget about software around (e.g. conda, zoxide, xonsh wizard, xonsh web, etc) that just do:

echo "some_init_code()" >> ~/.xonshrc

And this kind of tools don't know about $XONSH_INTERACTIVE. And when they add init code into xonshrc directly ALL scripts will be affected by this and will produce errors and slow timings! This is why I think it's a not so good idea @gforsyth .

We need more complex behavior. I'm thinking about at least push out ~/.xonshrc to interactive mode.

from xonsh.

And one moment. I want to remember you all that we have already stepped on this rake when we had loading history on every xonsh run - #4178. Before this fix we observed all kinds of unexpected errors and bad experience with scripts.
Do not do unexpected unintended work undercover.

from xonsh.

I understand the idea from here to have this in every xonshrc file:

if $XONSH_INTERACTIVE:
    # ...

It looks clear BUT you forget about software around (e.g. conda, zoxide, xonsh wizard, xonsh web, etc) that just do:

echo "some_init_code()" >> ~/.xonshrc

And this kind of tools don't know about $XONSH_INTERACTIVE. And when they add init code into xonshrc directly ALL scripts will be affected by this and will produce errors and slow timings! This is why I think it's a not so good idea @gforsyth .

We need more complex behavior. I'm thinking about at least push out ~/.xonshrc to interactive mode.

This is exactly how fish does it - load the same config.fish in all cases but have test for --is-interactive and --is-login Why is this not an issue for fish?

from xonsh.

@bestlem I think it's issue for fish. Let's consider the situation. I want to write script myscript using fish and then I want to apply it for 1000 files. Why I need to load fish RC file with setting up fancy prompt 1000 times?
If the answer - "you must know about checking for interactive usage and add checking in the RC file or add --no-rc in your script" - I treat this as "you must know everything in the world" and I don't like this.

Second thing is from practice. All home ~/.*rc files xonsh/bash/zsh are ordinarily unmanageable trash on most of systems I saw and applying the code from there to every execution of scripts is the shoot in the leg.

I'm ok to keep the rest of RC places like it works now but not for ~/.xonshrc. I'm in preparing the PR.

from xonsh.

Looking at my fish config item and fzf look at --is-interactive others don't affect script usage.
In my experience I use my ~/.zshenv, config.fish etc to enforce a sane set of constant stuff across all my environments. and the PATH and environment variables will differ between Windows / WSL / MacOS/ Solaris /NeXT / Linux and if my machine is in London or Chicago when travelling or remote logging in. I don't what to have to make each script I write deal with all those cases when I can with any other shell just change one or two files for each OS.

The environment configuration is not the job of my script.

Actually I have been commenting on SO question that you must understand what each line in your shell config files does. If you don't then leave that line out.
With experience you don't have to know the details of what that line does but you do have to understand its effect on your environment.

There MUST be a way to run xonsh for scripts loading ~/.xonshrc - if you don't want it then there is --no-rc which you can put in the shebang of your script.

The major problem before was that there was --no-rc but setting XONSH_INTERACTIVE was being done in the wrong place so I think if you loaded a config file ir set it to true in all cases.

from xonsh.

@bestlem I'm thinking about ~/.xonshrc as an unmanageable buffer for random configurations. If you are experienced user who knows life you will use ~/.config/ and I assume you know what you are doing. So this is why in the PR I will make ~/.xonshrc active only of interactive mode to prevent unexpected and unintended using in scripts. The rest behavior will stay as implemented.

(JFYI I'm completely against of adding --no-rc to shebangs by default. This decision completely annihilates the value of /etc/xonsh/xonshrc and others. At the end we will have tons of tools with --no-rc in shebangs. What a hell will be.)

from xonsh.

There are some inconsistencies here.

But the inconsistencies are that in all cases all the other shells read either both user and files in /etc or neither. ie the behaviour is never not read ~/.xonshrc but read /etc/xonsrc/*
Add to that you are suggesting that ~/.xonshrc and ~/.config/xonsrc are treated differently - that is just different to anything else and will mean the script depends on where a file is which is unusual.

I note that sh and bash behave differently to zsh and fish in that the former does not read anything but the latter do read some files for scripts.

I also work on Macs and Next which don't have a login shell. On other Unixes the login shell will already have been read, So I am used to having to get $PATH set by something and I don't want that in the script but something has to be read in e.g. using ~/.xonshrc etc,

from xonsh.

First of all I described the perspective of view in the PR - #5491. Please also read the changes in docs/ section.

Why make xonsh behave differently to all other shells?

Bash and Zsh do not use ~/.bashrc and ~/.zshrc in non-interactive mode. Please don't say "all".
(And it's meaningful because every tool want to do echo "mycode" >> ~/.bashrc and you don't want to have overloaded execution of every bash script.)

I also work on Macs and Next which don't have a login shell. On other Unixes the login shell will already have been read, So I am used to having to get $PATH set by something and I don't want that in the script but something has to be read in e.g. using ~/.xonshrc etc,

👉 I think this is the key. Instead of describe your problem you try to change the xonsh behavior. Please describe how system where you want to use xonsh is working and what is the problem first.

from xonsh.

Moved to 5496

from xonsh.

Moved to 5496

from xonsh.

I see this in https://carapace-sh.github.io/carapace-bin/setup.html:

@bestlem are you happy that this code will be executed on every run of every script?
We have 100+ xontribs. Are they need to implement checking on interactive mode because they can be loaded in RC?

Personally Im not happy, but ok, let's live with this until facing with new information.

Maybe we can mitigate this by checking interactive mode in completer, history, prompt, xontrib-template, etc and do not load completers - #5495. It will be cool to work on this and report.

Maybe we need to have different path to init completions like in fish. But I don't like this path. If we want to keep interactive mode in mind we need to leave current behavior and checking it to make habit.

from xonsh.