[ANNOUNCEMENT] Updated: mintty 2.9.5

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANNOUNCEMENT] Updated: mintty 2.9.5

Thomas Wolff
I have uploaded mintty 2.9.5 with the following changes:

Window handling
   * Fixed startup directory after cloning new window after starting
from desktop shortcut (#784, mintty/wsltty#96).
   * Avoiding stale hover indication in unfocussed window.
   * Changed default handling of resolution change to HandleDPI=2 (#824).

Tweaks to HTML clipboard/export feature
   * Flexible HTML formatting levels.
   * Configurable, also in Options dialog.
   * No more table cell container.
   * HTML escaping.
   * Apply styles individually and other tweaks for increased compatibility.
   * Font fallback 'monospace'.
   * Find relative HTML file name on Shift+"HTML Screen Dump".

Configuration
   * CopyAsHTML (#825, #811).

Other
   * Ensuring /bin in PATH for user commands.

The homepage is at http://mintty.github.io/
It also links to the issue tracker.

------
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Achim Gratz
Thomas Wolff writes:
> Other
>   * Ensuring /bin in PATH for user commands.

Blindly prepending /bin to the existing PATH is asking for trouble with
certain setups.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Thomas Wolff
Am 05.12.2018 um 21:21 schrieb Achim Gratz:
> Thomas Wolff writes:
>> Other
>>    * Ensuring /bin in PATH for user commands.
> Blindly prepending /bin to the existing PATH is asking for trouble with certain setups.
Just to clarify, this is only applicable to user-defined commands added
to the extended context menu (option UserCommands), in order to ensure
basic tools are available. If you see problems there, please be more
specific.
Kind regards,
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Andrey Repin
Greetings, Thomas Wolff!

> Am 05.12.2018 um 21:21 schrieb Achim Gratz:
>> Thomas Wolff writes:
>>> Other
>>>    * Ensuring /bin in PATH for user commands.
>> Blindly prepending /bin to the existing PATH is asking for trouble with certain setups.
> Just to clarify, this is only applicable to user-defined commands added
> to the extended context menu (option UserCommands), in order to ensure
> basic tools are available. If you see problems there, please be more
> specific.

Yes, I see problem there.
I have Cygwin in my regular %PATH% at the place I want it. I.e. when using
tools and commands, I expect them to behave in a certain way.
Changing it have potential to produce unexpected results.


--
With best regards,
Andrey Repin
Thursday, December 6, 2018 3:16:03

Sorry for my terrible english...
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Thomas Wolff

Am 06.12.2018 um 01:18 schrieb Andrey Repin:

> Greetings, Thomas Wolff!
>
>> Am 05.12.2018 um 21:21 schrieb Achim Gratz:
>>> Thomas Wolff writes:
>>>> Other
>>>>     * Ensuring /bin in PATH for user commands.
>>> Blindly prepending /bin to the existing PATH is asking for trouble with certain setups.
>> Just to clarify, this is only applicable to user-defined commands added
>> to the extended context menu (option UserCommands), in order to ensure
>> basic tools are available. If you see problems there, please be more
>> specific.
> Yes, I see problem there.
> I have Cygwin in my regular %PATH% at the place I want it. I.e. when using
> tools and commands, I expect them to behave in a certain way.
> Changing it have potential to produce unexpected results.
The issue that caused me to apply this change: if you start mintty from
a desktop shortcut, cygwin /bin is not in the PATH of mintty (unless you
would set it globally in Windows, which is discouraged). It will be
inside your login shell, of course, but user commands are spawned from
mintty directly.
I could append rather than prepend /bin, but then another tool like
`sed` might be in the path and user commands behave unexpectedly. I
could also check whether it's in PATH already, and then prepend.
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

cyg Simple
On 12/6/2018 2:22 AM, Thomas Wolff wrote:

>
> Am 06.12.2018 um 01:18 schrieb Andrey Repin:
>> Greetings, Thomas Wolff!
>>
>>> Am 05.12.2018 um 21:21 schrieb Achim Gratz:
>>>> Thomas Wolff writes:
>>>>> Other
>>>>>     * Ensuring /bin in PATH for user commands.
>>>> Blindly prepending /bin to the existing PATH is asking for trouble
>>>> with certain setups.
>>> Just to clarify, this is only applicable to user-defined commands added
>>> to the extended context menu (option UserCommands), in order to ensure
>>> basic tools are available. If you see problems there, please be more
>>> specific.
>> Yes, I see problem there.
>> I have Cygwin in my regular %PATH% at the place I want it. I.e. when
>> using
>> tools and commands, I expect them to behave in a certain way.
>> Changing it have potential to produce unexpected results.
> The issue that caused me to apply this change: if you start mintty from
> a desktop shortcut, cygwin /bin is not in the PATH of mintty (unless you
> would set it globally in Windows, which is discouraged). It will be
> inside your login shell, of course, but user commands are spawned from
> mintty directly.
> I could append rather than prepend /bin, but then another tool like
> `sed` might be in the path and user commands behave unexpectedly. I
> could also check whether it's in PATH already, and then prepend.

Please make it optional.  And rather than prepend doing an append might
avoid the conflicts described by Andrey.

--
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Achim Gratz
In reply to this post by Thomas Wolff
Thomas Wolff writes:
> Am 05.12.2018 um 21:21 schrieb Achim Gratz:
>> Thomas Wolff writes:
>>> Other
>>>    * Ensuring /bin in PATH for user commands.
>> Blindly prepending /bin to the existing PATH is asking for trouble with certain setups.
> Just to clarify, this is only applicable to user-defined commands
> added to the extended context menu (option UserCommands), in order to
> ensure basic tools are available. If you see problems there, please be
> more specific.

I'm not using this option, so my remark was just to remind you that
second-guessing the user w.r.t. PATH will eventually find at least one
user in an unfortunate (and in this case hard to debug) situation.  So
the usual advice applies:

a) Just warn about the missing PATH component without changing the PATH.
b) Give the user an option to let the command run with a separate PATH.

Indeed there might be other things that are missing in the environment,
so instead of just fixing up PATH you might consider using a wrapper
that the user can change.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Andrey Repin
Greetings, Achim Gratz!

> a) Just warn about the missing PATH component without changing the PATH.
> b) Give the user an option to let the command run with a separate PATH.

> Indeed there might be other things that are missing in the environment,
> so instead of just fixing up PATH you might consider using a wrapper
> that the user can change.

This is an interesting point.
Probably letting the user specify custom $PATH for quick commands (and save
current %PATH% as $ORIGINAL_PATH) may be the best choice.
The default can be %Cygwin%\bin:%PATH% or %PATH%:%Cygwin%\bin, I'm not very
concerned as long as it's explicit and customizable.
If anybody need a wrapper, they may write and use it by themselves.

(I already have one, written in TCC, working quite well.)


--
With best regards,
Andrey Repin
Friday, December 7, 2018 0:15:56

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

[ANNOUNCEMENT] Updated: mintty 2.9.5

Brian Inglis
In reply to this post by Achim Gratz
On 2018-12-06 12:39, Achim Gratz wrote:
> Thomas Wolff writes:
>> Am 05.12.2018 um 21:21 schrieb Achim Gratz:
>>> Thomas Wolff writes:
>>>> Ensuring /bin in PATH for user commands.
>>> Blindly prepending /bin to the existing PATH is asking for trouble with
>>> certain setups.

Many setups: my Windows User PATH includes Cygwin {,/usr/local}/{,s}bin and the
Windows System PATH, and my login scripts append new Cygwin paths before any
Windows paths, used to allow interop using Cygwin and Windows consoles with
Cygwin and non-Cygwin apps, which may only or also be available in MinGW/native
exes e.g. BitKeeper.

>> Just to clarify, this is only applicable to user-defined commands
>> added to the extended context menu (option UserCommands), in order to
>> ensure basic tools are available. If you see problems there, please be
>> more specific.
>
> I'm not using this option, so my remark was just to remind you that
> second-guessing the user w.r.t. PATH will eventually find at least one
> user in an unfortunate (and in this case hard to debug) situation.  So
> the usual advice applies:
>
> a) Just warn about the missing PATH component without changing the PATH.

after checking to see if the expected /bin is already present

> b) Give the user an option to let the command run with a separate PATH.

++

> Indeed there might be other things that are missing in the environment,
> so instead of just fixing up PATH you might consider using a wrapper
> that the user can change.

Maybe allow an env config file with comments, blank lines, env var definitions
with values including embedded single and double quotes, env var refs, and one
optional prefix command e.g. export, set, setenv, etc. which could be ignored
when used without a definition e.g. "export PATH" rather than "export PATH=...".

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Thomas Wolff
In reply to this post by Andrey Repin
Am 06.12.2018 um 22:32 schrieb Andrey Repin:

> Greetings, Achim Gratz!
>
>> a) Just warn about the missing PATH component without changing the PATH.
>> b) Give the user an option to let the command run with a separate PATH.
>> Indeed there might be other things that are missing in the environment,
>> so instead of just fixing up PATH you might consider using a wrapper
>> that the user can change.
> This is an interesting point.
> Probably letting the user specify custom $PATH for quick commands (and save
> current %PATH% as $ORIGINAL_PATH) may be the best choice.
> The default can be %Cygwin%\bin:%PATH% or %PATH%:%Cygwin%\bin, I'm not very
> concerned as long as it's explicit and customizable.
I didn't expect the setup of this specific feature to be so strongly
advocated :)
In any case, things shouldn't become too complex. What I can image is an
option UserCommandsPATH
with one optional placeholder %s which would be replaced with the
environment PATH;
default /bin:%s, corresponding to current behaviour.

> If anybody need a wrapper, they may write and use it by themselves.
>
> (I already have one, written in TCC, working quite well.)
Out of curiosity, what's TCC and what does your wrapper do?

Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Andrey Repin
Greetings, Thomas Wolff!

> Am 06.12.2018 um 22:32 schrieb Andrey Repin:
>> Greetings, Achim Gratz!
>>
>>> a) Just warn about the missing PATH component without changing the PATH.
>>> b) Give the user an option to let the command run with a separate PATH.
>>> Indeed there might be other things that are missing in the environment,
>>> so instead of just fixing up PATH you might consider using a wrapper
>>> that the user can change.
>> This is an interesting point.
>> Probably letting the user specify custom $PATH for quick commands (and save
>> current %PATH% as $ORIGINAL_PATH) may be the best choice.
>> The default can be %Cygwin%\bin:%PATH% or %PATH%:%Cygwin%\bin, I'm not very
>> concerned as long as it's explicit and customizable.
> I didn't expect the setup of this specific feature to be so strongly
> advocated :)
> In any case, things shouldn't become too complex. What I can image is an
> option UserCommandsPATH
> with one optional placeholder %s which would be replaced with the
> environment PATH;
> default /bin:%s, corresponding to current behaviour.
Using native paths and environment variable syntax, you can always use
ExpandEnvironmentString to get the %PATH% you need.
Cygwin DLL will then convert it to own version, avoiding you mangling it
yourself.
And I would strongly discourage from using placeholders familiar for you, but
unexpected by the end user and taken from entirely different area of knowledge.

BTW, Cygwin itself does it differently. %Cygwin%\bin is converted to /usr/bin.

>> If anybody need a wrapper, they may write and use it by themselves.
>>
>> (I already have one, written in TCC, working quite well.)
> Out of curiosity, what's TCC and what does your wrapper do?

This is an augmented CMD-like scripting platform.
https://jpsoft.com/products/tcc-cmd-prompt.html

Its "runtime" variant, TCC-RT, contains only scripting core, no interactive
functionality, and is distributed for free.

I attached the pair of scripts that I use to wrap .sh/.awk/.pl/etc. with.
In manual mode, I can use it to launch any script provided /usr/bin/env can
deal with it, as it's basically a wrapper around /usr/bin/env, which ensures
that the first argument (the script name) has Cygwin notation.
The fix-path thing is necessary to tweak startup behavior. Normal operation
environment don't have /usr/local/bin in %PATH%, as that hides some
Cygwin-specific scripts which have native counterparts in a different place.

P.S.
The %[variable] notation I use is not strictly necessary.
%var or %var% works equally well, but may be disabled in options.
I'm just playing on the safe side.


--
With best regards,
Andrey Repin
Saturday, December 8, 2018 0:16:49

Sorry for my terrible english...

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

cygwrap.btm (1010 bytes) Download Attachment
fix-path.btm (396 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Thomas Wolff
Am 07.12.2018 um 22:41 schrieb Andrey Repin:

> Greetings, Thomas Wolff!
>
>> Am 06.12.2018 um 22:32 schrieb Andrey Repin:
>>> Greetings, Achim Gratz!
>>>
>>>> a) Just warn about the missing PATH component without changing the PATH.
>>>> b) Give the user an option to let the command run with a separate PATH.
>>>> Indeed there might be other things that are missing in the environment,
>>>> so instead of just fixing up PATH you might consider using a wrapper
>>>> that the user can change.
>>> This is an interesting point.
>>> Probably letting the user specify custom $PATH for quick commands (and save
>>> current %PATH% as $ORIGINAL_PATH) may be the best choice.
>>> The default can be %Cygwin%\bin:%PATH% or %PATH%:%Cygwin%\bin, I'm not very
>>> concerned as long as it's explicit and customizable.
>> I didn't expect the setup of this specific feature to be so strongly
>> advocated :)
>> In any case, things shouldn't become too complex. What I can image is an
>> option UserCommandsPATH
>> with one optional placeholder %s which would be replaced with the
>> environment PATH;
>> default /bin:%s, corresponding to current behaviour.
> Using native paths and environment variable syntax, you can always use
> ExpandEnvironmentString to get the %PATH% you need.
> Cygwin DLL will then convert it to own version, avoiding you mangling it
> yourself.
> And I would strongly discourage from using placeholders familiar for you, but
> unexpected by the end user and taken from entirely different area of knowledge.
>
> BTW, Cygwin itself does it differently. %Cygwin%\bin is converted to /usr/bin.
This setup should be handled in the Posix path domain. I've uploaded a
patch for evaluation, to the github repository.
Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Andrey Repin
Greetings, Thomas Wolff!

> Am 07.12.2018 um 22:41 schrieb Andrey Repin:
>> Greetings, Thomas Wolff!
>>
>>> Am 06.12.2018 um 22:32 schrieb Andrey Repin:
>>>> Greetings, Achim Gratz!
>>>>
>>>>> a) Just warn about the missing PATH component without changing the PATH.
>>>>> b) Give the user an option to let the command run with a separate PATH.
>>>>> Indeed there might be other things that are missing in the environment,
>>>>> so instead of just fixing up PATH you might consider using a wrapper
>>>>> that the user can change.
>>>> This is an interesting point.
>>>> Probably letting the user specify custom $PATH for quick commands (and save
>>>> current %PATH% as $ORIGINAL_PATH) may be the best choice.
>>>> The default can be %Cygwin%\bin:%PATH% or %PATH%:%Cygwin%\bin, I'm not very
>>>> concerned as long as it's explicit and customizable.
>>> I didn't expect the setup of this specific feature to be so strongly
>>> advocated :)
>>> In any case, things shouldn't become too complex. What I can image is an
>>> option UserCommandsPATH
>>> with one optional placeholder %s which would be replaced with the
>>> environment PATH;
>>> default /bin:%s, corresponding to current behaviour.
>> Using native paths and environment variable syntax, you can always use
>> ExpandEnvironmentString to get the %PATH% you need.
>> Cygwin DLL will then convert it to own version, avoiding you mangling it
>> yourself.
>> And I would strongly discourage from using placeholders familiar for you, but
>> unexpected by the end user and taken from entirely different area of knowledge.
>>
>> BTW, Cygwin itself does it differently. %Cygwin%\bin is converted to /usr/bin.
> This setup should be handled in the Posix path domain.

Give me a good reason why should you second-guess Cygwin's own functionality?

> I've uploaded a
> patch for evaluation, to the github repository.
> Thomas


--
With best regards,
Andrey Repin
Monday, December 10, 2018 5:01:12

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Thomas Wolff
Am 10.12.2018 um 03:01 schrieb Andrey Repin:

> Greetings, Thomas Wolff!
>
>> Am 07.12.2018 um 22:41 schrieb Andrey Repin:
>>> Greetings, Thomas Wolff!
>>>
>>>> Am 06.12.2018 um 22:32 schrieb Andrey Repin:
>>>>> Greetings, Achim Gratz!
>>>>>
>>>>>> a) Just warn about the missing PATH component without changing the PATH.
>>>>>> b) Give the user an option to let the command run with a separate PATH.
>>>>>> Indeed there might be other things that are missing in the environment,
>>>>>> so instead of just fixing up PATH you might consider using a wrapper
>>>>>> that the user can change.
>>>>> This is an interesting point.
>>>>> Probably letting the user specify custom $PATH for quick commands (and save
>>>>> current %PATH% as $ORIGINAL_PATH) may be the best choice.
>>>>> The default can be %Cygwin%\bin:%PATH% or %PATH%:%Cygwin%\bin, I'm not very
>>>>> concerned as long as it's explicit and customizable.
>>>> I didn't expect the setup of this specific feature to be so strongly
>>>> advocated :)
>>>> In any case, things shouldn't become too complex. What I can image is an
>>>> option UserCommandsPATH
>>>> with one optional placeholder %s which would be replaced with the
>>>> environment PATH;
>>>> default /bin:%s, corresponding to current behaviour.
>>> Using native paths and environment variable syntax, you can always use
>>> ExpandEnvironmentString to get the %PATH% you need.
>>> Cygwin DLL will then convert it to own version, avoiding you mangling it
>>> yourself.
>>> And I would strongly discourage from using placeholders familiar for you, but
>>> unexpected by the end user and taken from entirely different area of knowledge.
>>>
>>> BTW, Cygwin itself does it differently. %Cygwin%\bin is converted to /usr/bin.
>> This setup should be handled in the Posix path domain.
> Give me a good reason why should you second-guess Cygwin's own functionality?
You have apparently set up some cmd scripts as mintty user commands, so
you're thinking in Windows terms here. However, the idea is more to use
cygwin tools for such purposes. In either case, the path is handled
within a cygwin session (mintty) and cygwin does the conversion both
ways, so it should be fine for you.
Thomas

>
>> I've uploaded a
>> patch for evaluation, to the github repository.
>> Thomas

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Andrey Repin
Greetings, Thomas Wolff!

>>>> BTW, Cygwin itself does it differently. %Cygwin%\bin is converted to /usr/bin.
>>> This setup should be handled in the Posix path domain.
>> Give me a good reason why should you second-guess Cygwin's own functionality?
> You have apparently set up some cmd scripts as mintty user commands, so
> you're thinking in Windows terms here.

One is very distantly related to another.
I set up programs to work as user commands, it's not actually relevant, if
they are cmd scripts, or perl, both, or neither.

> However, the idea is more to use cygwin tools for such purposes. In either
> case, the path is handled within a cygwin session (mintty) and cygwin does
> the conversion both ways, so it should be fine for you.

The path is handled within a **cygwin** session, but mintty is not it.
And you don't have to second-guess cygwin behavior, if you do it the way I
propose. And you would be safe if behavior would one day change (though I do
not foresee it in this case).

P.S.
I've tried to do it "your way" for tests.
Had enough of an issue starting Cygwin itself and rolled it back.
Cygwin already quite capable of path conversion, no need to deny it this
ability.


--
With best regards,
Andrey Repin
Monday, December 10, 2018 15:54:44

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Thomas Wolff
Hello Andrey,

On 10.12.2018 14:08, Andrey Repin wrote:

> Greetings, Thomas Wolff!
>
>>>>> BTW, Cygwin itself does it differently. %Cygwin%\bin is converted to /usr/bin.
>>>> This setup should be handled in the Posix path domain.
>>> Give me a good reason why should you second-guess Cygwin's own functionality?
>> You have apparently set up some cmd scripts as mintty user commands, so
>> you're thinking in Windows terms here.
> One is very distantly related to another.
> I set up programs to work as user commands, it's not actually relevant, if
> they are cmd scripts, or perl, both, or neither.
Acknowledged.

>> However, the idea is more to use cygwin tools for such purposes. In either
>> case, the path is handled within a cygwin session (mintty) and cygwin does
>> the conversion both ways, so it should be fine for you.
> The path is handled within a **cygwin** session, but mintty is not it.
Sure mintty is a cygwin program, linked with cygwin and thus starting a
cygwin session.

> And you don't have to second-guess cygwin behavior, if you do it the way I
> propose. And you would be safe if behavior would one day change (though I do
> not foresee it in this case).
I'm not tampering with cygwin behaviour in any way, just changing PATH,
so that a tool subsequently invoked by `popen` can use it.

> P.S.
> I've tried to do it "your way" for tests.
> Had enough of an issue starting Cygwin itself and rolled it back.
> Cygwin already quite capable of path conversion, no need to deny it this ability.
Not sure whether you're having a problem with your mintty command
scripts. I've tested this thoroughly, everything works fine in these
configuration combinations, with a test script D:\bin\test.cmd that
echoes %MINTTY_SELECT% attached to keyboard shortcut Ctrl+Shift+t:

KeyFunctions=t:`test.cmd`
UserCommandsPath=D:\bin:%s

KeyFunctions=t:`test.cmd`
UserCommandsPath=/cygdrive/d/bin:%s

KeyFunctions=t:`D:/bin/test.cmd`
#UserCommandsPath=

KeyFunctions=t:`/cygdrive/d/bin/test.cmd`
#UserCommandsPath=

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply | Threaded
Open this post in threaded view
|

Re: [ANNOUNCEMENT] Updated: mintty 2.9.5

Achim Gratz
In reply to this post by Thomas Wolff
Thomas Wolff writes:

> Tweaks to HTML clipboard/export feature
>   * Flexible HTML formatting levels.
>   * Configurable, also in Options dialog.
>   * No more table cell container.
>   * HTML escaping.
>   * Apply styles individually and other tweaks for increased compatibility.
>   * Font fallback 'monospace'.
>   * Find relative HTML file name on Shift+"HTML Screen Dump".
>
> Configuration
>   * CopyAsHTML (#825, #811).

I could only test this today, so here is my belated confirmation that
copy&paste is working again for my use-case.  Thanks!


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple