On Mon, Dec 05, 2011 at 06:28:59PM +0100, Matthias Lederhofer wrote: > 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)
Well, not necessarily, ksh for example does not export PWD. > > 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. Hmmmm I have a feeling actually this may be why I have cd $HOME in my .profile, I can't remember... > > > 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. Yes, I think they need to be squashed so we only have default-path and PWD which is treated precisely (aside from checking it is useful before sending to server) like all other variables. > > > - 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. I'm not wild about using PWD because it is a shell thing, but tmux can be a shell so I suppose it makes some sense. I think having it updated on every attach may be a good idea, certainly it would be nice if that could be controlled through update-environment. > > > - 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. > Well, to be more precise, the global environment is set from the client which starts tmux and that is used for ALL sessions, including the first one. So all sessions are the same, modulo update-environment. We have to set the global environment up somehow, either copying from the first client or starting empty. The point is that if we copy the whole environment into the session environment for new sessions, the hierarchy of global environment < session environment is lost. > > 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). Yes, unless it is configured that way with update-environment or whatever. > > > 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
