Nicholas Marriott <nicholas.marri...@gmail.com> wrote:
> I'm not really convinced by all the PWD talk, the canonical way to find
> the current working directory is to call getcwd(). Not to use PWD, that
> is just a shell convenience. I don't think applications should ever need
> to check PWD rather than calling getcwd(). They might not even be run
> from a shell.
>
> AFAICT getcwd() does not collapse symlinks, so I'm not sure what your
> issue is... I can't actually reproduce your original problem. If I do:
For a while I thought that OpenBSD would handle directories and
symlinks differently from Linux but I installed OpenBSD and it is the
same.
It seems the pwd binary (/bin/pwd) does not consider $PWD. But all
the shells have it as a built-in and use it:
$ cd /tmp
$ mkdir a
$ ln -s a b; ln -s a c
$ cd b
$ /bin/pwd
/tmp/a
$ sh -c pwd
$ env PWD= sh -c pwd
/tmp/a
$ env PWD=/tmp/c sh -c pwd
/tmp/c
The kernel does not store (or tell you) how you got to your current
directory, i.e. which symlinks were used. That's what $PWD is for.
It's a convenience variable for shell users hiding the symlinks.
> $ pkill tmux
> $ tmux new
> <inside tmux>
> $ pwd
> /tmp/b
> $ pwd -P
> /tmp/a
>
> Am I doing something incorrect here?
Yes, you have to start the tmux server in another directory. If you
start it in /tmp/b it will have PWD=/tmp/b for all later sessions.
$ cd /tmp
$ tmux new -d
$ cd /tmp/b
$ tmux new 'env | grep ^PWD= ; read'
PWD=/tmp/a (in tmux)
The shell started by tmux cannot figure out the path including the
symlinks because PWD is pointing to /tmp when it is started. Simply
adding PWD to update-environment does not fix it as attaching from
another directory to a session will invalidate the value of $PWD.
I think tmux should ensure that the value of PWD is maintained as I
find it quite inconvenient if shells inside tmux expand the symlinks
in pwd as the prompt may get quite long and confusing.
> I did at one point consider just storing PWD in the tmux environment and
> dropping the various cwd members. Then whether or not it is updated
> would be entirely controlled by update-environment. This might be the
> best solution but still I think we should use getcwd() for the original
> working directory, not PWD. That is:
I also found that default-path and session->cwd is kind of redundant.
> - In the client, force PWD to getcwd() in the environment sent to the
> server.
I hope my point above makes clear why I think PWD should be used if it
points to the correct directory.
> - Add a comment marking the cwd part of the identify struct as unused
> and remove cwd from the session. It may need to stick around in the
> pane and window for respawning, in case the user has changed the
> environment. In fact, perhaps we should save the WHOLE environment for
> respawning.
>
> - Add PWD to update-environment by default.
In my opinion the cwd/PWD (whatever we name it) should be set by
default when creating a new session, not when attaching. Adding it to
update-environment would change the session directory on every attach.
> - Call chdir() to the value of PWD after fork or forkpty.
>
> Then the question of whether we update the working directory for new
> sessions or on attach or whatever is moot - it is handled by
> update-environment the same as everything else.
>
> >
> > Adding PWD to update-environ works for spawning new sessions but it will
> > break when attaching to an existing session from another path. New
> > windows in this session get the wrong $PWD.
> >
> > Additionally when setting the default-path the user has to set $PWD
> > manually too. And even then windows using remain-on-exit will get the
> > wrong $PWD when respawning. All this should be fixed with this patch.
>
> Respawning windows is supposed to recreate them in the same state as
> before (I know it doesn't really right now) so they shouldn't
> necessarily reflect any working directory changes.
Exactly, that's the reason why a window has to have its own value for
$PWD (or the whole environment). Otherwise it gets the wrong value
for $PWD.
> > Through all this I realised that tmux new will copy the whole
> > environment when no server is running yet. If a server is running
> > already only the update-environ variables are copied. I find this a bit
> > inconsistent that it makes a difference if a server is already running
> > or not. Wouldn't it make more sense to copy the whole environment for
> > every new session? For example CFLAGS="-Wall -W" tmux does set the
>
> Well, perhaps. But then you can't override parts of the environment.
>
> One idea when the environment stuff was added was to reverse the sense
> so the global environment overrides the session environment rather than
> vice versa, but that is inconsistent with options...
What do you mean by the last two paragraphs? I think every new
session should be the same, in the current implementation the first
session is special as the environment variables of this session are
used for all later sessions.
> This is an edge case but my feeling is that it is more intuitive for
> tmux to not change the session environment around under you except for
> some obvious, easily configurable cases like DISPLAY.
>
> Replacing the whole thing on attach has it's own problems. For example,
> what if you have two or three clients on the same session? When the
> session is created is the only time we are guaranteed there is only one
> source environment. Or what if I don't want it changed?
I really like the way update-environment is used to update sessions
when they are already running. Attaching to a session should in my
opinion not change the session state too much (i.e. cwd, the whole
environment or the like).
> A nice - and probably relatively easy - change here would be to make
> update-environment accept fnmatch() wildcards, so those who want the
> entire environment updated could just add "*" and those who wanted the
> entire environment removed add "-*".
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
