You are not logged in.
... like many others do? (see github) Yes, but it does not solve the problem. You will still have a cluttered home, either will version-controlled config files or with links to version-controlled config files, so that your programs will function! I do both (moved my home to a folder called dotfiles AND made it a git repo so I can manage it more efficiently and effectively). And as far as I am concerned, configuration is also data since I invested some time on it and I don't want to lose it. I backup my configuration alongside my data!
Last edited by tzervo (2010-02-28 06:49:13)
Offline
I tried to send a bug report to irssi but it was rejected as "not going to be implemented" and got scolded that it has been suggested before and should have searched for it, *pft*. That is how willing the developers are to do the right thing.
Last edited by lordmetroid (2010-02-28 10:47:35)
Offline
(…) I added a $LIBETC_IGNORE variable as well, and it seems to be working:
It's not yet tested, though. I'll suggest it to the maintainer of the AUR libetc package tomorrow. Have fun with this if you want to, took me the better part of an afternoon.
Edit: Thanks, Barrucadu, for making something awesome even awesomer.
Looks nice
I'll apply it on my machine tomorrow (today is not a good day for breaking anything), and if nothings breaks until monday i'll add it in the package and re-try to contact upstream maintainer (unfortunately, he didn't reply to my previous mail for the firefox 3.5 fix, so don't expect a quick 0.5…)
Offline
Looks nice
I'll apply it on my machine tomorrow (today is not a good day for breaking anything), and if nothings breaks until monday i'll add it in the package and re-try to contact upstream maintainer (unfortunately, he didn't reply to my previous mail for the firefox 3.5 fix, so don't expect a quick 0.5…)
Are you the maintainer of libetc in the AUR? Good to hear from you, thanks for notifying upstream!
Last edited by Runiq (2010-03-02 19:18:23)
Offline
Yes, sorry for having used another nick on aur and the forum, that's just a mistake
EDIT: renamed my AUR account to avoid mistakes
Last edited by Sloonz (2010-03-02 19:28:17)
Offline
Thanks for this to Barrucadu Runiq & Sloonz.
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
Oops, sorry, I forgot this thread…
@Runiq
I can't apply your patch (indentation problems; your text editor probably has modified indentation before you made the diff), can you send me your full libetc.c please ? (you can have my mail in the libetc PKGBUILD) Thanks in advance
Offline
@Runiq
I can't apply your patch (indentation problems; your text editor probably has modified indentation before you made the diff), can you send me your full libetc.c please?
Done.
Offline
> Done.
Thanks
After some basic tests, I won't apply it on a minor release of the AUR package; it breaks backwards compatibility (before the patch: they search in $HOME/.local/share/foo, are redirected to $HOME/.config/local/share/foo, and are happy ; now, they search in $HOME/.local/share/foo, are no longer redirected and are not happy anymore). That's trivial for the user to fix (mv $HOME/.config/local $HOME/.local) but I prefer to put a notice "important change since libetc 0.5", not "important change between libetc 0.4-2 and libetc 0.4-3" — I'm sure you understand that
I also fixed two minor problems introduced by this patch:
- memleaks in translate() and am_i_in_list()
- no longer thread-safe
I can make a project on github if anyone is interested.
What's next ?
This patch is really useful for me (it helps a lot with the backup system I installed yesterday). I'll continue to run with it for one week and fix possible problems. After that, I'll contact upstream for inclusion. If upstream doesn't responds before the end of the month (or says: I don't want to maintain it anymore), I'll fork and publish libetc 0.5 with this patch included.
Offline
> Done.
Thanks
You're welcome!
After some basic tests, I won't apply it on a minor release of the AUR package; it breaks backwards compatibility (before the patch: they search in $HOME/.local/share/foo, are redirected to $HOME/.config/local/share/foo, and are happy ; now, they search in $HOME/.local/share/foo, are no longer redirected and are not happy anymore). That's trivial for the user to fix (mv $HOME/.config/local $HOME/.local) but I prefer to put a notice "important change since libetc 0.5", not "important change between libetc 0.4-2 and libetc 0.4-3" — I'm sure you understand that
I also fixed two minor problems introduced by this patch:
- memleaks in translate() and am_i_in_list()
- no longer thread-safe
I can make a project on github if anyone is interested.
Awesome. I didn't look at the patch's internals, and I didn't even notice that.
What's next ?
This patch is really useful for me (it helps a lot with the backup system I installed yesterday). I'll continue to run with it for one week and fix possible problems. After that, I'll contact upstream for inclusion. If upstream doesn't responds before the end of the month (or says: I don't want to maintain it anymore), I'll fork and publish libetc 0.5 with this patch included.
Sounds awesome too, looking forward to any updates
Offline
Sounds ideal. Many thanks.
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
I created a libetc-experimental package with this patch: http://aur.archlinux.org/packages.php?ID=35473
If you test it, please indicate it here or (exclusive or) vote for it, so I can have a reasonable indication of how many people tested it without problems (of course, if you have problems, please inform me in this thread, or by mail)
Last edited by Sloonz (2010-03-15 07:34:27)
Offline
I've installed it - just need to sort out the dotfiles. Will post here how I get on.
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
How did I miss this thread? I tried libetc a while back and even emailed the author requesting the exact feature this patch provides! I didn't get a response though. This community is awesome!
Offline
I changed my $HOME to .home a while ago. What are the advantages of using libetc instead of just changing it in /etc/passwd?
Offline
VERY good idea
Offline
Well, I for one use $HOME in several scripts. Also, with the recently added patches to libetc, you have a bit more fine-grained control over where your config files go than by changing $HOME, and you can basically mimic (part of) the XDG basedir specification for all/most/a lot of config files. Have a look at libetc-experimental if you're interested.
Offline
I'm playing with libetc-experimental and I just have a couple of questions -
1) To use the functionality provided by Barrucadu, do I need to specify the files in the variables stated? Do I include the . in the name listed there?
2) This one probably applies to libetc before this patch. The directory .rss2email is still being created in $HOME. Is does libetc not deal with .directories or is it configuration, or maybe foldder specific.
The libetc page talks about a few files that can't be moved, including the .zshrc. Should I be linking .bashrc, .xinitrc, .Xauthority, etc. ?
Bonus question there, I was having a 3 for 2 day
Last edited by skanky (2010-03-15 21:35:20)
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
@skanky
1) It depends on how the program does "call" its own configuration file. I suggest you to make both (LIBETC_CACHE=".program:$HOME/.program". I have this in my .zprofile:
set_libetc_cache() {
local cache_files
cache_files=(.dbus .dvdcss ..qt .recently-used .recently-used.xbel .SciTE.session .sqlite_history .viminfo)
LIBETC_CACHE=
for f in $cache_files; do
LIBETC_CACHE="$LIBETC_CACHE:$f:$HOME/$f"
done
export LIBETC_CACHE=$LIBETC_CACHE[2,$]
}
set_libetc_cache
2)
How is launched rss2email ? Are you sure that LD_PRELOAD and HOME are correctly set ? (if it's launched with cron, LD_PRELOAD will probably not be set)
bonus)
For files that can't be moved : it all depends where you did put LD_PRELOAD=libetc.so. General rule: programs launched before setting LD_PRELOAD= will search their config file in $HOME (captain obvious is here ). So, if you put LD_PRELOAD=libetc.so in your .xinitrc (as I did), you must keep .xinitrc in your HOME.
For .Xauthority, this special file is automatically handled by libetc since version 0.4 (before, it was an horrible pain). Let libetc manage it
EDIT: forgot to tell you: I just sent a mail to libetc maintainer. Now, let's wait & see…
Last edited by Sloonz (2010-03-21 12:46:03)
Offline
@Sloonz - many thanks. I'll readdress these questions early this week and post back here. No other issues so far though.
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
Okay, aside of some LD_PRELOAD conflicts with scrotwm (I've switched to dwm for now), I've set this up on my newly installed Arch work machine and it's working very well. The dmenu cache seemed to be being ignored - but that may be a config setting. Does it pick-up wildcard globbing?
Anyway, I've added it to .bash_profile as I don't always run X. I've added three functions based on Sloonz's that set-up the Ignore, Cache and Data variables based on equivalent files in the .config/libetc folder. It means I can add an entry by doing:
echo .entry >> ~/.config/libetc/[cache|ignore|data]
I'll switch this (home) netbook to the same set-up when I've either fixed the scrotwm issue, or worked out dwm.
EDIT:
Found an issue where it's not ignoring a file in a subdirectory, eg .log/getmail.log is not being found by getmail, even though I have that file in the ignore list. Same result if I divert it using LIBETC_DATA. Is there an issue with dot folders?
Note, I've not got rss2email on that machine, so I don't know if this setup'll fix that.
Last edited by skanky (2010-03-23 22:25:07)
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
Okay, some odd behaviour. It took me a couple of hours to work this one out.
If I set
export LIBETC_DATA=""
then libetc tried to access any dotfile in ~/.local/share that is the $XDG_DATA_HOME folder.
It *seems* to work if LIBETC_DATA is set to have a value, or if it isn't set at all. However I'm going to have to use the system for a bit to make sure that's the whole story, as I ended up messing quite a bit up pinpointing this issue.
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
> Found an issue where it's not ignoring a file in a subdirectory, eg .log/getmail.log is not being found by getmail, even though I have that file in the ignore list. Same result if I divert it using LIBETC_DATA. Is there an issue with dot folders?
I never had a similar issue, and i have only folders in my .cache. Can you reproduce it with other applications ? With command line tools (ls, cat) ?
> Okay, some odd behaviour. It took me a couple of hours to work this one out.
I had a similar issue ; I thought my fix would fix this one too — I must have been wrong. I'll look at this ASAP (which has few chances to mean «soon», unfortunately)
Offline
> Found an issue where it's not ignoring a file in a subdirectory, eg .log/getmail.log is not being found by getmail, even though I have that file in the ignore list. Same result if I divert it using LIBETC_DATA. Is there an issue with dot folders?
I never had a similar issue, and i have only folders in my .cache. Can you reproduce it with other applications ? With command line tools (ls, cat) ?
All blacklisted tools will find anything - but only in its correct place. I believe this is correct?
Now I've resolved the DATA issue (below) I'll try again. TBH I'm not sure where to put these logs so I've been happy enough with my workaround for now that I forgot to try and work on this some more. I will have another go - not sure when atm.
> Okay, some odd behaviour. It took me a couple of hours to work this one out.
I had a similar issue ; I thought my fix would fix this one too — I must have been wrong. I'll look at this ASAP (which has few chances to mean «soon», unfortunately)
It only seems to occur if the LIBETC_DATA variable gets set and is set to empty - which is odd. By avoiding setting it when it's empty, the problem seems to vanish. So no urgency on this on my part (to be selfish about it).
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
Okay, some news :
- I did set up a github repo: http://github.com/sloonz/libetc
- upstream still doesn't respond to my mails. I'll try to find him by other ways, and if I can't, I'll fork (release a 0.5).
- there's some news in this github : a lot of code cleanup. In particular, libetc now computes the absolute file path in translate() (and now, translate() is readable ) ; it makes it more reliable, but now the old trick (using "$HOME/./.foo" to access a real ~/.foo bypassing libetc) will not work anymore. Great news is that now LIBETC_{CACHE|DATA|IGNORE} is _really_ more predictable ; it must be set to the dotfile (see the reade) relative to HOME (e.g. LIBETC_CACHE=".fontconfig:.zhistory"). And the strange issues where everything goes to XDG_CACHE_HOME should be fixed.
I just finished to hack this "feature" minutes ago, so I may have introduced some bugs I haven't still noticed. Please test and spam me if you find bugs !
I'll update the libetc-experimental package tomorrow. It's late here, time to sleep
Last edited by Sloonz (2010-05-29 22:48:53)
Offline