Note that option UserCommands is deprecated - does it also happen with CtxMenuCommands?
Your invocation step 1. suggests you're starting mintty from a Windows cmd. In that case however, you'd normally not have env or bash in the path, so your path may be extended to include the cygwin bin directory? Also the cygwin path, for access to the test script, may not be included in that case. So the test case isn't yet fully described and I cannot reproduce it right now.
About note 2: which bash do you actually get? (uname) Say /bin/bash to make sure you're getting cygwin bash.

Also, as long as I can't reproduce this, please try to strip down the test case further:

• mintty parameters (is -t needed?)
• same effect if the menu item is selected by mouse rather than key?
• Is the Ctrl a in UserCommands needed?
• Is the env command needed?
• Since an issue with "here strings" (<<<) was recently reported on the cygwin mailing list, replace that with echo "$MINTTY_BUFFER" | less
• By "crash" you mean that the first mintty (the one to open the context menu, not the one started from the script) gets terminated? Can you build a debug version (make DEBUG=1) and provide the stacktrace?

Thanks for looking into this! First, good news:

CopyTab option

I have narrowed the issue down to a ~/.minttyrc with only these two lines:

CtxMenuFunctions=&test:`mintty-usercmd-test`;
CopyTab=yes

mintty only crashes with the CopyTab=yes option.

Answers

Before I found out about CopyTab, I already wrote down answers to your questions. Maybe you don't need them anymore, but here they are:

By "crash" you mean that the first mintty (the one to open the context menu, not the one started from the script) gets terminated?

Yes.

Your invocation step 1. suggests you're starting mintty from a Windows cmd. In that case however, you'd normally not have env or bash in the path, so your path may be extended to include the cygwin bin directory? Also the cygwin path, for access to the test script, may not be included in that case. So the test case isn't yet fully described and I cannot reproduce it right now.

But all that would equally apply to note 1 "Same with printf 'a b\n' (space instead of tab) works". By that I meant: The new mintty instance starts and runs less with the expected contents. So my PATH is not the problem, and I should probably just have left out note 2, which is probably irrelevant. In the meantime, I have verified with a deliberately (not by my test script) startet WSL bash, that Cygwin pstree does not show WSL bash, so the bash inside the user command is really Cygwin.

About note 2: which bash do you actually get? (uname) Say /bin/bash to make sure you're getting cygwin bash.

"CYGWIN_NT-10.0-22631 <my hostname> 3.5.1-1.x86_64 2024-02-27 11:54 UTC x86_64 Cygwin"
This is from within the test script invoked as a user command. (I added uname -a >> /tmp/uname.log; to the bash -c.)

mintty parameters (is -t needed?)

No. This mintty-usercmd-test is also sufficient to crash:

#!/bin/bash
cmd='less <<<"${MINTTY_BUFFER}"'
mintty -e env bash -c "$cmd" &

same effect if the menu item is selected by mouse rather than key?

Yes.

• Opening the context menu by key, then clicking it with the mouse: crashes too.
• I commented out MenuCtrlMenu option in ~/.minttyrc and started the user command with Ctrl RMB, then LMB on "test": crashes too.

Is the Ctrl a in UserCommands needed?

No. Same behavior without it. That was just the separator I usually use when I have multiple user commands configured.

Is the env command needed?

No. This mintty-usercmd-test is also sufficient to crash:

#!/bin/bash
cmd='less <<<"${MINTTY_BUFFER}"'
mintty -e bash -c "$cmd" &

Since an issue with "here strings" (<<<) was recently reported on the cygwin mailing list, replace that with echo "$MINTTY_BUFFER" | less

Still crashes with

#!/bin/bash
cmd='echo "${MINTTY_BUFFER}" | less'
mintty -e bash -c "$cmd" &

Note that option UserCommands is deprecated - does it also happen with CtxMenuCommands?

Yes. I checked with

CtxMenuFunctions=&test:`mintty-usercmd-test`;

Can you build a debug version (make DEBUG=1) and provide the stacktrace?

I have built it, but Windows Security does not let me start it yet. I probably will in a few days, though.

Thanks. And the extra script isn't needed either, the following config is sufficient:

UserCommands=copy with tabs:copy-tabs
CopyTab=yes

UserCommands=copy with tabs:copy-tabs

I confused config features here. But actually UserCommands=any cmd:true is sufficient.

Released 3.7.2.