Ubuntu

savedir option doesn't work as expected

Reported by Francis Giraldeau on 2008-02-26
14
Affects Status Importance Assigned to Milestone
Tux Paint
Unknown
Unknown
tuxpaint (Debian)
Fix Released
Unknown
tuxpaint (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: tuxpaint

tuxpaint has the option "savedir" to change the directory where drawings are saved. When the option is put on the command line, it works, but it doesn't work when the option is defined in the configuration file. It happens when "~" is included in the path. Here is an example :

 tuxpaint --savedir ~/tmp

But when place in the config file /etc/tuxpaint/tuxpaint.conf :

 savedir=~/tmp

I got the following error :

Error: Can't create user data directory:
~/tmp
The error that occurred was:
No such file or directory

Thanks for your bug!

Which version of tuxpaint are you using - and which version of Ubuntu?

Thanks!

Caroline Ford (secretlondon) wrote :

new ->incomplete

Changed in tuxpaint:
status: New → Incomplete

The bug is present in tuxpaint_0.9.16 (feisty), but also in tuxpaint_0.9.17 (gutsy,hardy)

I attach a patch that resolv the issue, by expanding the "~" in the path.

Caroline Ford (secretlondon) wrote :

confirming and sending upstream

Changed in tuxpaint:
status: Incomplete → Confirmed
Caroline Ford (secretlondon) wrote :

Upstream bug merged in with a feature request.

Changed in tuxpaint:
assignee: nobody → warp10
status: Confirmed → In Progress
Andrea Colangelo (warp10) wrote :

I built a debdiff based on Francis patch. It works fine for me.
Looks like debian is not aware of this issue: I'm reporting a bug on their BTS too.

Changed in tuxpaint:
assignee: warp10 → nobody
importance: Undecided → Medium
status: In Progress → Confirmed
Changed in tuxpaint:
status: Unknown → New
Daniel Holbach (dholbach) wrote :

Oliver: could you please take a look at it?

After a research on the topic, I found that gnulibc has a function to substitute the environment variables of a string : wordexp

http://www.opengroup.org/onlinepubs/009695399/functions/wordexp.html

But this POSIX function is not available in MinGW, which is used for the compilation of tuxpaint for Windows.

From : http://www.gnu.org/software/gnulib/manual/html_node/wordexp.html

===

Portability problems not fixed by Gnulib:

    * This function is missing on some platforms: MacOS X 10.3, OpenBSD 3.8, Cygwin, mingw, Interix 3.5, BeOS.

===

So, I did update the patch with #ifdef __linux__, to make sure that other plateform are not affected.

Changed in tuxpaint:
assignee: nobody → warp10
status: Confirmed → In Progress
Andrea Colangelo (warp10) wrote :

Francis, I tried your new patch, but it doesn't work for me. May you check it, please?

Changed in tuxpaint:
assignee: warp10 → nobody
status: In Progress → Triaged
Bruno Barrera Yever (bbyever) wrote :

It doesnt work for me either.

Oliver Grawert (ogra) wrote :

can you confirm that the very first patch worked ?

I did retest the patch and I do have the correct behavior.

I did change the setting in the file /etc/tuxpaint/tuxpaint.conf (and $HOME/.tuxpaintrc is working too) :

savedir=$HOME/tmp/test-tuxpaint4

 or

savedir=~/tmp/test-tuxpaint4

Both are working.

Andrea and Bruno, I would like to know how you did the test, because something seems different. Packages are available in my PPA.

https://edge.launchpad.net/~francis-giraldeau/+archive

Ogra : the first patch shouldn't be used, since it doesn't handle environment variables, it only expands "~" for the home directory.

Oliver Grawert (ogra) wrote :

well, i'm not really convinceed that we should use wordexp (especially not at that state of release). how about the patch andrea made up ? does that one work ? (it introduces dpatch in a package not using a patch system though, that would need to be changed to be just a debdiff)

Bruno Barrera Yever (bbyever) wrote :

Francis: I applied your patch again and it did work. Maybe it didnt work the first time because i also applied your first patch.

Steve Langasek (vorlon) wrote :

I'm surprised by this bug report, because the "bug" is the normal, expected behavior for almost all Unix applications: home directory expansion is supported on the commandline because this is implemented by the shell, but it's not supported in config files.

While I can see the advantages of supporting ~ expansion in config files, I don't believe this is something that it's beneficial to diverge from upstream on (and I definitely don't think this warrants a FeatureFreeze exception). Could you get this patch approved by upstream first?

The problem is that in the config file, there is an example of savedir option with "~" expansion, and that was not working at the time.

I confirm that the problem is fixed in Intrepid tuxpaint-0.9.20-2ubuntu1. Shell variables are not yet replaced, but at least "~" expansion is working. I will see with upstream for the next step.

Change status to Fix Released.

Changed in tuxpaint:
status: Triaged → Fix Released
Changed in tuxpaint (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.