Put your $HOME in .home!

Runiq · 2010-05-30 02:02:02

Yay, updates for my favourite package I'll try and actually hunt for bugs this time around…

Sloonz · 2010-05-30 11:34:00

New package on AUR : libetc-experimental-git (http://aur.archlinux.org/packages.php?ID=37676). I made a removal request for libetc-experimental.

Spacenick · 2010-05-30 20:00:55

Can someone tell me what would be the best way to switch to using XDG_CONFIG Home when I currently use the following python code: ("lotse" being the application name)
self.settingsdir = os.path.expanduser("~/.lotse")

Sloonz · 2010-05-30 22:31:01

The easy way is to use pyxdg.

Else, import user.home and try:

settingsdir = os.path.join(os.environ.get('XDG_CONFIG_HOME', os.path.join(user.home, '.config')), 'lotse')
but the existence of config home is not granted, so you should use os.makedirs()

And remember that xdg basedirs spec is not just "another place to put all the stuff generated with my app" ; you may want to distinguish between data, config and cache. There's a nice dev-oriented explanation here : http://ploum.frimouvy.org/?207-modify-y … dg-folders

Last edited by Sloonz (2010-05-30 22:48:15)

skanky · 2010-06-01 09:51:32

Sloonz wrote:

New package on AUR : libetc-experimental-git (http://aur.archlinux.org/packages.php?ID=37676). I made a removal request for libetc-experimental.

Thanks for this. I'll make the switch at some point this week, when I get a few minutes - need to update my profile for the new format.

venky80 · 2010-06-02 03:17:59

skanky wrote:

Sloonz wrote:
New package on AUR : libetc-experimental-git (http://aur.archlinux.org/packages.php?ID=37676). I made a removal request for libetc-experimental.
Thanks for this. I'll make the switch at some point this week, when I get a few minutes - need to update my profile for the new format.

would this automatically clean all the folders?

skanky · 2010-06-02 11:32:05

Not unless the new version adds that.
You have to move any existing files first, as this just redirects the reference to the files.

Sloonz · 2010-06-02 19:39:14

For those having already installed the git version : I found a potential segmentation fault (in really particular cases though, I noticed it only by re-reading my code). I just pushed a fix, so you can update to fix the bug you probably have not noticed

Last edited by Sloonz (2010-06-02 19:44:36)

Acheron · 2010-06-03 17:19:10

I'm interested in trying the git version, as I've been running libetc-experimental, but the build fails. Any ideas as to how I can fix this?

==> Starting build()...
Already up-to-date.
gcc -march=i686 -mtune=generic -O2 -pipe -DXAUTH_HACK -Wall -g -O2 -shared -fPIC -Wl,-soname,libetc.so.0 -o libetc.so.0.4 libetc.c -ldl -lc
In file included from libetc.c:59:0:
rewrite.c:147:1: error: conflicting types for 'truncate64'
/usr/include/unistd.h:1019:12: note: previous declaration of 'truncate64' was here
make: *** [libetc.so.0.4] Error 1
==> ERROR: Build Failed.

Sloonz · 2010-06-03 18:27:01

Should be fixed now

Last edited by Sloonz (2010-06-03 21:04:35)

Acheron · 2010-06-04 16:18:51

Thanks for fixing that, it builds properly now. Now on to some questions I've had since before the git-version but neglected to ask.

I can't determine why, but Comix doesn't seem to deal well with libetc. It should be saving its configuration in .local/share/ along with other software that works properly (like Audacious), but whenever I start it, the program says that there are deprecated config files left from an earlier version (from when it stored its data in .comix), and acts like this is the first time the program has been run. If I watch the directory I have set as XDG_CONFIG_HOME as I run the software, I see the "translated" .comix directory get created and subsequently deleted when I click yes to the prompt asking for the deprecated files to be removed. I've tried adding it to LIBETC_BLACKLIST and LIBETC_IGNORE as well, which doesn't seem to help, though I am not completely confident that I'm doing this correctly. I assume this originates with this particular piece of software, but I'm confused as to why I can't fix it through use of the blacklist or ignore.

Similarly, this seems to just be a conflict between the way Chromium and libetc run, but Chromium doesn't execute properly when running libetc unless one disables the sandbox. I've been running an outdated Chromium built from the AUR to avoid this. This has been noted elsewhere on the forum, and doesn't seem to be affected by blacklisting or ignoring (though again, I am not certain I'm actually blacklisting programs in the correct way).

Sloonz · 2010-06-04 17:52:48

For comix, you can't use LIBETC_BLACKLIST since comix is a python program (/proc/self/exe = /usr/bin/python, and you probably don't want to blacklist python, right). But in my local installation, LIBETC_IGNORE=.comix solves the problem.

For chromium, I noticed the problem some months ago, but I thought that my recent changes would have solved the it. It doesn't seems so, I'll investigate the problem this week-end.

Dieter@be · 2010-06-04 17:58:19

Some ideas:

* I don't like all the environment variables messing up my environment (and bashrc/xinitrc/..) . why not just let it read its config from files like $XDG_CONFIG_HOME/libetc/{config,data,cache} ? or 1 file that contains all (see point 3)
* if you decide to fork, call it 'forcexdg'
* user controllable mappings. in a "from ... to" format. like:

SomeApp/SomeAppConfiguration.xml   $XDG_CONFIG_HOME/someapp/config.xml
SomeApp/SomeAppData/data           $XDG_DATA_HOME/someapp/data
SomeApp/SomeAppData/.temporarydata $XDG_CACHE_HOME/someapp/tmp
.someappcache                      $XDG_CACHE_HOME/someapp/cache

because some apps are really messy. and this gives total control to the user what to route where.
* if the source ("bad") file/directory exists and the target ("good") doesn't, then automatically move it before letting the app read from/write to it.

Last edited by Dieter@be (2010-06-04 18:00:40)

Sloonz · 2010-06-05 10:51:54

Dieter@be wrote:

* I don't like all the environment variables messing up my environment (and bashrc/xinitrc/..) . why not just let it read its config from files like $XDG_CONFIG_HOME/libetc/{config,data,cache} ? or 1 file that contains all (see point 3)
* if you decide to fork, call it 'forcexdg'

Good ideas, I'll probably do this

Dieter@be wrote:

* user controllable mappings. in a "from ... to" format. like:
SomeApp/SomeAppConfiguration.xml   $XDG_CONFIG_HOME/someapp/config.xml
SomeApp/SomeAppData/data           $XDG_DATA_HOME/someapp/data
SomeApp/SomeAppData/.temporarydata $XDG_CACHE_HOME/someapp/tmp
.someappcache                      $XDG_CACHE_HOME/someapp/cache
because some apps are really messy. and this gives total control to the user what to route where.

Don't think I'll implement this. Right now, libetc takes into account that the original file MUST begin with $HOME/. to make a lot of simplifying assumptions (both for code simplicity and performances). There's some small handful assumptions like this that simplify the code that would turn false when implementing this. The resulting software would be different enough to justify a whole new project.

Dieter@be wrote:

* if the source ("bad") file/directory exists and the target ("good") doesn't, then automatically move it before letting the app read from/write to it.

Don't think it's a good idea either :
* The « workflow » of setting up libetc is : I run libetc, and then I set LIBETC_* variables for some particular cases. With this solutions, you will break these « special cases » the first time you run libetc. For example, it will move your .zshrc to .config/zshrc, and if you run libetc only in a graphical environment, you will be doomed next time you switch to a console.
* In a general case, I don't think that opening a file in read-only mode (just for example, that also apply for stat(), readlink()…) should perform a FS modification. In fact, I don't think libetc should call anything more than the original system call.
* Have you ever read the source code of GNU mv ? moving files is not as trivial as it seems.

Dieter@be · 2010-06-05 11:04:52

Sloonz wrote:

Dieter@be wrote:
* user controllable mappings. in a "from ... to" format. like:
SomeApp/SomeAppConfiguration.xml   $XDG_CONFIG_HOME/someapp/config.xml
SomeApp/SomeAppData/data           $XDG_DATA_HOME/someapp/data
SomeApp/SomeAppData/.temporarydata $XDG_CACHE_HOME/someapp/tmp
.someappcache                      $XDG_CACHE_HOME/someapp/cache
because some apps are really messy. and this gives total control to the user what to route where.
Don't think I'll implement this. Right now, libetc takes into account that the original file MUST begin with $HOME/. to make a lot of simplifying assumptions (both for code simplicity and performances). There's some small handful assumptions like this that simplify the code that would turn false when implementing this. The resulting software would be different enough to justify a whole new project.

Yes, this is quite a different approach. However, the way i see it is that the "from" values (in my column 1) are by definition subdirectories/files in your home, so they actually mean $HOME/SomeApp/... and so on.

Sloonz wrote:

Dieter@be wrote:
* if the source ("bad") file/directory exists and the target ("good") doesn't, then automatically move it before letting the app read from/write to it.
Don't think it's a good idea either :
* The « workflow » of setting up libetc is : I run libetc, and then I set LIBETC_* variables for some particular cases. With this solutions, you will break these « special cases » the first time you run libetc. For example, it will move your .zshrc to .config/zshrc, and if you run libetc only in a graphical environment, you will be doomed next time you switch to a console.
* In a general case, I don't think that opening a file in read-only mode (just for example, that also apply for stat(), readlink()…) should perform a FS modification. In fact, I don't think libetc should call anything more than the original system call.
* Have you ever read the source code of GNU mv ? moving files is not as trivial as it seems.

No, i haven't read the mv source code. But maybe you could reuse mv instead of reimplementing it. Anyway I was just thinking out loud. I'm not even sure myself whether this point is a good idea.

rwd · 2010-06-05 15:31:08

Does using libetc mean that all dotfiles, including .cache , .local and .xinitrc etc, need to be moved move to .config?

r6 · 2010-06-05 15:42:25

I still sometimes get a ~/.viminfo file with libetc, and vimperator is disagreeing for some reason, but overall it's great, I feel much more organised. If only programmers could agree on a standard name for the main configuration file. It's hard for me to remember, is it muttrc? mutt.rc? config? rc?

Acheron · 2010-06-05 16:10:52

Sloonz wrote:

For comix, you can't use LIBETC_BLACKLIST since comix is a python program (/proc/self/exe = /usr/bin/python, and you probably don't want to blacklist python, right). But in my local installation, LIBETC_IGNORE=.comix solves the problem.

While that explains why blacklisting didn't work, I tried just putting .comix in LIBETC_IGNORE and it only partially fixed the problem. I still get the prompt about deprecated files every time I start the program, but if I select no to deleting it, then my preferences are stored, though .comix still shows up as comix in my $XDG_CONFIG_HOME directory, and not as ~/.comix which is what I would expect with it added to LIBETC_IGNORE.

skanky · 2010-06-05 19:26:16

Sloonz wrote:

Dieter@be wrote:
* I don't like all the environment variables messing up my environment (and bashrc/xinitrc/..) . why not just let it read its config from files like $XDG_CONFIG_HOME/libetc/{config,data,cache} ? or 1 file that contains all (see point 3)
* if you decide to fork, call it 'forcexdg'
Good ideas, I'll probably do this

How will the first one affect performance? Will it have to read the config files every time it's used?
The reason why I ask is because when I switched to the the new git version, the first app call I made after I had removed the earlier version, I got an error that it couldn't find the libetc.so file. This made me think that the bash variables will be being read every time.

NB I haven't read the source code, so apologies if it's a stupid question.

Sloonz · 2010-06-05 21:45:40

Dieter@be wrote:

Yes, this is quite a different approach. However, the way i see it is that the "from" values (in my column 1) are by definition subdirectories/files in your home, so they actually mean $HOME/SomeApp/... and so on.

You're right
But IMO, an application which writes in your home, in visible files, without asking you is broken. Do you think of any concrete application which behave like "SomeApp" ?
I'll see the implications of this features when you first idea will be implemented

rwd wrote:

Does using libetc mean that all dotfiles, including .cache , .local and .xinitrc etc, need to be moved move to .config?

Yes, except :
* $XDG_CACHE_DIR (.cache by default) and $XDG_DATA_DIR (.local/share)
* files explicitly blacklisted in $LIBETC_IGNORE
* files used by applications explicitly blacklisted in $LIBETC_BLACKLIST

r6 wrote:

I still sometimes get a ~/.viminfo file with libetc,

Me too, but that's because I sometimes run vim under a non-X environnment, and I have put LD_PRELOAD in my .xsession. Perhaps that's your problem too.

r6 wrote:

and vimperator is disagreeing for some reason

Do you have an error message ?

Acheron wrote:

While that explains why blacklisting didn't work, I tried just putting .comix in LIBETC_IGNORE and it only partially fixed the problem. I still get the prompt about deprecated files every time I start the program, but if I select no to deleting it, then my preferences are stored, though .comix still shows up as comix in my $XDG_CONFIG_HOME directory, and not as ~/.comix which is what I would expect with it added to LIBETC_IGNORE.

Very strange. Are you sure that LD_PRELOAD= ls ~/.comix says that no files exists ?

skanky wrote:

How will the first one affect performance? Will it have to read the config files every time it's used?

libetc is reloaded each time a program is loaded into memory, in the same way that libc, libgtk… is loaded whenever an application that link it is loaded — that's how LD_PRELOAD works
I don't think it will affect performance.

tonyisnt · 2010-06-05 23:11:08

I'm in the middle of a complete reinstall and decided to give this libetc a try. I like the idea of it, and I like it. But I seem to be having a problem; maybe someone can help me out?

Some things are going into .config/ without a problem, but others keep popping up in ~ and I don't know why.

I have the following in .xsession and .bashrc:

export LD_PRELOAD=libetc.so.0
export LIBETC_BLACKLIST=/bin/ls:/bin/mv:/bin/cp:/bin/ln:/usr/bin/find:/bin/rm
export LIBETC_IGNORE:.fonts:.icons:.themes

Everything seemed to be working until I started to install/configure my graphical stuff.

Right now, here is a list of all the dot-files in ~:
.cache/
.config/
.dbus/
.fontconfig/
.fonts/
.gconf/
.gconfd/
.icons/
.local/
.mozilla/
.themes/
.thumbnails/
.bash_history
.bash_profile
.bashrc
.dmrc
.gtkrc-2.0
.nvidia-settings-rc
.recently-used.xbel
.xinitrc
.xsession
.xsession-errors
.xsession-errors.old

I think I missed something rather obvious, but I'm not positive. Help?

Acheron · 2010-06-06 02:25:07

Sloonz wrote:

Very strange. Are you sure that LD_PRELOAD= ls ~/.comix says that no files exists ?

LD_PRELOAD=ls ~/.comix 
-bash: /home/XXXX/.comix: is a directory

But using a file manager or console, I can't see or access this directory, and one called comix still appears in my XDG_CONFIG_HOME directory.

I have to admit that I don't understand why having .comix ignored works on your local installation in the first place. Are you running a version of Comix older than 4.0.3, where the config would be stored in .comix as opposed to (by default) .local/share/comix?

Sloonz · 2010-06-06 08:36:35

Acheron wrote:

Sloonz wrote:
Very strange. Are you sure that LD_PRELOAD= ls ~/.comix says that no files exists ?
I have to admit that I don't understand why having .comix ignored works on your local installation in the first place. Are you running a version of Comix older than 4.0.3, where the config would be stored in .comix as opposed to (by default) .local/share/comix?

I have comix 4.0.4-3
When I just run "comix", I have the message "there are deprecated files on your computer"

LD_PRELOAD= ls ~/.comix says "no such file or directory"

And if I run LIBETC_IGNORE=.comix comix, I don't have the "there are deprecated files on your computer anymore". This message is here because comix is doing something like this :

if(exists(~/.comix)) message("there are deprecated files")

libetc translates $home/.comix to $home/.config/comix, which exists (has been created by comix). So comix thinks that ~/.comix exists and display the message. That's why LIBETC_IGNORE=.comix should fix the issue, and indeeds does for me. Are you sure you are using libetc-experimental-git ? There's no LIBETC_IGNORE in libetc-0.4

tonyisnt wrote:

…

1. You have to move your old dot-files manually, libetc doesn't do it for you
2. There's a typo in your LIBETC_IGNORE line (LIBETC_IGNORE: instead of LIBETC_IGNORE= )
3. .x* files are… awful. They change between display managers. If I remember well, gdm doesn't call .xsession by default, for example (but slim does). Try deleting LD_PRELOAD from .bashrc and see if you have a LD_PRELOAD exported in graphical environment. If you don't, here's the problem.
My advice would be to put the environment variables in .bash_profile instead of .bashrc + .xsession, if you are willing to enable libetc in a non-X environment.

Just remember to keep a symlink for .bash_profile and .bashrc both in .config and home, or put .bashrc:.bash_profile in LIBETC_IGNORE

tonyisnt · 2010-06-06 17:16:47

Sloonz wrote:

1. You have to move your old dot-files manually, libetc doesn't do it for you

That's the thing: this is a fresh install. None of those files were there beforehand.

3. .x* files are… awful. They change between display managers. If I remember well, gdm doesn't call .xsession by default, for example (but slim does). Try deleting LD_PRELOAD from .bashrc and see if you have a LD_PRELOAD exported in graphical environment. If you don't, here's the problem.
My advice would be to put the environment variables in .bash_profile instead of .bashrc + .xsession, if you are willing to enable libetc in a non-X environment.

You're right in that I get nothing from an 'echo $LD_PRELOAD' when in Openbox (but I do in a console). I followed your advice and put the lines in .bash_profile instead, but it doesn't seem to have made any difference.

This is .bash_profile in its entirety.

export LD_PRELOAD=libetc.so.0
export LIBETC_BLACKLIST=/bin/ls:/bin/mv:/bin/cp:/bin/ln:/usr/bin/find:/bin/rm
export LIBETC_IGNORE=.bash_profile:.bashrc:.xsession:.xinitrc:.fonts:.icons:.themes
. $HOME/.bashrc

I still feel like I've overlooked something important, but I don't have any idea what.

Sloonz · 2010-06-06 17:47:51

What's the parent of openbox in pstree ?

Arch Linux

#76 2010-05-30 02:02:02

Re: Put your $HOME in .home!

#77 2010-05-30 11:34:00

Re: Put your $HOME in .home!

#78 2010-05-30 20:00:55

Re: Put your $HOME in .home!

#79 2010-05-30 22:31:01

Re: Put your $HOME in .home!

#80 2010-06-01 09:51:32

Re: Put your $HOME in .home!

#81 2010-06-02 03:17:59

Re: Put your $HOME in .home!

#82 2010-06-02 11:32:05

Re: Put your $HOME in .home!

#83 2010-06-02 19:39:14

Re: Put your $HOME in .home!

#84 2010-06-03 17:19:10

Re: Put your $HOME in .home!

#85 2010-06-03 18:27:01

Re: Put your $HOME in .home!

#86 2010-06-04 16:18:51

Re: Put your $HOME in .home!

#87 2010-06-04 17:52:48

Re: Put your $HOME in .home!

#88 2010-06-04 17:58:19

Re: Put your $HOME in .home!

#89 2010-06-05 10:51:54

Re: Put your $HOME in .home!

#90 2010-06-05 11:04:52

Re: Put your $HOME in .home!

#91 2010-06-05 15:31:08

Re: Put your $HOME in .home!

#92 2010-06-05 15:42:25

Re: Put your $HOME in .home!

#93 2010-06-05 16:10:52

Re: Put your $HOME in .home!

#94 2010-06-05 19:26:16

Re: Put your $HOME in .home!

#95 2010-06-05 21:45:40

Re: Put your $HOME in .home!

#96 2010-06-05 23:11:08

Re: Put your $HOME in .home!

#97 2010-06-06 02:25:07

Re: Put your $HOME in .home!

#98 2010-06-06 08:36:35

Re: Put your $HOME in .home!

#99 2010-06-06 17:16:47

Re: Put your $HOME in .home!

#100 2010-06-06 17:47:51

Re: Put your $HOME in .home!

Board footer