Bjartur Thorlacius | 1 Jan 2011 19:04
Picon

Re: [dmenu] Patch for XDG Base Directory specification of dmenu_path

On 12/30/10, Anselm R Garbe <garbeam <at> gmail.com> wrote:
> On 30 December 2010 20:47, Jon Raphaelson <jonraphaelson <at> gmail.com> wrote:
>> Attached is a patch to dmenu_path which (if enabled in the config.mk)
>> changes the cache file location to be XDG Base Directory Specification
>> compliant. After enabling the change, the cache file will live at
>> $XDG_CACHE_HOME/dmenu/path.cache (or $HOME/.cache/dmenu/path.cache if
>> $XDG_CACHE_HOME is not set), rather than in the home directory at
>> ~/.dmenu_cache.
>> This patch relies on libxdg-basedir [2] being installed.
>
> I think using some pseudo-directory standard and library to retrieve
> the location of a cache file is quite odd.
>
I think storing cache files under $HOME is even odder. $HOME is quite
often accessed over a network. Storing it under /var seems saner.

Anselm R Garbe | 1 Jan 2011 19:16
Picon
Favicon

Re: [dmenu] Patch for XDG Base Directory specification of dmenu_path

On Sat, Jan 01, 2011 at 06:04:45PM +0000, Bjartur Thorlacius wrote:
> On 12/30/10, Anselm R Garbe <garbeam <at> gmail.com> wrote:
> > On 30 December 2010 20:47, Jon Raphaelson <jonraphaelson <at> gmail.com> wrote:
> >> Attached is a patch to dmenu_path which (if enabled in the config.mk)
> >> changes the cache file location to be XDG Base Directory Specification
> >> compliant. After enabling the change, the cache file will live at
> >> $XDG_CACHE_HOME/dmenu/path.cache (or $HOME/.cache/dmenu/path.cache if
> >> $XDG_CACHE_HOME is not set), rather than in the home directory at
> >> ~/.dmenu_cache.
> >> This patch relies on libxdg-basedir [2] being installed.
> >
> > I think using some pseudo-directory standard and library to retrieve
> > the location of a cache file is quite odd.
> >
> I think storing cache files under $HOME is even odder. $HOME is quite
> often accessed over a network. Storing it under /var seems saner.

Or /tmp as it was in the earlier days.

-Anselm

Troels Henriksen | 2 Jan 2011 12:29
Picon
Gravatar

Re: [dmenu] Patch for XDG Base Directory specification of dmenu_path

Anselm R Garbe <anselm <at> garbe.us> writes:
> On Sat, Jan 01, 2011 at 06:04:45PM +0000, Bjartur Thorlacius wrote:
>> I think storing cache files under $HOME is even odder. $HOME is quite
>> often accessed over a network. Storing it under /var seems saner.
>
> Or /tmp as it was in the earlier days.

/tmp is wiped on system reboot, while you might like your dmenu cache to
live a little longer than that.

--

-- 
\  Troels
/\ Henriksen

Kurt H Maier | 2 Jan 2011 16:59
Picon
Gravatar

Re: [dmenu] Patch for XDG Base Directory specification of dmenu_path

On Sun, Jan 2, 2011 at 6:29 AM, Troels Henriksen <athas <at> sigkill.dk> wrote:
> Anselm R Garbe <anselm <at> garbe.us> writes:
>> On Sat, Jan 01, 2011 at 06:04:45PM +0000, Bjartur Thorlacius wrote:
>>> I think storing cache files under $HOME is even odder. $HOME is quite
>>> often accessed over a network. Storing it under /var seems saner.
>>
>> Or /tmp as it was in the earlier days.
>
> /tmp is wiped on system reboot, while you might like your dmenu cache to
> live a little longer than that.

1)  I go a pretty long time between reboots

2) /tmp is not always wiped on reboot -- that's distribution-specific.

--

-- 
# Kurt H Maier

Moritz Wilhelmy | 2 Jan 2011 17:01
Picon
Favicon

Re: [dmenu] Patch for XDG Base Directory specification of dmenu_path

Excerpts from Troels Henriksen's message of Sun Jan 02 12:29:19 +0100 2011:
> /tmp is wiped on system reboot, while you might like your dmenu cache to
> live a little longer than that.

Not necessarily.  This depends on your distribution.

A few examples:
Slackware doesn't purge it by default, debian iirc has an option somewhere,
archlinux empties /tmp completely.  I'm not very certain about other
distributions, but I think most of them purge it in default configuration.

According to hier(7) one can not even rely on /tmp being kept for the whole
uptime, while /var/tmp holds "temporary files for an unspecified duration",
whatever that means in practice.  At least no distribution known to me purges
/var/tmp/ on bootup per default.  Also note that simply purging everything in
/tmp via a cronjob as proposed by hier(7) is fatal for programs placing sockets
in it (screen, tmux) and running X11 sessions.

Maybe /var/tmp/ would be a better choice than /tmp?

Best regards,

Moritz

Ross Mohn | 2 Jan 2011 17:32
Favicon
Gravatar

Re: [dvtm] Graphics in madtty.c

Now I understand the mystery better. At home I do get the graphics (using HEAD), but not at work. And the reason is that at home I use en_US.utf8 while at work I'm stuck with AIX boxes that don't have that locale installed, just en_US. So, the UTF8 code within dvtm prints the actual UTF8 graphic characters while the non-UTF8 code within dvtm tries to use the ncurses settings, but then doesn't print using ncurses.

On the other hand, now that I've been prompted  to finally compile and try a version of st, I love it! And, this has probably already been discussed, but wouldn't it be more efficient to just write an optional patch to st that provides dvtm-like windowing capabilities? Is this already thought of for future?

-Ross


On 12/30/2010 03:29 PM, Niki Yoshiuchi wrote:
What version are you running? I was running 0.5.2 and just updated to HEAD, and that fixed the problem for me. It looks like your patch was added after version 0.6 so unless you are running against the HEAD of the repository you won't have the fix. Here I am running a nested instance: http://i.imgur.com/gc0Li.png On Thu, Dec 30, 2010 at 3:18 PM, Ross Mohn <rpmohn <at> waxandwane.org> wrote:
 Yes, I did add that patch, and it does indeed set the graphmode flag in dvtm, but it still prints 'lqj' rather than the graphic versions of them. I just tried st: graphics from st, but just 'lqj' from dvtm within st. Not sure what's going on now. :-/ On 12/30/2010 02:50 PM, Niki Yoshiuchi wrote:
The problem is with dvtm, specifically older versions.  dvtm 0.5.2 definitely has this problem and I know that the HEAD of the git repository does not.  According to the git log it was fixed by you: commit 163a07d5fb99f2b187e1da0f66084f14d6459626 Author: Marc Andre Tanner <mat <at> brain-dump.org> Date:   Fri Dec 17 21:01:33 2010 +0100     madtty: recognize set/clear graphmode with ESC(0, ESC(B     Based on a patch from Ross Mohn.     Signed-off-by: Marc Andre Tanner <mat <at> brain-dump.org> On Thu, Dec 30, 2010 at 11:06 AM, Aurélien Aptel <aurelien.aptel <at> gmail.com> wrote:
On Thu, Dec 30, 2010 at 1:50 AM, Ross Mohn <rpmohn <at> waxandwane.org> wrote:
Thanks for that! Yes, it also works in screen and tmux, but not dvtm. I'll slog through some tmux code and see about adding it to dvtm.
Sorry if I wasn't clear, but the line drawing characters are correctly displayed while using dvtm *inside* of st. Bottom line, there must be something wrong with your configuration.
Bjartur Thorlacius | 2 Jan 2011 18:01
Picon

Re: [dmenu] Patch for XDG Base Directory specification of dmenu_path

> Maybe /var/tmp/ would be a better choice than /tmp?
Or you know, /var/cache?
For sockets, /var/run, which is always wiped on boot, seems appropriate.

Bjartur Thorlacius | 2 Jan 2011 18:11
Picon

Re: [dmenu] Patch for XDG Base Directory specification of dmenu_path

Quoting <http://pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA>
> System programs that maintain transient UNIX-domain sockets must place them in this directory.
I don't even know what 'transient' means, but this seems to apply to X
IPC sockets.

On 1/2/11, Bjartur Thorlacius <svartman95 <at> gmail.com> wrote:
>> Maybe /var/tmp/ would be a better choice than /tmp?
> Or you know, /var/cache?
> For sockets, /var/run, which is always wiped on boot, seems appropriate.
>

Jacob Todd | 2 Jan 2011 18:23
Picon

Re: [dmenu] Patch for XDG Base Directory specification of dmenu_path

$home/tmp

anonymous | 2 Jan 2011 18:01

Re: [dmenu] Patch for XDG Base Directory specification of dmenu_path

On Sat, Jan 01, 2011 at 06:04:45PM +0000, Bjartur Thorlacius wrote:
> On 12/30/10, Anselm R Garbe <garbeam <at> gmail.com> wrote:
> > On 30 December 2010 20:47, Jon Raphaelson <jonraphaelson <at> gmail.com> wrote:
> >> Attached is a patch to dmenu_path which (if enabled in the config.mk)
> >> changes the cache file location to be XDG Base Directory Specification
> >> compliant. After enabling the change, the cache file will live at
> >> $XDG_CACHE_HOME/dmenu/path.cache (or $HOME/.cache/dmenu/path.cache if
> >> $XDG_CACHE_HOME is not set), rather than in the home directory at
> >> ~/.dmenu_cache.
> >> This patch relies on libxdg-basedir [2] being installed.
> >
> > I think using some pseudo-directory standard and library to retrieve
> > the location of a cache file is quite odd.
> >
> I think storing cache files under $HOME is even odder. $HOME is quite
> often accessed over a network. Storing it under /var seems saner.
> 
dmenu cache should be stored under $HOME because different users use
different $PATH.  In my .profile I set

export XDG_CONFIG_HOME="$HOME/etc"
export XDG_CACHE_HOME="$HOME/var/cache"

In dmenu_path.c I set

#define CACHE "var/cache/dmenu"

BTW under $HOME/lib I store various databases like browser bookmarks,
calendars and other things like that.


Gmane