corriander / dotfiles-env Goto Github PK

I could really do with offloading my content into separate files to make it truly drop in with no concern. Add a bootstrap.sh to allow me to source these in the default files automagically. Also, currently I believe bash_logout is untouched, for one.

I can keep my config in $XDG_CONFIG_HOME and leave the default files untouched. This means I won't be cluttering $HOME with my files. Also, this may well make it easier to make settings system-dependent. Also see a nice tidy approach

See /etc/skel for the defaults.

Further: .profile, .bashrc and .bash_profile are not recommended for env vars any more, with preference for .pam_environment (I think this is because this is available to all applications rather than just those launched via BASH).

• .pam_environment uses a special, non-shell syntax (note the need for braced variables).
• Beware potential issues.

Never really bothered with functions in the shell, but might be a good idea to have a .bin, .scripts and .functions trinity.

I'm starting to see value in a couple of extra features I decided to be conservative about:

• Job count
• VCSH integration

I'm toying with an indicator for the last exit status code, but I'm not sold on the idea yet. The two above though I am starting to miss.

Unity configuration might be better off in its own repo if it gets any more involved than this. Currently the desktop files need manual placement so they do no harm if pulled, but if I want to chuck any compiz settings etc here, scripts and so on it'll all be very Unity specific and possibly not super-compatible between Ubuntu releases.

I currently have my git identity in ~/.gitidentity (not in this repo). I should really move this to $XDG_CONFIG_HOME a-la the proposals for BASH configs.

add_to_path () in .profile has a basic implementation to allow appending to the PATH variable rather than prepending.

1. The only path which should take precedence is probably .local/bin for overrides. The rest should be ok appended to just make things slightly more secure. Implement this (currently not using the second argument to add_to_path () at all.
2. [Optional] Make the implementation a case statement rather than if?
3. Might need to think of some way of ensuring I don't trip myself up here, perhaps ensuring I don't put similarly name-clash executables outside of .local/bin?

Retire .profile for purposes of env vars and use .pam_environment as per recommendations.

Naked vchs is not not really suited to documents in the work tree root like README.md or LICENSE. Root of the work tree here is $HOME, so we don't want these appearing there because:

1. They don't make sense out of context of the repo.
2. Even if their presence is tolerated, they would clobber any other vchs repo docs.

For now, I've tucked them away in the $XDG_DATA_HOME tree, but this obscures them (and sort of defeats the point of them existing). There are various potential solutions to this issue:

1. Forget about them. Don't bother documenting, it's only a dotfile repo.
2. Figure out some way of unpacking them on Github, but keeping them tucked away during checkout. Possible methods:

• vcsh hooks?
• git attributes / filters?

Current .profile contains some bashisms which are preventing add_to_path () from working as expected. Needs fixing.