Re: SSH config in /etc/ssh/ rather than /etc?
On Tue, Apr 11, 2023 at 6:28 PM Philippe Cerfon via Cygwin wrote: > I've just wondered whether Cygwin packages could be changed to > place/expect any SSH config files in /etc/ssh, just as virtually any > Linux distribution seems to do? :-) Symlinks are your friend. You can even use real (Windows) symlinks to make things more uniform. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
have cygwin setup.exe signed and/or in the MS store
Hey there. I know you provide OpenPGP signatures for verification (which is good, and should be kept), but would it perhaps make sense to have setup.exe signed (in the sense of: by some MS trusted certificate) and/or in the MS store (though I guess that might not be possible with their policy)? Regards, Philippe. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
SSH config in /etc/ssh/ rather than /etc?
Hey. I've just wondered whether Cygwin packages could be changed to place/expect any SSH config files in /etc/ssh, just as virtually any Linux distribution seems to do? :-) Regards, Philippe -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: pinfo build fails with undefined macro: AM_INTL_SUBDIR
> On Apr 11 09:21, Andrew Schulman via Cygwin-apps wrote: > > I'm trying to rebuild pinfo 0.6.13. That's the current version in Cygwin, > > so I > > know I was able to build it successfully a couple of years ago. But now > > when I > > try, the build fails with > > > > error: possibly undefined macro: AM_INTL_SUBDIR > > Check configure.ac which version of autotools is required. There's a > good chance you need autoconf 2.69. You can probably fix that problem > in the cygport file by adding > > WANT_AUTOCONF="2.5" Thanks. I tried several different values of WANT_AUTOCONF and WANT_AUTOMAKE, but they didn't help. From what I can tell, AM_INTL_SUBDIR is just gone from automake now. So I removed the call to AM_INTL_SUBDIR, and that build problem is fixed. Anyway thanks for pointing me in a direction. Andrew
Re: Changing user home to overlap Windows user home possible? Or a bad idea?
Greetings, Thomas Schweikle!
> Am Sa., 08.Apr..2023 um 10:30:47 schrieb Andrey Repin:
>> Greetings, Thomas Schweikle!
>> >> Is it possible to have the same home for Windows and cygwin?
>> > See /etc/nsswitch.conf and
>> > https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
>> >> Using "C:\Users\" for Cygwin home setting mount points for users?
>> > I don't get this question. Can you please rephrase?
> I've tried to set
> C:/Users /home ntfs binary,posix=0,nouser 0 0
+,noacl
> Then have "C:/Users/..." and "/home/..." the same.
That's an option, but not without side-effects.
> Did not work this way. Starting some shell got cygwin exhaust "Could not
> create "/home/" -- true: the directory was there already, but cygwin
> did not notice. Can't tell why. I could switch to /home/, while cygwin
> couldn't setting $HOME to /tmp. I had success with
> mklink /D C:\cygwin\home C:\Users
> and then setting /etc/nsswitch.conf to
> db_home: /home/%U
> this did the trick: cygwin starting a shell works now as expected.
> One last problem: the owner of the files was not the one expected. Could
> change him to the expected one using windows tools.
But then Cygwin tools would complain.
> The remaining problems are all git related: git seems to have problems
> creating symlinks for clones. Maybe this is just a case enabling privileges
> via GPO for users needing them.
I suggest you do NOT use symlinks with git. The very idea is unstable and
error prone.
Other than that, it depends, which sources and which symlinks you are using.
> Looks like some sources fail to compile if symlinks are not available.
>>> Or is this a bad idea? Or is it something which has some drawbacks you've
>>> to decide to live with? At the moment the most ugly drawback is duplication
>>> of various data needed within "C:\cygwin\home\" and "C:\Users\".
>>> Would be nice if I could overlay both.
>> There's some caveats to using %USERPROFILE% as $HOME, most notable, you have
>> to be careful with overly sensitive programs, like SSH or GPG. Other than
>> that, the noacl flag on the cygdrive mount will cover you for the time being.
>> I.e.:
> This was why I tried to mount C:\Users to /home, having two identical
> directories making ssh, gpg and others happy.
No. That will NOT make gpg and ssh happy.
Quite the opposite, using noacl mount as default home, ssh and gpg will
complain about incorrect permissions on their configuration directories.
Or, if you do not mount users root with noacl, Cygwin will attempt to treat
profile as POSIX directory, potentially wreaking havoc on files and
directories for Windows programs not expecting such surprise.
What I did, I made a symlink to /home/$user/.{gnupg,ssh} in my profile
directory. Thus the permissions on the respective directories are matching the
POSIX standard, but parent directory (profile) permissions do not affect them.
none /cygdrive cygdrive noacl,binary,nouser,posix=0 0 0
>> And usertemp idea is also a good one:
none /tmp usertemp binary,nouser,posix=0 0 0
> This was helpful. It is a little bit problematic switching users, but it is
> lots better than having a global /tmp for all users.
--
With best regards,
Andrey Repin
Wednesday, April 12, 2023 00:59:45
Sorry for my terrible english...
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 'cp' command is still slow after Cygserver is installed
On Tue, Apr 11, 2023 at 10:08 PM Derek Pagel via Cygwin wrote: > > I've been seeing an issue where Cygwin commands sometimes take a while to > complete, or they will not complete at all and will have to be manually > killed through task manager. I installed Cygserver and that helped to lessen > the number of times that the issue happens but it didn't get rid of it. I'm > wondering if anyone has run into the same behavior. I've also shared the .dmp > files of a 'cp' command that was taking a while to complete in case that > helps: > how big are these files and from where to where are you copying them ? AV interference ? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Changing user home to overlap Windows user home possible? Or a bad idea?
Hi! Am Sa., 08.Apr..2023 um 10:30:47 schrieb Andrey Repin: Greetings, Thomas Schweikle! Is it possible to have the same home for Windows and cygwin? See /etc/nsswitch.conf and https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch Using "C:\Users\" for Cygwin home setting mount points for users? I don't get this question. Can you please rephrase? I've tried to set C:/Users /home ntfs binary,posix=0,nouser 0 0 Then have "C:/Users/..." and "/home/..." the same. Did not work this way. Starting some shell got cygwin exhaust "Could not create "/home/" -- true: the directory was there already, but cygwin did not notice. Can't tell why. I could switch to /home/, while cygwin couldn't setting $HOME to /tmp. I had success with mklink /D C:\cygwin\home C:\Users and then setting /etc/nsswitch.conf to db_home: /home/%U this did the trick: cygwin starting a shell works now as expected. One last problem: the owner of the files was not the one expected. Could change him to the expected one using windows tools. The remaining problems are all git related: git seems to have problems creating symlinks for clones. Maybe this is just a case enabling privileges via GPO for users needing them. Looks like some sources fail to compile if symlinks are not available. Or is this a bad idea? Or is it something which has some drawbacks you've to decide to live with? At the moment the most ugly drawback is duplication of various data needed within "C:\cygwin\home\" and "C:\Users\". Would be nice if I could overlay both. There's some caveats to using %USERPROFILE% as $HOME, most notable, you have to be careful with overly sensitive programs, like SSH or GPG. Other than that, the noacl flag on the cygdrive mount will cover you for the time being. I.e.: This was why I tried to mount C:\Users to /home, having two identical directories making ssh, gpg and others happy. none /cygdrive cygdrive noacl,binary,nouser,posix=0 0 0 And usertemp idea is also a good one: none /tmp usertemp binary,nouser,posix=0 0 0 This was helpful. It is a little bit problematic switching users, but it is lots better than having a global /tmp for all users. -- Thomas OpenPGP_0x27AE2304B4974851.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Cygwin 'cp' command is still slow after Cygserver is installed
I've been seeing an issue where Cygwin commands sometimes take a while to
complete, or they will not complete at all and will have to be manually killed
through task manager. I installed Cygserver and that helped to lessen the
number of times that the issue happens but it didn't get rid of it. I'm
wondering if anyone has run into the same behavior. I've also shared the .dmp
files of a 'cp' command that was taking a while to complete in case that helps:
cp.dmp
Microsoft (R) Windows Debugger Version 10.0.22621.755 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\sandbox\Logs\cp.dmp]
User Mini Dump File with Full Memory: Only application data is available
Symbol search path is: srv*
Executable search path is:
Windows 10 Version 17763 MP (8 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Edition build lab: 17763.1.amd64fre.rs5_release.180914-1434
Machine Name:
Debug session time: Tue Apr 4 11:13:23.000 2023 (UTC - 5:00)
System Uptime: 38 days 11:52:56.830
Process Uptime: 0 days 0:21:50.000
...
For analysis of this file, run !analyze -v
ntdll!NtWaitForSingleObject+0x14:
7ffd`f967f7e4 c3 ret
0:000> !analyze -v
***
* *
*Exception Analysis *
* *
***
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 327
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 1001
Key : Analysis.Init.CPU.mSec
Value: 624
Key : Analysis.Init.Elapsed.mSec
Value: 13453
Key : Analysis.Memory.CommitPeak.Mb
Value: 80
Key : Timeline.OS.Boot.DeltaSec
Value: 3325976
Key : Timeline.Process.Start.DeltaSec
Value: 1310
Key : WER.OS.Branch
Value: rs5_release
Key : WER.OS.Timestamp
Value: 2018-09-14T14:34:00Z
Key : WER.OS.Version
Value: 10.0.17763.1
FILE_IN_CAB: cp.dmp
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress:
ExceptionCode: 8003 (Break instruction exception)
ExceptionFlags:
NumberParameters: 0
FAULTING_THREAD: 19f0
PROCESS_NAME: cp.exe
ERROR_CODE: (NTSTATUS) 0x8003 - {EXCEPTION} Breakpoint A breakpoint has
been reached.
EXCEPTION_CODE_STR: 8003
STACK_TEXT:
`004fe608 7ffd`f61783d3 : ` `
` `004fe720 : ntdll!NtWaitForSingleObject+0x14
`004fe610 `677ea815 : `0001 `
` `00c8 : KERNELBASE!WaitForSingleObjectEx+0x93
`004fe6b0 `677eb688 : ` `00ae6bd0
` ` : msvcr90!_dospawn+0x261
`004fe7d0 `677eb831 : ` `00ae4cb0
` 7931`45513238 : msvcr90!comexecmd+0x78
`004fe820 `677ebd0a : ` `00ae4c20
` ` : msvcr90!_spawnve+0x17d
`004fe890 7ff7`afc11261 : `00ae6bd0 `0003
`004fed20 `004fe920 : msvcr90!system+0xaa
`004fe8f0 7ff7`afc11442 : ` 1e3c`d7e4c5c9
` ` : cp+0x1261
`004ffd40 7ffd`f9227974 : ` `
` ` : cp+0x1442
`004ffd70 7ffd`f964a271 : ` `
` ` : kernel32!BaseThreadInitThunk+0x14
`004ffda0 ` : ` `
` ` : ntdll!RtlUserThreadStart+0x21
STACK_COMMAND: ~0s; .ecxr ; kb
FAULTING_SOURCE_LINE: f:\dd\vctools\crt_bld\self_64_amd64\crt\src\dospawn.c
FAULTING_SOURCE_FILE: f:\dd\vctools\crt_bld\self_64_amd64\crt\src\dospawn.c
FAULTING_SOURCE_LINE_NUMBER: 215
SYMBOL_NAME: msvcr90!_dospawn+261
MODULE_NAME: msvcr90
IMAGE_NAME: msvcr90.dll
FAILURE_BUCKET_ID: BREAKPOINT_8003_msvcr90.dll!_dospawn
OS_VERSION: 10.0.17763.1
BUILDLAB_STR: rs5_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
IMAGE_VERSION: 9.0.30729.9518
FAILURE_ID_HASH: {ae098e47-a4ce-0039-c30c-1cea11724b06}
Followup: MachineOwner
-
cp2.dmp:
Microsoft (R) Windows Debugger Version 10.0.22621.755 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\sandbox\116929941_cp\cp2.dmp]
User Mini Dump File with Full Memory: Only application data is available
Symbol
Re: [ANNOUNCEMENT] cygport 0.36.1-1
On 11/04/2023 05:14, Marco Atzeri wrote: On 26.03.2023 18:43, Jon Turney wrote: On 11/03/2023 20:15, Marco Atzeri via Cygwin-apps wrote: On 11.03.2023 17:29, Jon Turney via Cygwin wrote: The following packages have been uploaded to the Cygwin distribution: * cygport-0.36.1-1 Hi Jon, I was a bit too late... No problem, I can always make more releases! [...] I would any some version of it released before I upload the git source that has only pyproject.toml. Otherwise scullywag will fail the build. I was hoping to make a new release last weekend, but unfortunately that didn't happen. Hopefully I'll have time to do one sometime this week.
Re: issue when piping from a windows program
Greetings, Leonid Mironov! > I am trying to feed the output of wmic.exe - a windows console program, to > cygwin bash script. > wmic.exe produces UTF16LE output with BOM and CR/LFs, so I am using dos2unix > to convert it. > The problem is that when I write wmic.exe output to a file and then use > dos2unix to convert this file > I get the expected result - ASCII file with LFs, I get the same result when I > pipe this file to dos2unix, > but when I pipe wmic.exe output directly to dos2unix I get ASCII file with > CR/LFs and an extra empty line. > Cygwin is up to date, windows 10. What gives? You don't need d2u. Use `… | iconv -f UTF16LE | tr -d '\r'` (Don't even need -t for iconv - it assumes current locale settings as default source/destination encoding.) -- With best regards, Andrey Repin Tuesday, April 11, 2023 17:41:32 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: pinfo build fails with undefined macro: AM_INTL_SUBDIR
On Apr 11 09:21, Andrew Schulman via Cygwin-apps wrote:
> I'm trying to rebuild pinfo 0.6.13. That's the current version in Cygwin, so I
> know I was able to build it successfully a couple of years ago. But now when I
> try, the build fails with
>
> error: possibly undefined macro: AM_INTL_SUBDIR
>
> I'm afraid my grasp of autotools is too weak for me to know what the problem
> is
> here. At present I'm using the inherited src_complile() function from
> autotools.cygclass. In the past I used:
>
> src_compile ()
> {
> cd "$S"
> gettextize -f # needed to create tools/config.rpath
> cygautoreconf --install
> cd "$B"
> cygconf
> cygmake
> }
>
> but that doesn't fix the AM_INTL_SUBDIR problem.
Check configure.ac which version of autotools is required. There's a
good chance you need autoconf 2.69. You can probably fix that problem
in the cygport file by adding
WANT_AUTOCONF="2.5"
Corinna
pinfo build fails with undefined macro: AM_INTL_SUBDIR
I'm trying to rebuild pinfo 0.6.13. That's the current version in Cygwin, so I
know I was able to build it successfully a couple of years ago. But now when I
try, the build fails with
error: possibly undefined macro: AM_INTL_SUBDIR
I'm afraid my grasp of autotools is too weak for me to know what the problem is
here. At present I'm using the inherited src_complile() function from
autotools.cygclass. In the past I used:
src_compile ()
{
cd "$S"
gettextize -f # needed to create tools/config.rpath
cygautoreconf --install
cd "$B"
cygconf
cygmake
}
but that doesn't fix the AM_INTL_SUBDIR problem.
The full build log is below. Could someone suggest a solution?
Thanks,
Andrew
$ cygport pinfo.cygport make
*** Warning: Building on a case-insensitive filesystem
>>> Compiling pinfo-0.6.13-3.x86_64
autoreconf-2.71: export WARNINGS=
autoreconf-2.71: Entering directory '.'
autoreconf-2.71: running: /usr/bin/autopoint -V 0.21.1 --force
autopoint: warning: Version mismatch: specified -V 0.21.1 but the package uses
gettext version 0.14.4. Forcibly upgrading to 0.21.1
autoreconf-2.71: running: aclocal --force -I macros
configure.ac:144: warning: macro 'AM_INTL_SUBDIR' not found in library
autoreconf-2.71: configure.ac: tracing
autoreconf-2.71: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'tools'.
libtoolize: copying file 'tools/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'macros'.
libtoolize: copying file 'macros/libtool.m4'
libtoolize: copying file 'macros/ltoptions.m4'
libtoolize: copying file 'macros/ltsugar.m4'
libtoolize: copying file 'macros/ltversion.m4'
libtoolize: copying file 'macros/lt~obsolete.m4'
autoreconf-2.71: configure.ac: not using Intltool
autoreconf-2.71: configure.ac: not using Gtkdoc
autoreconf-2.71: running: aclocal --force -I macros
configure.ac:144: warning: macro 'AM_INTL_SUBDIR' not found in library
autoreconf-2.71: running: /usr/bin/autoconf-2.71 --force
configure.ac:55: warning: The macro `AC_PROG_CC_C99' is obsolete.
configure.ac:55: You should run autoupdate.
/mnt/share/cygpkgs/autoconf2.7/autoconf2.7.noarch/src/autoconf-2.71/lib/autoconf/c.m4:1659:
AC_PROG_CC_C99 is expanded from...
configure.ac:55: the top level
configure.ac:104: warning: The macro `AC_CHECKING' is obsolete.
configure.ac:104: You should run autoupdate.
/mnt/share/cygpkgs/autoconf2.7/autoconf2.7.noarch/src/autoconf-2.71/lib/autoconf/general.m4:2499:
AC_CHECKING is expanded from...
macros/readline.m4:102: AC_SEARCH_READLINE is expanded from...
macros/readline.m4:46: AC_CHECK_READLINE is expanded from...
configure.ac:104: the top level
configure.ac:104: warning: The macro `AC_FD_CC' is obsolete.
configure.ac:104: You should run autoupdate.
/mnt/share/cygpkgs/autoconf2.7/autoconf2.7.noarch/src/autoconf-2.71/lib/autoconf/general.m4:399:
AC_FD_CC is expanded from...
macros/readline.m4:111: AC_READLINE_VERSION is expanded from...
macros/readline.m4:46: AC_CHECK_READLINE is expanded from...
configure.ac:104: the top level
configure.ac:159: error: possibly undefined macro: AM_INTL_SUBDIR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf-2.71: error: /usr/bin/autoconf-2.71 failed with exit status: 1
*** ERROR: autoreconf failed
bc 1.07.1-1
bc version 1.07.1-1 is now available in Cygwin. This is a minor bugfix release. bc is an arbitrary precision numeric processing tool, that supports batch or interactive use. The package also includes dc, and arbitrary precision reverse-Polish calculator. Homepage: https://www.gnu.org/software/bc/ Andrew E. Schulman
[ANNOUNCEMENT] bc 1.07.1-1
bc version 1.07.1-1 is now available in Cygwin. This is a minor bugfix release. bc is an arbitrary precision numeric processing tool, that supports batch or interactive use. The package also includes dc, and arbitrary precision reverse-Polish calculator. Homepage: https://www.gnu.org/software/bc/ Andrew E. Schulman -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: issue when piping from a windows program
On 11.04.2023 09:15, Leonid Mironov via Cygwin wrote: I am trying to feed the output of wmic.exe - a windows console program, to cygwin bash script. wmic.exe produces UTF16LE output with BOM and CR/LFs, so I am using dos2unix to convert it. The problem is that when I write wmic.exe output to a file and then use dos2unix to convert this file I get the expected result - ASCII file with LFs, I get the same result when I pipe this file to dos2unix, but when I pipe wmic.exe output directly to dos2unix I get ASCII file with CR/LFs and an extra empty line. Cygwin is up to date, windows 10. What gives? Here are the hexdumps of 'wmic /NAMESPACE:root\\WMI PATH BatteryStatus get charging,voltage,remainingcapacity,chargerate>file' use "iconv" to change the codification and than d2u for the line termination $ iconv -f UTF16 -t UTF8 file ChargeRate Charging RemainingCapacity Voltage 0 FALSE 0 0 $ iconv -f UTF16 -t UTF8 file |od -c 000 C h a r g e R a t e C h a r 020 g i n g R e m a i n i n g C 040 a p a c i t y V o l t a g e 060 \r \n 0 100 F A L S E 0 120 0 140 \r \n 150 $ iconv -f UTF16 -t UTF8 file |d2u | od -c 000 C h a r g e R a t e C h a r 020 g i n g R e m a i n i n g C 040 a p a c i t y V o l t a g e 060 \n 0 F 100 A L S E 0 120 0 140 \n 146 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: reporting error
>pwd 2444 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
reporting error
pwd 2444 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[Bug] No Keyboard input when using interactive commands with stdin via pipes
Dear Cygwin users, there appears to be a bug or a missing implementation detail in either unix pipes or ConPTY, which prevents interactive console programs from receiving keyboard input, when they get stdin via a pipe. This report concerns the following Github issue, originally started in the MinTTY Terminal emulator Repo: https://github.com/mintty/mintty/issues/1210 There are multiple programs, which fail to receive any kind of keyboard input when used in MinTTY and when their stdin input is supplied via a pipe. This has been reported multiple times in the MinTTY repo already. Examples include: - `fzf`, which works normally when being called, but stops working properly if it receives a file list via a pipe. Eg.: `fzf` by itself works fine. but `find . | fzf` fails. - By extension, the zsh plugin fzf-plugin fails for the same reason, when opening the command history - The program fx ( https://github.com/antonmedv/fx ) which successfully receives keyboard input for navigating a json file, Eg.: `curl -s https://api.openai.com/v1/chat/completions -H 'Content-Type: application/json' > test.json; fx test.json` but fails when getting the json data as a direct pipe: `curl -s https://api.openai.com/v1/chat/completions -H 'Content-Type: application/json' | fx` This happens with MinTTY accessing the MSYS2 environment on Windows. Interestingly enough, this does not happen with Alacritty accessing the MSYS2 environment on Windows. With Alacritty everything is fine, which made me initially suspect MinTTY as being the culprit. However, the MinTTY repo lead diagnosed this issue to come from Cygwin, which is why I write report the bug in this mailing list. Is there something that can be done about this? Can I provide additional debug info or logs to help fix this? Best regards, Vlad -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
issue when piping from a windows program
I am trying to feed the output of wmic.exe - a windows console program, to cygwin bash script. wmic.exe produces UTF16LE output with BOM and CR/LFs, so I am using dos2unix to convert it. The problem is that when I write wmic.exe output to a file and then use dos2unix to convert this file I get the expected result - ASCII file with LFs, I get the same result when I pipe this file to dos2unix, but when I pipe wmic.exe output directly to dos2unix I get ASCII file with CR/LFs and an extra empty line. Cygwin is up to date, windows 10. What gives? Here are the hexdumps of 'wmic /NAMESPACE:root\\WMI PATH BatteryStatus get charging,voltage,remainingcapacity,chargerate>file' ff fe 43 00 68 00 61 00 72 00 67 00 65 00 52 00 |..C.h.a.r.g.e.R.| 0010 61 00 74 00 65 00 20 00 20 00 43 00 68 00 61 00 |a.t.e. . .C.h.a.| 0020 72 00 67 00 69 00 6e 00 67 00 20 00 20 00 52 00 |r.g.i.n.g. . .R.| 0030 65 00 6d 00 61 00 69 00 6e 00 69 00 6e 00 67 00 |e.m.a.i.n.i.n.g.| 0040 43 00 61 00 70 00 61 00 63 00 69 00 74 00 79 00 |C.a.p.a.c.i.t.y.| 0050 20 00 20 00 56 00 6f 00 6c 00 74 00 61 00 67 00 | . .V.o.l.t.a.g.| 0060 65 00 20 00 20 00 0d 00 0a 00 30 00 20 00 20 00 |e. . .0. . .| 0070 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .| 0080 20 00 46 00 41 00 4c 00 53 00 45 00 20 00 20 00 | .F.A.L.S.E. . .| 0090 20 00 20 00 20 00 33 00 37 00 37 00 33 00 34 00 | . . .3.7.7.3.4.| 00a0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .| 00b0 20 00 20 00 20 00 20 00 20 00 20 00 31 00 32 00 | . . . . . .1.2.| 00c0 37 00 34 00 30 00 20 00 20 00 20 00 20 00 0d 00 |7.4.0. . . . ...| 00d0 0a 00 |..| 00d2 of wimic>file followed by dos2unixhttps://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: python2 removal
On 03.04.2023 03:08, marco atzeri wrote: On Sun, Apr 2, 2023 at 11:47 AM Jon Turney via Cygwin-apps wrote: extra-cmake-modulesextra-cmake-modules ORPHANED (Yaakov Selkowitz) [†] probably ok, but should probably update & rebuild I adopted extra-cmake-modules and appstream that is required by it. I will upload as soon finished to clean both builds Regards Marco
