Return in non interactive mode
[Moved from Talk:Color Bash Prompt#Return in non interactive mode -- Kynikos (talk) 03:18, 26 April 2014 (UTC)]
# This file is sourced by all *interactive* bash shells on startup, # including some apparently interactive shells such as scp and rcp # that can't tolerate any output. So make sure this doesn't display # anything or bad things will happen ! # Test for an interactive shell. There is no need to set anything # past this point for scp and rcp, and it's important to refrain from # outputting anything in those cases. # If not running interactively, don't do anything! [[ $- != *i* ]] && return
Some Linux distributions like ArchLinux actually distribute a bashrc with a statement like
[[ $- != *i* ]] && return included (see above). The comments say the bashrc script has to exit (return) because tools like scp are running in interactive mode and don't support having some user customizations, this is the reason why we have to return. But the return code actually returns if the script isn't run in interactive mode (
!= *i*), which is the contrary of what we want to achieve. Can anyone explain me that? Either the comments are incorrect or it is unneeded to use that return statement. But on IRC, some people agreed with me regarding this problem. And on the
#bash channel, some said the statement is unneeded because all scripts (which are all running in non-interactive mode) do not source ANY configuration files like
bashrc file. Wget (talk) 20:18, 25 August 2013 (UTC)
- From :
- Bash has a special compile time option that will cause it to source the .bashrc file on non-login, non-interactive ssh sessions. This feature is only enabled by certain OS vendors (mostly Linux distributions). It is not enabled in a default upstream Bash build, and (empirically) not on OpenBSD either.
- [...] Note that a test on SHLVL is also done, so if you do: ssh remotehost bash -c echo then the first bash will source .bashrc but not the second one (the explicit bash on the command line that runs echo).
- The behaviour of the bash patched to source a system level bashrc by some vendors is left as an exercise.
- (Emphasis mine; Arch sources a system-level bashrc).
- From :
- When Bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. [...] but the value of the PATH variable is not used to search for the filename.
- As noted above, if a non-interactive shell is invoked with the --login option, Bash attempts to read and execute commands from the login shell startup files.
- The above comment on scp was removed from
.bashrcfiles in Arch Linux. Either way, it is clear that non-interactive shells do source configuration files under some circumstances. Questions:
- What is the "special compile time option" for ssh sessions?
- If files specified in
BASH_ENVdo not use
PATH, what is then used? A default? The current directory?
- Does a non-interactive login shell also source files in
.profile& co. ?
- -- Alad (talk) 14:21, 16 August 2015 (UTC)
- From :
Chart: Login shells - /etc/bash.bashrc
The Configuration files chart lists that
/etc/bash.bashrc is not used for a login shell, but is used for an interactive non-login shell. If I'm understanding correctly, I think this is accurate for upstream bash. But, as the chart says under
/etc/profile, Arch has this source
/etc/bash.bashrc. As this page is about how bash functions under Arch, not upstream, doesn't this mean that
/etc/bash.bashrc should be listed as "Yes" for both login shells, and interactive non-login shells? If someone's focused at the green/red Yes/No's, this chart makes it look like
/etc/bash.bashrc won't be sourced by a login shell. I'd say just change it to "Yes", but it could be changed to "Yes (see note)" and another note could be added that although upstream bash doesn't source
/etc/bash.bashrc, Arch's default
- There is a difference between "sourced by a shell" and "sourced by a shell script". Documenting the latter does not make sense because you can add custom source commands to force sourcing all listed config files in all types of shells as well as remove the command sourcing
/etc/profile. -- Lahwaacz (talk) 13:47, 12 October 2018 (UTC)