mainThe GNU Bourne-Again SHell - Support: sr #108134, Use XDG dirs instead of $HOME

 
 

sr #108134: Use XDG dirs instead of $HOME

Submitter:  Oliver Propst <oliverp>
Submitted:  Sun 16 Sep 2012 11:11:47 AM UTC
Votes: 501
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Postponed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 14 Nov 2024 07:53:21 PM UTC, comment #38: 

On 11/12/24 11:10 PM, cpli wrote:

> Follow-up Comment #37, sr #108134 (group bash):
>
> with an available patchset planned to land in a future version, shouldn't the
> req's status be changed to in-progress?


When I start working on it, it will.

Chet Ramey <chet>
Group administrator
Wed 13 Nov 2024 04:10:12 AM UTC, comment #37: 

with an available patchset planned to land in a future version, shouldn't the req's status be changed to in-progress?

cpli <cpli>
Mon 16 Sep 2024 02:16:50 PM UTC, comment #36: 

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

Chet Ramey <chet>
Group administrator
Sat 14 Sep 2024 08:32:52 PM UTC, comment #35: 

New commenter to this post. Does the patch work? Can it be implemented? It would be great to see this for all the reasons in the original comment and as the current paths are still prioritized and it actually resolves existing technical debt rather than creating new debt as was explained by someone before it's hard to understand why it hasn't been accepted. If the patch isn't acceptable could the maintainers submit feedback so that it could be improved.

Anonymous
Wed 21 Aug 2024 03:25:46 PM UTC, comment #34: 

No update.

Chet Ramey <chet>
Group administrator
Mon 19 Aug 2024 11:08:09 AM UTC, comment #33: 

Any news on this ?

Anonymous
Mon 29 Jan 2024 12:03:04 PM UTC, comment #32: 

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,

90 <ninety>
Sun 21 Jan 2024 07:16:32 PM UTC, comment #31: 


> Usually it's nice to keep things together in a program-specific directory
> within $XDG_CONFIG_HOME, such as bash/bash_profile and bash/bashrc, but apart
> from that I'm stoked that you're willing to make it happen in the end.


Sorry, that was my mistake, typing too quickly. The files would go into
$XDG_CONFIG_HOME/bash.

Chet Ramey <chet>
Group administrator
Sun 21 Jan 2024 12:57:33 AM UTC, comment #30: 

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)

Anonymous
Fri 19 Jan 2024 11:59:12 PM UTC, comment #29: 

I really apologise for this many successive posts and have been spoiled by forums and issue trackers with post editing functionality, but the last point I forgot to address is that the fish shell implements XDG base dir support by default and uses the $XDG_CONFIG_HOME/fish directory to store its configuration.

Anonymous
Fri 19 Jan 2024 11:56:23 PM UTC, comment #28: 


> 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.

Anonymous
Fri 19 Jan 2024 11:53:24 PM UTC, comment #27: 

Usually it's nice to keep things together in a program-specific directory within $XDG_CONFIG_HOME, such as bash/bash_profile and bash/bashrc, but apart from that I'm stoked that you're willing to make it happen in the end.

While this would be out of my comfort zone given my relative inexperience with C, I'd be happy to even try patching it in myself and contributing it to help expedite the process. Would it be fine to attach a git .patch for it on this thread in that event?

Anonymous
Fri 19 Jan 2024 10:01:41 PM UTC, comment #26: 


> 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.

Chet Ramey <chet>
Group administrator
Fri 19 Jan 2024 09:53:20 PM UTC, comment #25: 


> If not, simply make a fresh bash_profile, still under the legacy path if desired.


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


> It might be worth also pointing out that the behaviour I'm describing isn't particularly new to GNU software


It's not GNU software per se; there aren't any shells out there that I've seen implement this. zsh comes closest with ZDOTDIR.

Chet Ramey <chet>
Group administrator
Sat 13 Jan 2024 08:50:01 PM UTC, comment #24: 

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.

Anonymous
Thu 11 Jan 2024 08:18:15 AM UTC, comment #23: 

Exactly. If $HOME/.bash_profile is not present, see if $XDG_CONFIG_HOME/bash/bash_profile / $HOME/.config/bash/bash_profile is present instead and use that if so. If not, simply make a fresh bash_profile, still under the legacy path if desired.

This way, the user can count on Bash to allow them to keep their $HOME as cleanly organised as possible, given the option.

Anonymous
Wed 10 Jan 2024 03:15:14 PM UTC, comment #22: 

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?

Chet Ramey <chet>
Group administrator
Wed 10 Jan 2024 10:35:47 AM UTC, comment #21: 

But how does that address the location of .bash_profile and other files like .bash_logout? The issue was never just about the location of .bashrc.

Anonymous
Tue 09 Jan 2024 04:25:03 PM UTC, comment #20: 

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.

Chet Ramey <chet>
Group administrator
Thu 04 Jan 2024 12:35:17 AM UTC, comment #19: 

I believe the assumption is supposed to be that they don't have to be set as the defaults of $HOME/.config and the like are part of the spec, with the variables specified in case a user wishes to point them to a non-standard location.

To reiterate, what I am suggesting is that Bash may optionally search for a $HOME/.config/bash/bash_profile or equivalent (rather, $XDG_CONFIG_HOME/bash/bash_profile first before the fallback) if the default $HOME/.bash_profile isn't present, and that this would be the case for any of the files Bash uses for login sessions, interactive sessions, logout etc.

Anonymous
Tue 02 Jan 2024 09:26:16 PM UTC, comment #18: 

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.

Chet Ramey <chet>
Group administrator
Fri 29 Dec 2023 04:00:57 PM UTC, comment #17: 

That would also be a perfectly fine compromise if it allows effectively "emulating" XDG compliance.

However, my only worry would be the potential requirement of super user permissions needing to set this in a root-level/system directory and script. The compromise I outlined earlier would effectively be a way to ensure compliant behaviour even for users who don't necessarily have superuser permissions.

Anonymous
Wed 27 Dec 2023 09:42:42 PM UTC, comment #16: 

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.

Chet Ramey <chet>
Group administrator
Fri 22 Dec 2023 03:51:23 PM UTC, comment #15: 

If the worry is about changing "what Bash has done since day 0" of creating the relevant .bashrc/_profile files under $HOME, then I would like to propose the following compromise:

- Let Bash continue to generate its files under $HOME upon initial launch, so as not to disrupt existing expectations for most users.
- HOWEVER, allow and support these files to be moved to the respective XDG-compliant paths (mainly $XDG_CONFIG_HOME/bash/... or $HOME/.config/bash/..., maybe $XDG_STATE_HOME for the history file) and merely document that this is an option users may take if they so choose to.

This way, Bash may continue to prioritise the legacy paths if they exist, but also check for the existence of the same relevant configuration files under the XDG path and use those if the files are not present under their legacy paths.

Would these terms be acceptable, and would you be happy to accept any patches implementing this?

Anonymous
Fri 22 Dec 2023 10:21:02 AM UTC, comment #14: 

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

Anonymous
Mon 23 Oct 2023 08:20:52 PM UTC, comment #13: 

1. New users only, maybe. There's no reason to expect bash to do something it's never done and isn't documented as doing.

2. "Better" is in the eye of the beholder, I suppose. As I think I stated in a previous comment, there's no compelling reason to change what bash has done since day 0.

Chet Ramey <chet>
Group administrator
Sat 21 Oct 2023 01:33:50 AM UTC, comment #12: 

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.

Anonymous
Thu 24 Nov 2022 02:50:46 PM UTC, comment #11: 


> There's no reason to change historical behavior here.  All the world is not Linux.


I think nobody said to enforce said behaviour or said it something that applies to Linux only.

An option would be:
1. Enable it only when requested during build.
2. Enable it on all platforms using XDG but prefer the regular path first.
3. Prefer the XDG path on XDG-platforms then load the regular
4. Add a even variable that allows to change the location of bashrc and friends.

4. isn't as nice however there are also other uses cases to do so.




Anonymous
Thu 17 Nov 2022 10:34:14 AM UTC, comment #10: 

"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.

Archer <archer>
Sun 16 Oct 2022 09:48:44 AM UTC, comment #9: 

There was a patch to implement this from 2014:
https://lists.gnu.org/archive/html/bug-readline/2014-03/msg00054.html

It doesn't seem to have been accepted.

Anonymous
Sat 27 Aug 2022 07:36:27 PM UTC, comment #8: 

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.

Anonymous
Wed 17 Aug 2022 09:44:39 PM UTC, comment #7: 

1. Here's my two cents. Hosting or version controlling configuration files becomes dead simple when everything is in XDG_CONFIG_HOME. No symlink hell. Oh, and easy to omit cache that isn't essential when it's time for backups / disk cleaning.

2. I'm compelled to argue towards the opposite. Not following this standard will continue to create edge-cases that have to be accounted for by every user that attempts to interact with bash but knows about the XDG base directory spec.

gabrielhansson <gibbz>
Mon 25 Jul 2022 02:22:54 PM UTC, 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

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

Chet Ramey <chet>
Group administrator
Sat 23 Jul 2022 01:13:25 PM UTC, comment #5: 

What about just adding support for it, simply add an option to enable support for XDG dirs.



BWKC <bwkc>
Wed 12 Oct 2016 03:25:05 AM UTC, comment #4: 

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

Chris <cseelus>
Fri 13 Nov 2015 02:36:20 AM UTC, comment #3: 

There's no reason to change historical behavior here.  All the world is not Linux.

Chet Ramey <chet>
Group administrator
Sat 05 Jan 2013 09:24:33 AM UTC, comment #2: 

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.

Eric Heintzmann <eheintzmann>
Wed 21 Nov 2012 12:32:53 PM UTC, comment #1: 
  • ping
FaisPas <faispasierch>
Sun 16 Sep 2012 11:11:47 AM UTC, original submission:  

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

Oliver Propst <oliverp>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55594:  XDGbasedir.patch added by None (4KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by cpli (Posted a comment)
  • -email is unavailable- added by cpli (Voted in favor of this item)
  • -email is unavailable- added by rpetrov (Voted in favor of this item)
  • -email is unavailable- added by ninety (Posted a comment)
  • -email is unavailable- added by archer (Posted a comment)
  • -email is unavailable- added by gibbz (Posted a comment)
  • -email is unavailable- added by bwkc (Posted a comment)
  • -email is unavailable- added by whenov (Voted in favor of this item)
  • -email is unavailable- added by dfrankcom (Voted in favor of this item)
  • -email is unavailable- added by k41eb (Voted in favor of this item)
  • -email is unavailable- added by hannavasung
  • -email is unavailable- added by adrianheine (Voted in favor of this item)
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by eheintzmann (Posted a comment)
  • -email is unavailable- added by faispasierch (Posted a comment)
  • -email is unavailable- added by oliverp (Submitted the item)
  •  

    There are 501 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-11-13 cpli Carbon-Copy- Added cpli
    2024-02-03 rpetrov Carbon-Copy- Added rpetrov
    2024-01-21 None Attached File- Added XDGbasedir.patch, #55594
    2024-01-19 chet StatusWont Do Postponed
    2023-12-29 cseelus Carbon-CopyRemoved cseelus -
    2023-12-29 cseelus Carbon-CopyRemoved 106174 -
    2021-12-24 whenov Carbon-Copy- Added whenov
    2020-09-12 dfrankcom Carbon-Copy- Added dfrankcom
    2019-12-08 k41eb Carbon-Copy- Added k41eb
    2017-09-19 hannavasung Carbon-Copy- Added hannavasung
    2017-02-08 adrianheine Carbon-Copy- Added adrianheine
    2016-10-12 cseelus Carbon-Copy- Added cseelus
    2015-11-13 chet StatusNone Wont Do

    Back to the top

    Powered by Savane 3.14-f13d.
    Corresponding source code