It's still on the roadmap for a future version.

No update.

Just in case you haven't seen it, I've been registered for a couple of days now and have re-submitted that earlier patch here to the appropriate section under patch #10431. If there are any other concerns with this so far please let me know,

Well, after some testing with a custom Arch PKGBUILD, I've managed to do it. I'm attaching a formatted patch adding the discussed XDG fall-backs for all of .bash_profile, .bash_login, .bashrc and .bash_logout. While their legacy paths are still prioritised to not subvert existing expectations, they all now have the option to be moved to an $XDG_CONFIG_HOME/bash directory without needing to be dotfiles.

The only one that does not have such a fall-back defined for it is .bash_history due to the need to preserve the existing HISTFILE default. Ideally, this would have been migrated to something like $XDG_STATE_HOME/bash/history, however users are free to set this as their HISTFILE if they so choose to.

All in all, I hope that this contribution is to your liking and that you may consider it for inclusion in a future Bash release.

(file #55594)

> I don't get this part of the discussion; bash doesn't `make' any startup files.

I might have been somewhat confused in that case by the fact that Arch Linux packages for bash automatically copy the templates for bash_profile and bashrc upon installation. At least, every time I've set up an Arch or derivative system, I've immediately found those files present within $HOME.

> Emacs also takes exactly this approach of using $XDG_CONFIG_HOME/emacs/init.el as a fallback

I can see adding something like the emacs behavior in a future version of bash.

Use $XDG_CONFIG_HOME/bash_profile and $XDG_CONFIG_HOME/bashrc.
I'm not sure about changing .bash_logout, since you can already do what you want using an exit trap you set for login shells, but maybe a fallback in the absence of ~/.bash_logout would be ok.

It might be worth also pointing out that the behaviour I'm describing isn't particularly new to GNU software; According to the Arch wiki, Emacs also takes exactly this approach of using $XDG_CONFIG_HOME/emacs/init.el as a fallback, while still prioritising legacy $HOME/.emacs(.d) paths and not necessarily creating the directory for the former option.

The idea is that you have a fixed filename that you can count on for login shell startups, but you have the flexibility to put the per-interactive-shell startup file wherever you want (without specifying it at invocation), like $BASH_HISTORY allows you to specify the location of the history file.

So the idea is to add an additional fallback filename in case the multiple current filename candidates are not present? For each of the bash-specific startup files and .bash_logout?

I'm not going to add one fixed path to replace or supplement another fixed path; that's nothing but cosmetics.

I think the $BASHRC approach is more useful and general.

You can set this hypothetical variable in .bash_profile and export it. That should get you through most interactive use cases.

slogin already runs a login shell, so setting and exporting it in .bash_profile would work for this case.

You can pass the variable and value over an ssh connection if you want ssh to source the .bashrc file, but that's non-default behavior.

Setting the XDG_ variables has the same issue as setting BASHRC; XDG_CONFIG_HOME et al aren't set by default on the random RHEL box I just tested.

How about something like BASHRC, a shell variable whose value would be the name of the interactive shell startup file to execute. That would allow users to put the file wherever they want, and name it whatever they want. It would still be overridden by --rcfile and --init-file. If unset, bash would use its historical behavior. If null, bash wouldn't source a startup file in an interactive shell. This parallels $ENV/$BASH_ENV.

"We need to keep using old dated dotfiles instead of a sane spec because... BECAUSE WE JUST DO OKAY?"

comment #6:

> Because someone has to add that support, which leads to two reasons:
>
> 1. No one has ever been able to articulate a compelling reason
>    for adding this that doesn't ultimately come down to circular
>    reasoning; and

The reason is simply the Principle of Least Astonishment. A user expects that their choice of $XDG_CONFIG_HOME will be respected.

>
> 2. It adds technical debt that has to be carried.
>

Technical debt is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time. Therefore, the debt has already been incurred.

It's time to pay up.

"All the world is not linux" is an understatement. XDG base spec also supports BSD, as well as mac. Throwing everything in root home directory is never a well thought idea. It doesn't change the fact & not even worth arguing over.

Hello, I'd like this feature too (supporting moving configuration files to a user-specified directory). My goal is to organize my home directory and centralize all user configuration in a single directory that's not hidden (doesn't start with a dot). I expect to reduce my home directory by almost 70 files and keep only 2 dozen directories in it, none of them being hidden files.

Because someone has to add that support, which leads to two reasons:

1. No one has ever been able to articulate a compelling reason
   for adding this that doesn't ultimately come down to circular
   reasoning; and

2. It adds technical debt that has to be carried.

The Bourne-Again Shell is sadly one of the few software tools still not implementing the  XDG Base Directory Specification: https://wiki.archlinux.org/index.php/XDG_Base_Directory_support

According to XDG Base directory specification,
user preferences should go into $XDG_CONFIG_HOME (which default to ~/.config)
and cached data should go to $XDG_CACHE_HOME (which default to ~/.cache).
More details at :
http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
https://live.gnome.org/GnomeGoals/XDGConfigFolders

Full specification can be found at:
http://standards.freedesktop.org/basedir-spec/latest/

The Freedesktop.org XDG base directory specification have good de facto adoption.
It has been adopted by:
- GNOME ( https://live.gnome.org/GnomeGoals/XDGConfigFolders )
- GTK+ ( https://bugzilla.gnome.org/show_bug.cgi?id=646631 )
- KDE ( http://techbase.kde.org/KDE_System_Administration/XDG_Filesystem_Hierarchy#Freedesktop.org_and_Standard_Directories )
- QT ( http://harmattan-dev.nokia.com/docs/library/html/qt4/qsettings.html#setPath )
- XFCE ( http://docs.xfce.org/xfce/xfce4-session/advanced in Files and Environment Variables )
- LXDE
- Razor-qt
- VLC ( https://trac.videolan.org/vlc/ticket/1267 )
- GStreamer ( https://bugzilla.gnome.org/show_bug.cgi?id=518597 )
- Chrome ( http://code.google.com/p/chromium/issues/detail?id=16976 )
- many more upstream applications
- Ubuntu ( http://brainstorm.ubuntu.com/idea/6557/ & http://packages.ubuntu.com/fr/source/precise/libxdg-basedir )
- Debian ( http://packages.debian.org/squeeze/libxdg-basedir1 )
- Red Hat
- Fedora
- Suse
- many more distributions

I think that bash should use same locations than the vast majority of Desktop environment and applications.


There are real advantages of following this specification :
- a lot less cluttered $HOME
- Make backups a lot more safer and easier.
  Backuping your $XDG_DATA_HOME along with your files is enough
  (or just excluding $XDG_CACHE_HOME)
- A lot easier to reset a default configuration if you want/need it (and
  without any risk to loose informations). Even for the software itself
  could choose to reset $XDG_CONFIG_HOME if needed.
- Avoid some strange bugs that happens because you had a old version of
  some configuration file
- A lot more of flexibility and portability because no path are hardcoded.

Bash stores ~/.bash_aliases , ~/.bash_history, ~/.bash_logout and ~/.bashrc in the home directory. It would be better to store these files according to the XDG Base Directory Specification.

https://live.gnome.org/GnomeGoals/XDGConfigFolders
http://standards.freedesktop.org/basedir-spec/latest/ar01s02.html