Talk:Bash

From ArchWiki

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 /etc/profile and bashrc file. Wget (talk) 20:18, 25 August 2013 (UTC)

Doesn't really belong here. --Dettalk 11:37, 25 April 2014 (UTC)
Certainly, but as the question is not really answered, I'd suggest to move this discussion into Talk:Bash. The snippet is probably from some content recently removed from this page, but this should not matter. -- Lahwaacz (talk) 21:17, 25 April 2014 (UTC)
Agreed, moved here as suggested. -- Kynikos (talk) 03:18, 26 April 2014 (UTC)
From [1]:
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 [2]:
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 .bashrc files in Arch Linux. Either way, it is clear that non-interactive shells do source configuration files under some circumstances. Questions:
  1. What is the "special compile time option" for ssh sessions?
  2. If files specified in BASH_ENV do not use PATH, what is then used? A default? The current directory?
  3. Does a non-interactive login shell also source files in BASH_ENV besides .profile & co. ?
-- Alad (talk) 14:21, 16 August 2015 (UTC)

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 /etc/profile does.

Jamespharvey20 (talk) 09:31, 12 October 2018 (UTC)

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/bash.bashrc from /etc/profile. -- Lahwaacz (talk) 13:47, 12 October 2018 (UTC)

~/.bash_aliases suggestion

Flagged to add ~/.bash_aliases file as suggestion, but after some thought not so sure any more as my /etc/skel/.bashrc does not have:

if [ -f ~/.bash_aliases ]; then
   . ~/.bash_aliases
fi

I have it in my ~/.bashrc but maybe I added it there a while ago and forgot about it.. --Cvlc (talk) 21:45, 19 December 2021 (UTC)

Looking at the files and PKGBUILD at https://github.com/archlinux/svntogit-packages/tree/packages/bash/trunk it is your /etc/skel/.bash_profile that should have the content you describe. --Erus Iluvatar (talk) 06:13, 20 December 2021 (UTC)
Well looking at it I only see .bahrc being linked there, not .bash_aliases --Cvlc (talk) 14:29, 20 December 2021 (UTC)
I should have read more carefully, you're right. Sorry for my mistake. We might still want to add a sentence about using a specific file for aliases and the fact that some distributions have been using a specific name for it ? --Erus Iluvatar (talk) 17:00, 20 December 2021 (UTC)
I've changed the section to explain how it works. The file name is arbitrary, anyone can come up with their own. — Lahwaacz (talk) 20:08, 20 December 2021 (UTC)
Thanks. Tried to find some specification for this but couldn't find any. --Cvlc (talk) 01:46, 21 December 2021 (UTC)
This looks like it's been closed by Cvlc. --Erus Iluvatar (talk) 13:23, 24 June 2022 (UTC)