Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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 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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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... cygwrap.btm Description: Binary data fix-path.btm Description: Binary data -- 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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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...
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
Re: [ANNOUNCEMENT] Updated: mintty 2.9.5
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
