Below is a patch for getting tmux running on cygwin. I only have access to
a 32 bit XP system, so I don't know if it works on other versions of
Windows. Cygwin doesn't provide a libevent package, so you'll first have
to install that. I used libevent-2.0.21-stable. Also, for tmux I had to
specif
I've added the patch as an attachment since it seems it was garbled the
first time.
On Wed, May 15, 2013 at 1:32 AM, Nicholas Marriott <
nicholas.marri...@gmail.com> wrote:
> Hi
>
> Your mailer has mangled the patch, can you attach it?
>
>
> On Wed, May 15, 2013
I've found a better way to get tmux working on cygwin. There's now no need
to modify tty.c to have separate read and write file descriptors. I've
attached the new patch.
On Wed, May 15, 2013 at 12:59 AM, J Raynor wrote:
> Below is a patch for getting tmux running on cy
The patch I had sent in was meant for testing, and to see if there was
any interest, so I wasn't putting any effort into getting it into
shape for acceptance. Now that that might be possible, I'll get it
cleaned up, taking into account your notes.
> I guess this obviously won't let other things
I've attached a new patch.
TTY_NAME_MAX is already defined in compat.h, so I didn't need to add
it. Gcc didn't define _WIN32, so I used __CYGWIN__ instead.
Regarding this:
> You should probably fail early if isatty is false (before filling in ttyname
> into the identify struct).
I believe isa
I've attached an updated patch.
You had wanted the change to resolv.h to go into compat.h, but I
didn't see how to do that since I needed to comment it out. But I
figured out that I just needed to undef something. I put that in
compat.h, so now tty.c isn't changed at all.
tmux-cygwin.patch
Des
I've attached a new patch that puts the msg_identify_data change in an
ifdef. Also, in compat.h, I moved the "undef b64_ntop" for cygwin
into the "ifndef HAVE_B64_NTOP" check so that if cygwin ever gets a
working b64_ntop tmux will continue to compile.
If I do "tmux new
tmux-cygwin.patch
Descri
> Are you sure ECHOPRT 0x20 is right on Cygwin? Maybe it should be 0 to
> leave it out if it isn't supported?
I'm not the least bit sure, so I'll defer to you.
I tested your patch and it worked fine.
--
See everything fr
I use pipe-pane to capture the output of my sessions, but I would
prefer not to have to spawn external processes to do so. I've
attached a patch that enables pipe-pane to write directly to a file.
I realize the semantics are a little off; you pipe to processes, not
files. But it's close.
Doing
>
> Why? What's wrong with using cat?
>
I log my sessions, so I end up with a bunch of cat and sh processes,
and it just bugs me slightly seeing them when they don't need to be.
Some better reasons for it would be:
- If you log lots of sessions, you're getting closer to hitting maxuproc.
- Usi
I wasn't trying to make the claim that using cat hurts performance,
just that it uses more resources than is necessary.
With libevent1, all other functionality should still work. You just
wouldn't get the write-to-file functionality.
It looks like libevent1 was last updated over 3 years ago. Wo
> If you log lots of sessions, what the hell are you doing in the first place
> that needs it? You could always use script(1) or ttyrec(1) instead.
I prefer to log my sessions so that I have a history in case I need
it. And occasionally I do. I know I could use other tools, but if
that's what s
I've attached a new patch. The functionality now uses socketpair
instead of bufferevent_pair_new(), so it'll work with libevent1 and 2,
and there's no need to reimplement any of libevent2 in tmux.
pipe2file.patch
Description: Binary data
--
The TODO list for tmux has this entry:
* add -c for new-session like new-window
I've attached a patch that implements that.
new-c.patch
Description: Binary data
--
Get your SQL database under version control now!
Versi
Ok. Maybe I'll take a stab at adding an actual logging facility and
see if that might be more palatable.
--
Get your SQL database under version control now!
Version control is standard for application code, but databases
> You could possibly record it externally by starting a control client
> for each session and listening for %output.
By "externally" do you mean a separate process? Or just a separate
bufferevent processor (external to the pane), so that each pane isn't
doing its own file writing?
--
> Entirely separate process that could fork a "tmux -C attach", it
> wouldn't even need to be C.
Ah, now I understand what you meant. That's quite different from what
I had in mind.
The desire to log sessions can't be that strange. Different terminal
emulators, like putty, iTerm, and KDE's kons
I've attached a new patch that should support the same prefixes as neww.
new-c.patch
Description: Binary data
--
Get your SQL database under version control now!
Version control is standard for application code, but datab
I've attached a patch that implements logging with a new command,
log-pane or logp. A -b flag will begin logging for the pane, -e will
end it, and -o will toggle it on/off, similar to pipe-pane. You can
specify the filename with -f, but if you don't, there's a default
that's set to "~/tmux-#S-#I-
> Why are you using status_replace() for this? format_expand() and
> using a struct format_tree * makes much more sense here. What has
> status_replace() got to do with expanding file names?
I want to allow things like #S and #P in the filename so people can
tell the different logs apart. Using
On Sat, Aug 17, 2013 at 3:50 AM, Nicholas Marriott
wrote:
> Do we need a new command? Why not just a window option log-file and if it is
> set all panes in that window are logged? People who want everything logged
> can set it globally. If we have a new command it is hardly different from
> pipe-p
Combining the logging with pipe-pane seemed to be the easier option
since I'm familiar with both bits of code, so I gave that a shot and
I've attached a new patch.
The code for the logging and for having pipe-pane write to a file are
a bit simpler than previous patches. There's no need for a sepa
On Sun, Aug 18, 2013 at 1:42 AM, Nicholas Marriott
wrote:
> I think either you or me are miss the point :-).
Oh, I'll bet it's me.
> There is no point adding something to pipe-pane or something that does the
> same as pipe-pane. People who want to log individual panes can already do it
> with p
I've attached a new patch that implements logging without adding a new
command and without touching pipe-pane.
There's a window option called logging-default-logname that's set to
"~/tmux-#S-#I-#P.log" by default. That's what name logfiles will get
when they get created. I mainly needed a string
There are some conditions I don't know how to generate, so I couldn't
test those. But I tried testing what I could, and it appears that
this preserves the behavior of neww and split-window, and that the
prefixes for "new -c" match the -c behavior for neww and split-window.
Does cmd_default_path1
This looks fine too, except it looks like the unreachable "return
(base);" is still there.
Also, the comment above cmd_default_path() mentions using the
default-path option, but that's now taken care of elsewhere. So that
might need an update.
I've attached a new patch for the logging.
> - Don't add new calls to status_replace please. Use format API directly
> instead.
The new patch does this.
> - These option names aren't great. How about automatic-log and
> automatic-log-format (or automatic-log-file)?
Yeah, I didn't care for
Could you try pulling the latest from git and compiling it? Once
compiled, if it still doesn't work, what happens if you do:
tmux < /dev/null
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Disc
> Note that even when I release 1.9, which will contain support on
> Cygwin, I won't be providing Windows binaries of tmux. That's
> somebody else's problem.
Are you interested in having a cygwin package for tmux if someone else
either builds the package, or supplies a small script which would ta
Most of these just look like warnings. But for this:
> configure.ac:111: error: possibly undefined macro: AC_SEARCH_LIBS
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
I believe you need to have pkg-config installed. You ca
If you run it normally, does it work now?
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get a
Mark was starting cygwin using the cygwin.bat script. This results in
a terminal with /dev/cons0 (or cons1, cons2, etc) instead of /dev/ptyX
as the tty. From the cygwin documentation:
> Starting with Cygwin 1.7.10, Console sessions are numbered from /dev/cons0
> upwards.
> Console device names a
I've attached a patch that implements this.
tmux-otherend.patch
Description: Binary data
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI,
It looks like there's a bug in the window_copy_scroll_up and down
functions where they don't correctly highlight what's been selected
for copying.
To see the problem with window_copy_scroll_up, do the following:
1. Generate more than a screenful of text.
2. Enter copy mode.
3. Scroll up some s
I applied your patch and it corrects the problem.
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn mo
I've attached a patch that implements case insensitive searching in
copy mode. The case insensitive searching only works for ascii
characters (not unicode) because that's all tmux appears to allow you
to enter when you do a search.
The patch adds a new window option called case-insensitive-search
> How about doing this the emacs way? All lowercase means case-insensitive,
> any caps means case-sensitive.
Sure. I've attached a new patch that does that. There's no window
option this time since it isn't needed.
tmux-case-insensitive-search.patch
Description: Binary data
---
The TODO list has this item:
* attach should take a pane and select it as well as attaching
I've attached a patch that implements this. You can specify a pane
with %, or a window with @, just as before, but tmux will switch to
that pane or window. You can also specify windows and panes with th
> Can't you just use cmd_find_pane? If the user doesn't specify a pane
> it'll default to the active pane anyway so selecting it'll be a no-op.
Do you mean use a patch like this:
diff --git a/cmd-attach-session.c b/cmd-attach-session.c
index e4c0b23..7f7153e 100644
--- a/cmd-attach-session.c
+++
> Can't you just use cmd_find_pane? If the user doesn't specify a pane
> it'll default to the active pane anyway so selecting it'll be a no-op.
Your suggestion got me to look at my patch again, and I think it
could've been clearer. I've attached an updated patch. Everything
should behave the sam
This works fine. However, as of 1.8, it is possible to have a period
in the session name and to attach to it. With this patch, it's no
longer possible to attach to such a session since the period is
interpreted as a pane specifier. Does that matter?
-
On Mon, Jan 6, 2014 at 9:22 AM, Nicholas Marriott
wrote:
> Hmm... I don't know, people who include periods in session names are
> probably just asking for trouble but maybe we should ban them earlier.
By "ban them earlier" do you mean never allow periods in session
names? If so, the attached pa
The tmux TODO list has this item regarding command sequences:
* don't require space after ;
I've attached a patch that does this.
diff --git a/cmd-list.c b/cmd-list.c
index 08e2067..22327cd 100644
--- a/cmd-list.c
+++ b/cmd-list.c
@@ -29,55 +29,85 @@ cmd_list_parse(int argc, char **argv, const
There's this item on the tmux TODO list:
* way to set socket path from config file
I was thinking of trying to implement it, but I thought it needed
discussion first.
I was thinking that there could be a command, like set-client or
set-flag. This could be used to set the socket path (set-clien
> I don't really see a need for this at all, especially given the
> complexity it'll add to the client
Do you not see a need for the TODO list item (anymore), or just the
proposed implementation?
If it's the latter, how about something simpler? The client could
read the config file and look for:
Ok. I'll drop it.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quo
I've attached a patch which implements this. The 't' group of escape
sequences are described as being for "window manipulation" in some
documentation, so that's why I picked WMN in the INPUT_CSI_WMN
identifier.
diff --git a/input.c b/input.c
index 259fad1..e27ecbb 100644
--- a/input.c
+++ b/input.
Sorry, after I submitted the patch I realized it was incorrect.
Certain options take arguments and my patch didn't account for that.
I've attached a new patch which does.
On Wed, Jan 29, 2014 at 12:28 AM, J Raynor wrote:
> I've attached a patch which implements this. The &
> How about WINOPS instead of WMN? This matches xterm src and seems a bit
> more readable. Otherwise looks good.
Sure. I've attached an updated patch with WINOPS instead of WMN.
diff --git a/input.c b/input.c
index 259fad1..bc4f912 100644
--- a/input.c
+++ b/input.c
@@ -154,6 +154,7 @@ enum input
> Take a look at this instead which a) uses a function like CSI, SM etc b)
> don't increment m inside function arguments.
This works fine. However, I noticed that just incrementing m may
cause it to skip over bad input. For example, a winop of 3 is
supposed to take 2 arguments. If someone enter
> Please don't use expressions with side-effects like m++ in function
> arguments, it's too easy to miss.
Ok. I've attached a new patch that meets your request.
diff --git a/input.c b/input.c
index 259fad1..23804b9 100644
--- a/input.c
+++ b/input.c
@@ -74,6 +74,7 @@ void input_csi_dispatch_rm(s
> This breaks quotes, for example try:
>
> neww -n "a;neww"
I knew the patch caused this behavior.
> I know the existing code allows things like 'neww -n "a;" neww'
And that's why I didn't think it was a problem. I figured it was
established behavior that semicolons weren't safe in quotes.
The tmux TODO list has this item:
* use "--" to mark start of command w/ neww etc to avoid quoting
I'm a little confused about this, so I'm hoping to get some
clarification. In this email:
http://article.gmane.org/gmane.comp.terminal-emulators.tmux.user/5432
...the user gets a usage error wi
> I don't think you need to modify getopt, the commands just need to handle a
> variable number of args but I don't remember specifics of what needs to
> change.
I still don't see how I can get "--" passed to neww. For example,
this works fine in tmux 1.8:
tmux neww -- emacs
There's no code in
> No, this is why "--" exists, and on BSD, getopt() does not do "--"
> scanning, unlike on Linux.
The man page for getopt in openbsd mentions checking for "--", and
tmux's compat/getopt.c, which has a lot of "BSD" in it, also checks
for "--".
>> would never see it, and so couldn't alter its beha
> Neww doesn't need to get -- it just needs to know how many args it has. The
> -- is to make getopt pass args to neww rather than treating as flags eg
>
> tmux neww -x -- foo -y
>
> Needs to set x flag in args but pass 2 args to neww foo and -y.
I believe the existing code already does this. New
> If you want I can send you a rough diff of how I think this should look?
I think Nicholas's last email cleared up most of what I needed, but I
might try to take you up on this if it turns out I'm still not getting
it.
-
> The original behaviour needs to stay if there is 1 arg.
Should there be a way to force the new behavior? This might be
desirable since quoting would be different in this one case. For
example, someone might enter:
neww "/path/x y/bin/foo"
...and their intention is to run the command "foo"
I've attached a patch that allows people to specify a command to neww
and related commands without having to quote the command. Using "--"
is only needed if the command you want to run happens to start with a
dash.
tmux-dashdash.patch
Description: Binary data
> - If we are going to call execvp we should control PATH, I think we
> should probably get it from the client if it's a command line client
> else from the session environ. In any case you'll need to pass it in
> from the caller as yet another argument.
Tmux currently runs commands by calli
> I reckon we always set PATH and yes pass it into the func. Behaviour will
> only change if someone sets PATH in global or session environment
> themselves.
I've attached a new patch with the new PATH behavior, and the patch
also fixes the 2 issues you noted with cmd_stringify_argv.
tmux-dashda
It looks like there's a potential memory leak in
window_copy_copy_selection. This function calls
window_copy_copy_buffer, which calls paste_replace. If paste_replace
succeeds, it stores the data that was passed to it.
But if paste_replace fails, such as when an invalid buffer index is
specified,
> Why not this instead? Also fix some other similar problems.
I was hesitant to free the memory in window_copy_copy_buffer in case
the caller wasn't done with it. But since all current callers are
done with it, I guess it doesn't matter.
Your patch looks good.
--
I suppose paste_replace could always handle the freeing of the memory.
This would preserve its fire and forget nature.
See the attached patch.
tmux-ml.patch
Description: Binary data
--
Android apps run on BlackBerry 10
In the "copy/paste improvements" section of the TODO list there's this item:
* append to buffer
I've attached a patch that implements this. I've added a new command
called append-buffer, which works like set-buffer. I added the code
for this in cmd-set-buffer.c to avoid adding a new source fil
> Hi. Can you make this a flag to setb (-A? -a?) instead of a new command?
Sure. I've attached a new patch. There's no append-buffer command,
and passing -a to set-buffer will cause it to append.
tmux-append.patch
Description: Binary data
---
> This looks good but you need to add the new flag and key to the manpage?
I've attached a new patch that includes updates to the man page.
tmux-append.patch
Description: Binary data
--
Managing the Performance of Cloud-
> Applied with a few changes, thanks
The changes removed a bit of functionality. If someone does "setb -a
foo", then I believe that "foo" should get appended to what's at
buffer 0, assuming it isn't NULL. That doesn't happen with the patch
that got applied.
If the removal of that functionality
The TODO list has this item:
* get_cwd for cgywin
I've attached a patch which implements this, along with get_name.
Cygwin's /proc filesystem is similar enough to linux's that the code
could be copied from osdep-linux.c, and that's what I've done.
osdep-cygwin.c is just a copy of osdep-linux.c,
> what i didn't like before was that setb -a w/o any buffers acts like
> setb, but i think that is actually more useful than an error
In copy mode, if you highlight some text and hit 'A', it'll set buffer
0 if it's NULL, otherwise it'll append to what's there. I figured
"setb -a" should work the
> nice, i thought they would probably be very similar but the guy who
> requested this said he tried to copy osdep-linux.c and it didn't work
Hmm. Did he supply a patch? I'm just wondering if he forgot to
update configure.ac. In that case, tmux would've continued to use
osdep-unknown.c.
--
> Any chance you can split the PATH bits out so they work on the current
> code then we can apply them separately before adding --?
Let me make sure I understand what you're looking for.
The current code passes in cmd to things like session_create and
window_pane_spawn. My patch, as it is now, d
> I did not submit a patch because I could not get `tmux splitw -c
> '#{pane_current_path}'` to work properly on Cygwin. I'd love to say that the
> patch submitted by J Raynor worked for me though, but I'm still always
> getting new panes/windows opening at `~`
> I did not submit a patch because I could not get `tmux splitw -c
> '#{pane_current_path}'` to work properly on Cygwin. I'd love to say that the
> patch submitted by J Raynor worked for me though, but I'm still always
> getting new panes/windows opening at `~`
It looks like cygwin's /etc/profile is causing the homedir behavior.
Add this line to your tmux.conf and the behavior should stop:
set-environment -g CHERE_INVOKING 1
--
Learn Graph Databases - Download FREE O'Reilly Book
I've attached a patch that just does the PATH bits.
diff --git a/cmd-new-session.c b/cmd-new-session.c
index 15e411d..8953820 100644
--- a/cmd-new-session.c
+++ b/cmd-new-session.c
@@ -54,11 +54,12 @@ cmd_new_session_exec(struct cmd *self, struct cmd_q *cmdq)
struct window *w;
struct environ
The following will cause a fatal error in recent tmux code:
setb ""
The empty string leads to an xrealloc in cmd-set-buffer.c with a size
of 0, which is fatal. I've attached a patch which fixes this.
diff --git a/cmd-set-buffer.c b/cmd-set-buffer.c
index 0e754bb..e7f9b95 100644
--- a/cmd-set-bu
For cygwin, you may also need to set/export CHERE_INVOKING=1 before
starting tmux, or put this in your .tmux.conf:
set-environment -g CHERE_INVOKING 1
See here for more:
http://article.gmane.org/gmane.comp.terminal-emulators.tmux.user/5920
http://article.gmane.org/gmane.comp.terminal-emulators
I've attached a patch which implements named buffers.
Commands that take a buffer arg, like save-buffer and paste-buffer,
have been modified so that -b can take a number or a name. So, you
can do "setb -b myBuf someData".
buffer-limit applies to both the paste stack and the named buffers.
So if
e rest of the
"--" patch since the 2 parts of the patch need to modify some of the
same lines in different ways, so they'd conflict if they were just 2
unrelated patches.
On Tue, Mar 11, 2014 at 7:05 PM, J Raynor wrote:
> I&
In cmd-new-session.c, you've made path's type "char *", but everywhere
else it is "const char *". Was that intentional?
The parts of your patch that take the path from the global or session
env seem redundant, unless I'm missing a use case. When a new
session, window, or pane is created, a new e
On Thu, Apr 17, 2014 at 8:04 AM, Nicholas Marriott
wrote:
> Applied this to OpenBSD now with the const char * thing fixed. Thanks
Ok. I'll wait until this shows up in the git repository and then send
in the 2nd part of the "--" patch.
Your proposed implementation looks fine to me. I have a question about this:
> - buffer-limit is only applied to !sticky buffers
Which of these did you mean?
1. Buffer-limit limits the total number of buffers (the sum of sticky
and non-sticky), but only non-sticky buffers get aged away.
2. B
I've attached a new patch for named buffers. There's no longer a
paste stack. There's a name-tree which stores all the buffers, and a
time-tree which just stores unsticky buffers. The time-tree only
needs to store unsticky buffers since they're the only ones which can
be aged away.
I was going
I've attached the 2nd part of the "--" patch.
On Fri, Apr 18, 2014 at 12:39 PM, J Raynor wrote:
> On Thu, Apr 17, 2014 at 8:04 AM, Nicholas Marriott
> wrote:
>> Applied this to OpenBSD now with the const char * thing fixed. Thanks
>
> Ok. I'll wait unt
I kept passing in global_buffers since that's what the existing code
did, and I thought there might be a reason (planned future
functionality?), so I kept it. But it makes sense to not pass it in
if you don't expect other paste_stores. But why not do the same with
buffer-limit? paste_add can loo
> Only bit I don't like now is passing return from xstrdup() to xrealloc()
> in cmd_stringify_argv, better just to start len = 1 and x = 0.
I've attached a new patch. The only difference is the implementation
of cmd_stringify_argv, which I've altered to remove what you disliked.
diff --git a/cmd-
> Yes I think we could do the same with buffer-limit now it is global too.
Ok, I'll do that.
> I think let's not limit the length or charset of names for now, if someone
> sets it to something silly it'll be a display issue only and their own fault
> anyway.
Ok, I'll remove the restrictions.
>
I've attached a new patch. It's the patch you just recently sent with
the following modifications:
1. buffer-limit isn't passed to paste_set. paste_add is the only
paste function that needs it now, and it'll look it up itself.
2. The length and character restrictions for buffer names have been
Sorry, I made an off-by-one error in cmd_stringify_argv. I've
attached a new patch.
On Thu, Apr 24, 2014 at 5:42 PM, J Raynor wrote:
>> Only bit I don't like now is passing return from xstrdup() to xrealloc()
>> in cmd_stringify_argv, better just to start len = 1 and x =
I've attached a patch which implements xterm's title stack
functionality for screens inside tmux.
diff --git a/input.c b/input.c
index b6c27cb..c7bf0a2 100644
--- a/input.c
+++ b/input.c
@@ -1493,8 +1493,6 @@ input_csi_dispatch_winops(struct input_ctx *ictx)
/* FALLTHROUGH */
case 9:
case
It looks like there's a memory leak in cmd_find_window_exec. This
function calls cmd_find_window_match, which allocates memory to
find_data.list_ctx using xstrdup or xasprintf.
cmd_find_window_exec then uses this allocated string in a call to
format_add, but never frees it. I've attached a patch
>
>
> On Wed, Apr 30, 2014 at 10:55:49PM -0500, J Raynor wrote:
>> I've attached a patch which implements xterm's title stack
>> functionality for screens inside tmux.
--
"Accelerate Dev
I've attached a new patch which drops the buffer_stickiness format and
includes changes to the man page.
On Thu, May 1, 2014 at 5:33 PM, Nicholas Marriott
wrote:
> Hi
>
> This looks good thanks, but I'd lose the buffer_stickiness format and just add
> buffer_name.
>
> (Even if we want it flag fo
My patch isn't correct. It misses the case where there's only 1 item
in find_list.
I've attached a new patch which should correctly free the memory.
On Thu, May 1, 2014 at 1:48 AM, J Raynor wrote:
> It looks like there's a memory leak in cmd_find_window_exec.
I've attached a patch that just updates the man page. If this patch
is acceptable, let me know if you would like this combined with the
patch for the code into a single patch.
On Thu, May 8, 2014 at 2:41 AM, Nicholas Marriott
wrote:
> This looks good, it needs to go in the man page, but I'm not
Do you mean order everything by time when displaying the buffers in
buffer-list and buffer-choose? Or do you mean order everything by
time in all cases, so that paste_get_top refers to the most recent
buffer, even if it is !automatic?
If it's the former, that sounds fine. If it's the latter, tha
> If we supported it outside tmux it would add something useful but even
> then I'm not convinced the status quo isn't good enough.
Ok. I'll drop it. It can be revisited if people start requesting the feature.
--
Is you
> Only need to change paste_cmp_times, paste_(get|free)_top and remove the
> RB_INSERT and REMOVE from paste_rename:
I think paste_set needs to be modified as well. When it replaces a
buffer, it frees the old one and mallocs a new one. The new one needs
to have pb->order set to paste_next_order+
When you installed tmux via cygwin, you might’ve updated some other packages
that brought new behavior. I have to do some more checking, but it looks like
cygwin might have changed something recently so that it doesn’t set errno when
it can’t connect to an existing socket file, and this confuse
1 - 100 of 132 matches
Mail list logo
