Romain Francoise wrote:
> Hi Matthias,
>
> Matthias Lederhofer writes:
>
> > Is it easily possible to disable this feature for new sessions, i.e. by
> > putting something in the tmux.conf?
>
> I'm not sure what you're asking. If you want to disable the feature for
> any sessions created in you
Hi Matthias,
Matthias Lederhofer writes:
> Is it easily possible to disable this feature for new sessions, i.e. by
> putting something in the tmux.conf?
I'm not sure what you're asking. If you want to disable the feature for
any sessions created in your config file, then you can just set
defaul
Nicholas Marriott wrote:
> Thanks for this. The OpenBSD kernel bits are in so I've applied your
> diff with some minor tweaks and the required bits for osdep-openbsd.c.
I really like this feature, currently I'm using a shell function to
change the directory and additionally set the default-path.
Thanks for this. The OpenBSD kernel bits are in so I've applied your
diff with some minor tweaks and the required bits for osdep-openbsd.c.
Anyone wants to do AIX, Darwin, DFLY, HP/UX, or NetBSD send the code
:-).
On Tue, Dec 06, 2011 at 07:35:18PM +0100, Romain Francoise wrote:
> Nicholas Marr
This looks good apart from minor things, I'll take a better look later
today hopefully.
Thanks
On Tue, Dec 06, 2011 at 07:35:18PM +0100, Romain Francoise wrote:
> Nicholas Marriott writes:
>
> > Ok, so OpenBSD should have a way to do this soon, either a new
> > second-level sysctl KERN_PROC_CW
Romain Francoise wrote:
> +Set the default working directory for new processes. If empty (the
> +default), the working directory is determined dynamically from the
> +calling context: when called from keys or the command prompt the working
> +directory of the process living in the active window is
marcel partap writes:
> ..just for reference, from konsole/src/ProcessInfo.cpp, includes omitted:
> [...]
Thanks, that was useful.
--
Romain Francoise
http://people.debian.org/~rfrancoise/
--
Cloud Services Checklist
Nicholas Marriott writes:
> Ok, so OpenBSD should have a way to do this soon, either a new
> second-level sysctl KERN_PROC_CWD or a new third-level under
> KERN_PROC_ARGS. Don't worry about that though, let's move forward with
> your diff and I'll add OpenBSD when my code goes in.
Awesome, thank
Ok, so OpenBSD should have a way to do this soon, either a new
second-level sysctl KERN_PROC_CWD or a new third-level under
KERN_PROC_ARGS. Don't worry about that though, let's move forward with
your diff and I'll add OpenBSD when my code goes in. It's clear it can
be made to work on most platforms
Cool. So basically we need to implement KERN_PROC_CWD on OpenBSD,
although I don't think I would do it the way DragonFly does, I would
probably add a new level 3 sysctl like KERN_PROC_ARGS.
Lemme see if I have time to look at it this week.
On Mon, Dec 05, 2011 at 10:08:55AM +0100, marcel partap
..just for reference, from konsole/src/ProcessInfo.cpp, includes omitted:
> virtual bool LinuxProcessInfo::readCurrentDir(int pid)
> {
> QFileInfo info( QString("/proc/%1/cwd").arg(pid) );
>
> const bool readable = info.isReadable();
>
> if ( readable && info.isSymL
> On Sun, Dec 04, 2011 at 03:58:36PM +0100, Romain Francoise wrote:
>> I think I spoke too fast. KERN_FILE_BYPID only gives you the inode number
>> of the cwd and the mountpoint of the filesystem where it's located.
>
> Hm. That sucks... looks like getcwd() works by walking each vnode on
> the
Nicholas Marriott writes:
> Can we do this on ANY platform apart from Linux?
Solaris, with procfs. That's about it, I think.
--
Romain Francoise
http://people.debian.org/~rfrancoise/
--
All the data continuously gene
On Sun, Dec 04, 2011 at 03:58:36PM +0100, Romain Francoise wrote:
> I think I spoke too fast. KERN_FILE_BYPID only gives you the inode number
> of the cwd and the mountpoint of the filesystem where it's located.
Hm. That sucks... looks like getcwd() works by walking each vnode on
the way up to
I think I spoke too fast. KERN_FILE_BYPID only gives you the inode number
of the cwd and the mountpoint of the filesystem where it's located.
Finding the name of the directory from that requires walking the entire
filesystem, which is obviously out of the question...
So I guess we're back to squar
On Fri, Dec 02, 2011 at 12:13:29PM +0100, Romain Francoise wrote:
> Nicholas Marriott writes:
>
> > I think you can probably use sysctl KERN_FILE, KERN_FILE_BYPID and look
> > for KERN_FILE_CDIR in fd_fd on OpenBSD at least.
>
> Ah indeed, that's how fstat(1) does it. And it's even more permissi
Nicholas Marriott writes:
> I think you can probably use sysctl KERN_FILE, KERN_FILE_BYPID and look
> for KERN_FILE_CDIR in fd_fd on OpenBSD at least.
Ah indeed, that's how fstat(1) does it. And it's even more permissive than
on Linux because my non-privileged user can see the wd of all processe
Yeah it has to work on OpenBSD and preferably FreeBSD too.I think you
can probably use sysctl KERN_FILE, KERN_FILE_BYPID and look for
KERN_FILE_CDIR in fd_fd on OpenBSD at least.
I don't think we need a new option, why not make default-path default to
"" and override the automatic inheriting if it
I figured this would be controversial...
First some context: this was originally filed a wishlist request in the
Debian BTS. I replied that the only way to keep the cwd is to use the
client, and that achieving this from keys would involve non-portable ways
of getting the working directory and so w
I'm genuinely not delighted about more OS-dependent code. Is there no
portable solution to this? Even if it isn't quite as good.
Otherwise, what's the use case here? I love that you sent code but how
inconvenient is it to have more OS-dependent code verses the actual
issue? And how inconvenient th
Thomas Adam writes:
> Why, when this is in the tmux FAQ?
The "solution" in the FAQ is ugly.
--
Romain Francoise
http://people.debian.org/~rfrancoise/
--
All the data continuously generated in your IT infrastructure
On Wed, Nov 30, 2011 at 09:48:31PM +0100, Romain Francoise wrote:
> Hi,
>
> This patch adds a new session option 'inherit-default-path' and the
> associated machinery to create new windows/panes in the same working
> directory as the active window instead of using the value of default-path.
> It a
Hi,
This patch adds a new session option 'inherit-default-path' and the
associated machinery to create new windows/panes in the same working
directory as the active window instead of using the value of default-path.
It affects only windows created from keys or the command prompt.
Note that only L
23 matches
Mail list logo
