On Fri, Oct 18, 2013 at 10:34 AM, Manolo Martínez
<manolo_AT_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
Received on Fri Oct 18 2013 - 11:49:49 CEST