Config file .dataprinter can be a symbolic link #34

wants to merge 1 commit into


None yet
4 participants

bessarabov commented Sep 12, 2012

I'm was using old version of Data::Printer for a long time and it worked

Yesterday I've decided to update DDP to the latest version (witch is 0.33).
I've installed in on my machine but when I run the script that was using DDP I
got the error:

rc file '/home/bessarabov/.dataprinter' doesn't look like a plain file. Skipping.

I switched back to the previous version of DDP and started discovering. I've
found that this is because my file ~/.dataprinter is a symbolic link. This
logic was added to the lib/Data/ file in commit 47b61b2 Thu Feb 23
03:15:52 2012 -0200.

Now I will try to explaing why I need the ~/.dataprinter to be a symbolic
link. I have several computers where I work. It is a work notebook with
ubuntu, personal ubuntu notebook and a several servers. I work mostly in
terminal and some time ago I've understood that I need some system that will
help me to store all my configuration files (dot files) to be in order. I want
to have possobility to change some config file and it will change on all other
computers. I had several attempts to solve this problem and finally I've found
the solutin. I have a git repository that lives on all my computers in ~/felix
It containg all my configuration files and a script that creates symbolic
links from the files in that directory to my home directory. This system work
perfectly - I'm getting new server - I log in, clone git repository with my
configs, run one small script, logout and after loggin in again I have all my
usual environment.

My system for managing config files is called felix and it lives at

I'm syncing .dataprinter across all my computers with felix, but the new
version of DDP does not allow .dataprinter to be a symbolic link and because
of it I can't sync .dataprinter.

Here is a fix that allows .dataprinter to be a symbolic link. I really hope
that you will accept it.

Thank you for reading such a long text =)


sdt commented Sep 13, 2012

You can set a custom .dataprinter file location with the DATAPRINTERRC environment variable

export DATAPRINTERRC=~/felix/.dataprinter

bessarabov commented Sep 13, 2012

Thank you, Stephen!

Yes, this is a solution. I've did it and now DDP is working. But I think this
is a hack and the better solution is to allow symbolic link as a .dataprinter

+1 to merge this patch.


bessarabov commented Feb 16, 2013

I've rebased the patch on top of master. I sill think that this patch is correct and it Data::Printer will become better after applying it.


garu commented Feb 17, 2013

Hey guys, thanks for the patch and all the input, and sorry for taking such a long time to reply (for some reason I missed a lot of reports, maybe they weren't being properly forwarded to my email, not sure).

Stephen is right. Though the main goal of $ENV{DATAPRINTERRC} was letting people specify a different path than $HOMEDIR, it lets you simply set a system-wide RC file so you don't have to spread symlinks all around. If you add "DATAPRINTERRC=/home/felix/dataprinterrc" to your "/etc/environment", for example, this should go away transparently.

That being said, I can understand you and matsunosan wanting this merge - having symbolic links to your rc file can be very helpful. I have, however, a lot of concerns about .dataprinterrc from a security point of view, mostly because it's perl code in userspace being potentially loaded by any program. You'd assume Data::Printer is a debugging tool and no one would leave it in production code, but I found out it's not the case all the time, and some people use it to debug live code. I haven't really had the time to sit through the question, but I think about turning to Config::Tiny or Config::General or whatever all the time, just so I can sleep better at night - but it would prevent the creation of small filters in .dataprinter (which, of course, are perl subs), which is something I find useful as well.

So, right now what I'm doing is pondering on the effective difference between reading from a symlink and reading from %ENV from a security standpoint. They both scare me, but it might be so that if one's being allowed, there's little reason for the other not to be allowed as well. But it's 3am here now and I want to make sure I'm very much awake when I make this kind of call :-)

If you have any other comments on the issue, I'm all ears! Either way, I promise to update this pull request real soon. Thanks!


bessarabov commented Feb 17, 2013

Thank you for the explanation, now you position is clear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment