On Fri, Oct 18, 2013 at 10:34 AM, Manolo Martínez <man...@austrohungaro.com> wrote: >> Secondly, you never make it clear *who's* working directory you want to read. >> Do you always want to be in dwm's working directory? The working directory >> from >> the environment you are currently in (which may not be the same as dwm's)? > > I meant the current user's (i.e., my) working directory. What "echo > $PWD" shows.
That'd be the pwd of the shell that currently has the keyboard focus, not the pwd of dwm. (the problem is: there is no such thing as “the user's working directory”. Working directories are associated to processes, not people. >> >> Also, urxvt(c) does not change the current working directory on launch, >> anyway. >> You can see this quite easily by launching an urxvt instance, and then doing >> `cd / && urxvt`. The new instance will have / as its current working >> directory. > > I actually knew that, and it puzzles me. In my config.h I have the following > line: > > static const char *termcmd[] = { "urxvt", NULL }; > > Which always launches a terminal in /home/manolo, regardless of what my > current pwd is. Well /home/manolo is in fact the pwd of dwm. And because dwm starts the shell, the shell is started in /home/manolo. I guess what you want is the pwd of the client that currently has focus… I also need something like that for plumb(1)ing purposes (relative file paths not resolving correctly otherwise). I didn't manage to juice that out of xprop/xwininfo, WMNET properties and procfs. Cheers, -- ______________ Raphaël Proust