Preserving current working directory for new tabs

[Matt Hillsdon]

This is a feature of gnome-terminal, and perhaps others, that I rely on
more than I realized. I often get some way through assembling a command
line, realize I'm missing some piece of information, spawn a new tab,
find it out, close the new tab and carry on. This is much less painful
if the new tab starts in the current working directory of the tab you
were just in.

I've just implemented this in my embedding of Terminator in Eclipse.
This uses a small patch to the PtyProcess code to expose the process
id. I then use this in Java to find out the cwd from /proc/$pid/cwd. I
don't know a cross-platform way do this so this will only work on Linux
and whatever UNIX platforms support /proc.

Is this a feature you would be interested in for Terminator proper?
Even without cross-platform support? If so then I'd be happy to discuss
how best to implement it and come up with a patch. If not, please
consider applying the attached patch to just expose the pid. Please be
brutal about my C++/JNI (not that there's much of it), it's been a fair
while since I've written any C/C++ and this is my first JNI code.

Thanks,

Matt.

[Elliott Hughes]

On Sat, April 4, 2009 09:42, Matt Hillsdon wrote:
> This is a feature of gnome-terminal, and perhaps others, that I rely on
> more than I realized. I often get some way through assembling a command
> line, realize I'm missing some piece of information, spawn a new tab, find
> it out, close the new tab and carry on. This is much less painful if the
> new tab starts in the current working directory of the tab you were just
> in.
>
> I've just implemented this in my embedding of Terminator in Eclipse.
> This uses a small patch to the PtyProcess code to expose the process
> id. I then use this in Java to find out the cwd from /proc/$pid/cwd. I
> don't know a cross-platform way do this so this will only work on Linux
> and whatever UNIX platforms support /proc.
>
> Is this a feature you would be interested in for Terminator proper?
> Even without cross-platform support? If so then I'd be happy to discuss
> how best to implement it and come up with a patch.

not using tabs, i have no opinion. maybe others do.

> If not, please consider
> applying the attached patch to just expose the pid. Please be brutal
> about my C++/JNI (not that there's much of it), it's been a fair while
> since I've written any C/C++ and this is my first JNI code.

you don't need this patch. in your calling code just replace "getPid" with
"getProcessId" --- we already offer what you want, just not with the name
you expected.

i wouldn't be against changing getProcessId to getPid, depending on what
others think. (we're seriously considering moving PtyProcess to
salma-hayek and moving away from Sun's Process everywhere.)

--
Elliott Hughes, http://www.jessies.org/~enh/

[Martin Dorey]

"id" is already an abbreviation and there's well-known precedent for
getpid and, though you could make a case that it would be misleading, I
think it would be a poor case - it's PtyProcess.getPid, not
Posix.getPid. Someone clueful and motivated being confused is
compelling. There's also some compelling grot in the code where we
initialize a local variable called "pid" from the field called
"processId". Two names for the same thing? I'll sort it out.

[Martin Dorey]

> I often get some way through assembling a command line, realize I'm
> missing some piece of information, spawn a new tab, find it out, close
the
> new tab and carry on. This is much less painful if the new tab starts
in
> the current working directory of the tab you were just in.

That's a reasonably compelling use-case. A look at the behavior of the
cited precedent - gnome-terminal (which I, and I think we, have some
respect for) - shows that it does this for "New Terminal" (by which it
means New Window) as well as "New Tab". I still don't have any
objection. Others may now have. If so, we could consider stretching to
a preference. I suspect we won't get any strong feedback until we do it
and people see how it feels. (Then go "ugh!", then use it for a while
and come to like it.)

> so this will only work on Linux and whatever UNIX platforms support
/proc

Cygwin, for one. Cygwin support would mean doing the readlink in the
JNI, which is where we do most (but not quite all) of what little /proc
handling we do at the moment. Lack of Cygwin support for this wouldn't
be killer. It'd be nice to behave the same on all platforms, though.
That'd also mean finding a way of doing this on Mac OS. 30s of Googling
didn't find it and I'm out of time again.

-----Original Message-----
From: terminat...@googlegroups.com
[mailto:terminat...@googlegroups.com] On Behalf Of Matt Hillsdon
Sent: Saturday, April 04, 2009 09:42
To: terminat...@googlegroups.com
Subject: [terminator-users] Preserving current working directory for new
tabs

[Matt Hillsdon]

Elliott Hughes wrote:
> On Sat, April 4, 2009 09:42, Matt Hillsdon wrote:
>

>> ...

>> Is this a feature you would be interested in for Terminator proper?
>> Even without cross-platform support? If so then I'd be happy to discuss
>> how best to implement it and come up with a patch.
>>
>
> not using tabs, i have no opinion. maybe others do.
>

As Martin notes it applies to new windows too.

>> If not, please consider
>> applying the attached patch to just expose the pid. Please be brutal
>> about my C++/JNI (not that there's much of it), it's been a fair while
>> since I've written any C/C++ and this is my first JNI code.
>>
>
> you don't need this patch. in your calling code just replace "getPid" with
> "getProcessId" --- we already offer what you want, just not with the name
> you expected.
>

Oops! I think getPid is more natural, but I'm embarrassed to have
missed getProcessId.

Matt.

[Matt Hillsdon]

Martin Dorey wrote:
> Cygwin, for one. Cygwin support would mean doing the readlink in the
> JNI, which is where we do most (but not quite all) of what little /proc
> handling we do at the moment. Lack of Cygwin support for this wouldn't
> be killer. It'd be nice to behave the same on all platforms, though.
> That'd also mean finding a way of doing this on Mac OS. 30s of Googling
> didn't find it and I'm out of time again.

I can see it might make sense do push it into JNI if it was to be a
terminator feature and present a uniform interface, e.g.
PtyProcess.getCwd, across all platforms, even if it had to be described
as 'best effort' and always failed for some platforms.

My googling suggests lsof -p $pid will give the cwd on OSX. I can't
confirm. Perhaps we can find out how it does it. I'll investigate
further later in the week.

Matt.

[Elliott Hughes]

On Sat, April 4, 2009 15:12, Matt Hillsdon wrote:
> Elliott Hughes wrote:
>> On Sat, April 4, 2009 09:42, Matt Hillsdon wrote:
>>> ...
>>> Is this a feature you would be interested in for Terminator proper?
>>> Even without cross-platform support? If so then I'd be happy to
>>> discuss how best to implement it and come up with a patch.
>>
>> not using tabs, i have no opinion. maybe others do.
>
> As Martin notes it applies to new windows too.

in GNOME Terminal, but we don't have to copy that. if we do, i'd
definitely want a preference to turn it off. why would i be opening a new
window if i wasn't about to do something new?

(i can perhaps see the use of a separate "clone" action, but i fear the
only time i'd want it would be when i'm actually SSHed into another
machine, and it wouldn't actually help me there.)

in fact, i could almost do with the opposite functionality, that noticed
when i cd into a directory another shell's already in and pops the other
one to the front, reminding me that i've lost it under my other windows
;-)

[Chris Reece]

> I still don't have any objection. Others may now have.

Unless I've overlooked some part of the conversation, this is only
going to work for local processes. I spend most of my time operating
remotely. My most commonly used "New" function is "New Command Tab",
followed by typing a hostname, Tab, Return. Matt's use case matches
my own needs, except that the environment I want to duplicate will be
a shell with the same cwd, on the same remote machine. I've learned
to ^Z, pushd and popd (utilising other sessions on the remote
machine) but that kind of use -- a handful of shells doing lots of
different things -- is in contrast to my usage when shells are local,
where tabs are typically opened for the duration of a particular task
and closed as soon as that task is complete. Matching sessions to
tasks like that is a great help when you're juggling a lot of balls
at once. Matt's suggestion sounds like a boon there.

Dirty as it may be, some sort of heuristic that used the window title
(most often saying things like 'telnet hostname', 'ssh -v [username@]
hostname' or '[[username@]hostname:]path') would probably get me very
close to where I want to be. If memory serves, each Terminator
session has record of the command that is started with, which in my
case might provide useful information on how I got to where I want my
new shell to be (e.g: 'ssh -vXA hostname.fqdn.fqdn'. But while that
sort of magick sounds like heaven to use, it sounds like hell to
implement and support.

No objections here.

> If so, we could consider stretching to a preference.

Or extending the current Cmd-T for new tab, Shift-Cmd-T for new
command tab with Shift-Alt-Diamond-Stop-Help-Cmd-T for new tab in
this cwd?

--
Chris Reece
http://www.jessies.org/~car/

[Elliott Hughes]

On Sat, April 4, 2009 15:42, Chris Reece wrote:
>> I still don't have any objection. Others may now have.
>
> Unless I've overlooked some part of the conversation, this is only
> going to work for local processes. I spend most of my time operating
> remotely. My most commonly used "New" function is "New Command Tab",
> followed by typing a hostname, Tab, Return. Matt's use case matches my
> own needs, except that the environment I want to duplicate will be a shell
> with the same cwd, on the same remote machine. I've learned to ^Z, pushd
> and popd (utilising other sessions on the remote machine) but that kind of
> use -- a handful of shells doing lots of different things -- is in
> contrast to my usage when shells are local, where tabs are typically
> opened for the duration of a particular task and closed as soon as that
> task is complete. Matching sessions to tasks like that is a great help
> when you're juggling a lot of balls at once. Matt's suggestion sounds
> like a boon there.

(maybe this is why i don't use tabs; it's only usually by accident of
forgetfulness that i have multiple shells in the same directory. even for
the SSH case, i usually want a new shell on the remote machine in a
different directory.)

> Dirty as it may be, some sort of heuristic that used the window title
> (most often saying things like 'telnet hostname', 'ssh -v [username@]
> hostname' or '[[username@]hostname:]path') would probably get me very close
> to where I want to be. If memory serves, each Terminator session has
> record of the command that is started with, which in my case might provide
> useful information on how I got to where I want my new shell to be (e.g:
> 'ssh -vXA hostname.fqdn.fqdn'. But while that
> sort of magick sounds like heaven to use, it sounds like hell to implement
> and support.

i use ssh a lot, but i'll create a new shell and then type "ssh ...". or,
more to the point, i'll use my command-line history. i think that's part
of why i don't use "new command": i already have one history [that doesn't
quite get on with itself]; i don't want another history that doesn't even
try to share.

i'd probably use something that scraped the title bar, but i'd never plan
ahead enough to make any use of "re-run the current window's command".

>> If so, we could consider stretching to a preference.
>
> Or extending the current Cmd-T for new tab, Shift-Cmd-T for new
> command tab with Shift-Alt-Diamond-Stop-Help-Cmd-T for new tab in this cwd?

i too was thinking it's a pity we've run out of modifiers. but by the
sounds of these fairly different usage patterns, maybe we really do want
preferences.

i'd use a "clone by guessing from title bar", but would want it as a
separate action, not the default behavior of "new shell". (i'm happy to
let tab users tell me what makes sense for tabs.)

--elliott

[Csaba]

On Apr 5, 12:56 am, "Elliott Hughes" <e...@jessies.org> wrote:
> On Sat, April 4, 2009 15:42, Chris Reece wrote:
> >> I still don't have any objection.  Others may now have.
>
> > Unless I've overlooked some part of the conversation, this is only
> > going to work for local processes.  I spend most of my time operating
> > remotely.

There's still a "current directory" on the local system (from before
launching ssh).

> > My most commonly used "New" function is "New Command Tab",
> > followed by typing a hostname, Tab, Return.  Matt's use case matches my
> > own needs, except that the environment I want to duplicate will be a shell
> > with the same cwd, on the same remote machine.

Even if terminator found out the machine and the remote directory, it
may
not be able to drive ssh to duplicate it e.g. if it went through a
third machine
to get there.

> i too was thinking it's a pity we've run out of modifiers. but by the
> sounds of these fairly different usage patterns, maybe we really do want
> preferences.
>
> i'd use a "clone by guessing from title bar", but would want it as a
> separate action, not the default behavior of "new shell".

"Clone" suggests itself :)

> (i'm happy to let tab users tell me what makes sense for tabs.)

I think the behavior should be the same regardless of whether one uses
tabs or separate windows (unless by "no tabs" you mean one single
shell window).

[Martin Dorey]

> I think the behavior should be the same regardless of whether one uses
tabs or separate windows

Me too. Some people use tabs, some people use windows. They use them for the same things.

I wonder what gnome-terminal does with environment. If you ran a new copy of Terminator from the terminal being cloned, it'd inherit that too. It could find that in /proc too.

[Martin Dorey]

> I wonder what gnome-terminal does with environment

Nothing clever.

[Elliott Hughes]

On Thu, April 9, 2009 07:35, Martin Dorey wrote:
> I wonder what gnome-terminal does with environment. If you ran a new
> copy of Terminator from the terminal being cloned, it'd inherit that too.
> It could find that in /proc too.

not wanting to distract my main "i don't use two shells in the same
directory at the same time" point before, i didn't mention that there is a
very rare occasion when i do, and that's when i've messed about with my
environment and i want to compare against a clean environment. duplicating
the environment would drive me mad.

back to the idea of duplicating the cwd, another thing i don't like about
the idea is that it ruins the muscle memory you have from always starting
in the same directory. ruins the history's ability to take you to your
usual haunts, too, unless you only ever use absolute paths (another thing
the idea of a home directory was meant to save us the hassle of).

[Martin Dorey]

Two different usages. One usage, you want to preserve everything. One,
nothing.

-----Original Message-----
From: terminat...@googlegroups.com
[mailto:terminat...@googlegroups.com] On Behalf Of Elliott Hughes
Sent: Thursday, April 09, 2009 08:50
To: terminat...@googlegroups.com
Subject: [terminator-users] Re: Preserving current working directory for
new tabs

[Elliott Hughes]

On Thu, April 9, 2009 08:52, Martin Dorey wrote:
> Two different usages. One usage, you want to preserve everything. One,
> nothing.

maybe. i certainly see the sense in that argument, but a counter argument
would be that since it's not actually possible to preserve everything, a
more simply-stated rule might cause less confusion. (as i said, i thought
what gnome-terminal was doing was failing to start a login shell. i wonder
if this is why so many people seem to have "cd" in their bash startup
scripts. i'd wondered about that.)

environment seems especially tricky because people often don't know what's
in their environment. given user problems i quite often ask them to try
again in a new shell, and when that works they remember that weeks ago
they changed something in their environment and had forgotten all about
it. a terminal emulator that preserved their environment would make life
more difficult there. it's easy to see & fix the cwd, but the environment
is large and hard to make pristine. (and i'll not lie and pretend i've
never wasted time by having messed with my environment and then forgotten
about it. when i say "people" i don't mean "beginners"; just "humans".)

--elliott

[Elliott Hughes]

(part of my motivation for making Terminator always start login shells,
which hasn't traditionally been the default behavior of terminal
emulators, was to ensure that you (a) always know what you're getting and
(b) know that each new shell is a "fresh" one. having long felt that way
probably explains why i'm having difficulty seeing this as anything but a
bad idea likely to cause more trouble than it would solve.)

--elliott

[Martin Dorey]

A little script to diff the /proc entries (in some useable format probably not involving nulls) between two processes seems likely to be of more general use than cloning the environment to a new shell.

 

Perhaps we should export the pid of the cloned terminal's "shell", then a small script could use that to cd or slurp the environment as it chooses.

[Elliott Hughes]

On Thu, April 9, 2009 10:21, Martin Dorey wrote:
> A little script to diff the /proc entries (in some useable format
> probably not involving nulls) between two processes seems likely to be of
> more general use than cloning the environment to a new shell.
>
> Perhaps we should export the pid of the cloned terminal's "shell", then
> a small script could use that to cd or slurp the environment as it chooses.

i was trying to think of a way we could make this available, but stupidly
didn't think of that (i was too stuck on the traditional X11 window id).

i do like the idea of adding some kind of user scripting support to
Terminator. i'd probably use a "get me another SSH connection to this same
machine" script (hacky and incapable of fully coping with transitive
SSHing though it would be), and my main use of short-lived shells is to
read a section 1 man page (Evergreen, probably sensibly unless you're
editing a shell script, restricts itself to sections 2 and 3).

something like Evergreen's "external tools" might be quite handy. "feed
the selection to addr2line and show the output in a dialog", "open the
selected file in Evergreen", "open a new shell window running 'ssh -v
%{selection}'"... i'm sure everyone could think of one or two things they
might use this for.

and "focused terminal's pid" would be another variable we could make
available. (though we only know our direct child; we have code to collect
the other pids, but to us they're just a set; we don't know the tree
structure. if we did, i'd have added a little tree to the info dialog ;-)
)

[Chris Reece]

On 10/04/2009, at 1:32 AM, Csaba wrote:

>
> On Apr 5, 12:56 am, "Elliott Hughes" <e...@jessies.org> wrote:
>> On Sat, April 4, 2009 15:42, Chris Reece wrote:
>>>> I still don't have any objection. Others may now have.
>>
>>> Unless I've overlooked some part of the conversation, this is only
>>> going to work for local processes. I spend most of my time
>>> operating
>>> remotely.
>
> There's still a "current directory" on the local system (from before
> launching ssh).

Yes, I discounted that because it's not useful to me. Is it useful
to you?

>>> My most commonly used "New" function is "New Command Tab",
>>> followed by typing a hostname, Tab, Return. Matt's use case
>>> matches my
>>> own needs, except that the environment I want to duplicate will
>>> be a shell
>>> with the same cwd, on the same remote machine.
>
> Even if terminator found out the machine and the remote directory, it
> may
> not be able to drive ssh to duplicate it e.g. if it went through a
> third machine
> to get there.

Yes, that's what I was thinking when I drifted from title-scraping to
using the tab or window's initiating command. If the hostnames
matched, the directory gained from scraping the title would be
useful. If they didn't, then simply repeating the tab's initial
command would be useful to me, because it'd get me one hop closer.
But as Elliott pointed out, his usage (start a shell, then ssh) is
different from mine, making the window title his only source of
information.

> I think the behavior should be the same regardless of whether one uses
> tabs or separate windows (unless by "no tabs" you mean one single
> shell window).

This would certainly be less confusing.

[Chris Reece]

On 10/04/2009, at 3:50 AM, Elliott Hughes wrote:
> back to the idea of duplicating the cwd, another thing i don't like
> about
> the idea is that it ruins the muscle memory you have from always
> starting
> in the same directory. ruins the history's ability to take you to your
> usual haunts, too, unless you only ever use absolute paths (another
> thing
> the idea of a home directory was meant to save us the hassle of).

Anyone else share this muscle memory? Personally, if I'm thinking
"from ${HOME}, go FOO", I type "cd" first, without stopping to think
whether I'm in my home directory already.

[Matt Hillsdon]

Sorry for starting this thread and then vanishing. I've commented on
input from various people below.

First a little background I omitted before: my Eclipse embedding of
terminator doesn't just default the cwd for new tabs based on the
currently selected tab. If another element in the Eclipse UI is focused
(for example an editor) and a terminal is spawned, it uses the directory
associated with the UI element (so the directory containing the file
being edited). The consistency of using the cwd when a terminal is
focused makes sense to me. Plus, as I said before, I'm addicted to it
from gnome-terminal.

I don't really have the muscle memory issue. I do find myself typing
cd, or cd ~/... often but that's cheap, whereas it's often awkward to
get back to a path deep within a Java source tree (an average path from
/ to a leaf package has ~9 segments for me).

I rarely intentionally use multiple windows. Others have very different
work styles and I can see cwd preserving could be irritating if new
shell almost always means new task. Perhaps this is a case for a
preference, though as I say don't see the cost of cd or cd ~/... as
high, but that's my habit and the change might be very annoying to
someone used to always starting in their home directory.

I don't really use ssh often enough to comment on cloning remote
sessions. I just connect to one machine and use screen(1) all the while.

Exposing the pid of the spawning tab's command in the new tab's
environment for scripting is a neat idea but pretty much hides the
feature from the average user.

More generally, I raised this because I find this feature essential and,
because I'd got some way to implementing it myself, it seemed
straightforward enough to add to terminator. However, I don't really
have much invested in any decision because I don't actually use
terminator day-to-day other than embedded in Eclipse, which handles
creating a new tab differently and now behaves as I prefer. I might
benefit in terms of cross platform support if getCwd ended up on
PtyProcess though I'm only worrying about Linux for now.

It's not clear to me that there's a consensus.

Matt.

[Martin Dorey]

I just can't live without my Shell Window external tool in Evergreen, which equivalently gets me a terminal in the directory of the focused source.

More generally, I've kept a closer eye on what I'm opening new windows for since this discussion. I'd estimate that about two thirds of the time, I'm wanting to start something new but about a third of the time I explicitly want to be in the same directory, to perform some subtask that I don't want in the main window for one of various reasons. Now the idea has been brought up, I'm irritated each time I have to cd back to the right place.

> Exposing the pid of the spawning tab's
> command in the new tab's environment for
> scripting is a neat idea but pretty much
> hides the feature from the average user.

Yeah. One way of revealing it would be in a preference for the command we run. "cd /proc/$TERMINATOR_PARENT_PID/cwd && bash --login". Mmm... but then we'd have to run the shell via the shell and we have to choose the directory for the child anyway. Yeah, bleagh.

I think the function is worth having. I think it should be uniform across windows and tabs. I think it should be a different action rather than a preference, so I can use both at will, though I'd use the popup menu anyway for the with-cwd case, so I don't care if the binding between key shortcut and preferred action is a preference.

I suppose we could grey-out or omit the menu items on platforms where we haven't got support yet.

Although there isn't consensus, there's general agreement that it's a plausible feature. As long as the existing default actions and key bindings don't change, I think there's quorum for making additions. What's the next step?

----- Original Message -----
From: terminat...@googlegroups.com <terminat...@googlegroups.com>

To: terminat...@googlegroups.com <terminat...@googlegroups.com>
Sent: Tue May 05 17:08:20 2009
Subject: [terminator-users] Re: Preserving current working directory for new tabs

[Chris Reece]

> Although there isn't consensus, there's general agreement that it's a
> plausible feature. As long as the existing default actions and key bindings
> don't change, I think there's quorum for making additions.

Chris is happy to suck it and see.

[Elliott Hughes]

On Wed, May 6, 2009 08:04, Martin Dorey wrote:
> I just can't live without my Shell Window external tool in Evergreen,
> which equivalently gets me a terminal in the directory of the focused
> source.
>
> More generally, I've kept a closer eye on what I'm opening new windows
> for since this discussion. I'd estimate that about two thirds of the
> time, I'm wanting to start something new but about a third of the time I
> explicitly want to be in the same directory, to perform some subtask that
> I don't want in the main window for one of various reasons. Now the idea
> has been brought up, I'm irritated each time I have to cd back to the
> right place.

i've been paying attention too, and though i'd only use it about once a
day, i still find myself thinking "why isn't there a key to do this?". but
i don't know what the key would be. we already oversubscribe some keys for
control-shift users, and this would only make things worse.

>> Exposing the pid of the spawning tab's
>> command in the new tab's environment for scripting is a neat idea but
>> pretty much hides the feature from the average user.
>
> Yeah. One way of revealing it would be in a preference for the command
> we run. "cd /proc/$TERMINATOR_PARENT_PID/cwd && bash --login". Mmm...
> but then we'd have to run the shell via the shell and we have to choose
> the directory for the child anyway. Yeah, bleagh.
>
> I think the function is worth having. I think it should be uniform
> across windows and tabs. I think it should be a different action rather
> than a preference, so I can use both at will, though I'd use the popup
> menu anyway for the with-cwd case, so I don't care if the binding between
> key shortcut and preferred action is a preference.

that's an interesting idea. having it on the menu wouldn't get in anyone's
way. (though i do then wonder whether i'd ever use it!)

> I suppose we could grey-out or omit the menu items on platforms where we
> haven't got support yet.

remind me where we can't do this? is it Linux-only?

it's a bit weird in that getters on process abstractions usually tell you
the initial (arguments, environment, directory, pid) or final (exit
status) value. we could always put it in ProcessUtilities. there's plenty
of use-at-your-own-risk stuff in there already ;-) (and there's no obvious
advantage to using JNI to implement it, aiui.)

--elliott

> It's not clear to me that there's a consensus.
>
>
> Matt.
>
>
>
>
>
>
> >
>
>

[Martin Dorey]

>> I'd use the popup menu anyway for the with-cwd case

> having it on the menu wouldn't get in anyone's way.

 

That sounds like a good starter then.

 

> remind me where we can't do this?

 

We don't have code to do it on Mac or, I guess, Solaris.  The Linux method will work on Cygwin, if we inspect /proc from Cygwin.

 

-----Original Message-----
From: terminat...@googlegroups.com [mailto:terminat...@googlegroups.com] On Behalf Of Elliott Hughes

[Chris Reece]

> We don't have code to do it on Mac or, I guess, Solaris

Both Solaris 9 and 10 implement /proc/<pid>/cwd. Did you need more than that?

[Martin Dorey]

Just Mac then.

[Matt Hillsdon]

Martin Dorey wrote:
> Just Mac then.
>

Yeah. I don't have a Mac handy. Does an OSX standard install have
lsof? On Linux

/usr/sbin/lsof -a -p $PID -d cwd -F0n

seems to run quickly and be fairly easy to parse.

Matt.

[Chris Reece]

On Thu, May 7, 2009 7:56 pm, Matt Hillsdon wrote:

> Martin Dorey wrote:
>
>> Just Mac then.
>>
>>
>
> Yeah. I don't have a Mac handy. Does an OSX standard install have
> lsof? On Linux
>
> /usr/sbin/lsof -a -p $PID -d cwd -F0n

My 10.4 iBook does:

dahmer:/var/tmp car$ /usr/sbin/lsof -a -p 18316 -d cwd -F0n
p18316
n/private/var/tmp

However, in case we were hoping for a one-stop shop, Solaris doesn't.
Available from Blastwave or OpenCSW.

[Martin Dorey]

Since we originally talked about this idea, we gained code that implicitly canonicalizes Cygwin symlinks from Java whenever we open a Cygwin path. Now there'd be no advantage to implementing getCwd in the JNI, which would be a relief even if we weren't contemplating a forky pipe parsing dance for Mac.

----- Original Message -----
From: terminat...@googlegroups.com <terminat...@googlegroups.com>
To: terminat...@googlegroups.com <terminat...@googlegroups.com>
Cc: terminat...@googlegroups.com <terminat...@googlegroups.com>
Sent: Thu May 07 01:08:54 2009
Subject: [terminator-users] Re: Preserving current working directory for new tabs

[Martin Dorey]

My 10.4 MacBook (entirely unsurprisingly) has lsof too.

The Windows Explorer right-click menu's "Open Terminator Here", which follows convention from elsewhere, suggests a clear enough and concise name for the menu options - "New Shell Here" and "New Tab Here".

I feel a patch coming on.