Re: ag 2 <(echo 2) gets assertion "p >= path" failed: .. /cygwin-3.1.7 ... /cygwin/path.cc", line 3065, function: int symlink_info::check
Thank you Ken, Corinna, and list members
On Tue, Sep 8, 2020 at 12:32 PM Ken Brown wrote:
> On 9/8/2020 3:26 PM, Ken Brown via Cygwin wrote:
> > On 9/7/2020 4:35 PM, Ken Brown via Cygwin wrote:
> >> On 9/6/2020 4:28 PM, Ken Brown via Cygwin wrote:
> >>> On 9/6/2020 3:47 PM, Ken Brown via Cygwin wrote:
> >>>> On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
> >>>>> This command triggers an assertion failure
> >>>>>"ag" is from the_silver_searcher
> >>>>>
> >>>>> $ ag 2 <(echo 2)
> >>>>> assertion "p >= path" failed: file
> >>>>>
> "/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc",
>
> >>>>>
> >>>>> line 3065, function: int symlink_info::check(char*, const
> >>>>> suffix_info*, fs_info&, path_conv_handle&)
> >>>>> Aborted (core dumped)
> >>>>>
> >>>>> 3473k 2020/08/22 C:\cygwin64\bin\cygwin1.dll
> >>>>> Cygwin DLL version info:
> >>>>> DLL version: 3.1.7
> >>>>> bash
> 4.4.12-3OK
> >>>>> the_silver_searcher
> 2.2.0-1 OK
> >>>> [...]
> >>>>> assertion "p >= path" failed: file
> >>>>>
> "/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc",
>
> >>>>>
> >>>>> line 3065, function: int symlink_info::check(char*, const
> >>>>> suffix_info*, fs_info&, path_conv_handle&)
> >>>>> Aborted (core dumped)
> >>>> [...]
> >>>>> I've reported this on github as an "ag" bug, but I think it is a bug
> in cygwin
> >>>>
> >>>> An assertion failure in Cygwin code is a Cygwin bug. I'll take a
> look.
> >>>
> >>> Running
> >>>
> >>>bash -c '/usr/bin/ag 2 <(echo 2)'
> >>>
> >>> under strace yields the following:
> >>>
> >>>242 191767 [main] ag 33659 open: open(/dev/fd/63/.ignore, 0x0)
> >>> [...]
> >>> 30 192584 [main] ag 33659 mount_info::conv_to_win32_path:
> src_path
> >>> /proc/self/fd/63/.ignore, dst /proc/self/fd/63/.ignore, flags 0x0, rc 0
> >>> [...]
> >>> 31 193366 [main] ag 33659 mount_info::conv_to_win32_path:
> >>> conv_to_win32_path (pipe:[4295036184]/.ignore)
> >>> [...]
> >>> 31 193550 [main] ag 33659 mount_info::conv_to_win32_path:
> >>> conv_to_win32_path (pipe:[4295036184])
> >>> [...]
> >>> 34 193615 [main] ag 33659 symlink_info::check: 0xC034 =
> NtCreateFile
> >>> (\??\C:pipe:[4295036184])
> >>>
> >>> The assertion fails because the path 'C:pipe:[4295036184]' doesn't
> contain a
> >>> backslash. But probably we should never have allowed ourselves to get
> to the
> >>> point of considering that path.
> >>
> >> I've made some progress but haven't figured out the fix yet. First,
> for
> >> easier debugging, here's a simpler way to reproduce the problem:
> >>
> >> $ cat proc_bug.c
> >> #include
> >> #include
> >> #include
> >> #include
> >>
> >> int
> >> main ()
> >> {
> >>int fd[2];
> >>char fname[100];
> >>
> >>if (pipe (fd) < 0)
> >> {
> >>perror ("pipe");
> >>exit (1);
> >> }
> >>sprintf (fname, "/dev/fd/%d/foo", fd[0]);
> >>if (open (fname, O_RDONLY) < 0)
> >> {
> >>perror ("open");
> >>exit (1);
> >> }
> >> }
> >>
> >> $ gcc -o proc_bug proc_bug.c
> >>
> >> $ ./proc_bug.exe
> >> assertion "p >= path" failed: file
> >> "../../../../newlib-cygwin/winsup/cygwin/path.cc", line 3065, function:
> int
> >> symlink_info::check(char*, const suffix_info*, fs_info&,
> path_conv_handle&)
> >> Aborted (core dumped)
> >>
> >> Here's what happens. The program is trying to open /dev/fd/3/foo,
> where file
> >> descriptor 3 is the read end of a pipe. path_conv check resolves this
> to
> >> /proc//fd/3/foo, creates an fhandler_process for this path, and
> calls (at
> >> path.cc:782) fhandler_process::exists. The latter fills the filebuf
> with
> >> "pipe:[xx]/foo" and returns virt_fsdir. We're now at
> path.cc:808, and
> >> everything is set up for the assertion failure.
> >
> > This is now fixed. David, you can test it as soon as Corinna has a
> chance to
> > make a new Cygwin snapshot.
>
> That's now done:
>
>https://cygwin.com/snapshots/
>
> Ken
>
Thank you!
My first time through
https://cygwin.com/snapshots/
and
https://cygwin.com/faq.html#faq.setup.snapshots
Installed the dll alone (
https://cygwin.com/snapshots/x86_64/cygwin1-20200908.dll.xz )
and the tests I performed were successful
$ ack 2 <(echo 2)
2
--
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
[ANNOUNCEMENT] New: unison2.48+4.04.2, unison2.48+4.08.1 [test]
Two new Unison packages are now available in test: unison2.48+4.04.2 unison2.48+4.08.1 Both of these are Unison 2.48.4, but compiled with OCaml 4.04.2 and 4.08.1, respectively. For the reasons explained below, we now need separate Unison packages for compatible versions of both Unison and OCaml. If you use Unison 2.48, please test these packages to see if one of them works to synchronize with your server, and report the results here. If they don't work for you, we can add other combinations. Once these packages move to the current release, they'll obsolete the current unison2.48 package, so please test them now. Unison is a file synchronizer for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other. == Unison versions and packages Unison comes in several complementary packages for Cygwin: Unison OCaml Package name version version Unison executable --- --- - unison2.27 2.27.* 4.01.0 /usr/bin/unison-2.27 unison2.32 2.32.* 4.01.0 /usr/bin/unison-2.32 unison2.40 2.40.* 4.02.3 /usr/bin/unison-2.40 unison2.45 2.45.* 4.01.1 /usr/bin/unison-2.45 unison2.48+4.04.2 2.48.* 4.04.2 /usr/bin/unison-2.48+4.04.2 unison2.48+4.08.1 2.48.* 4.08.1 /usr/bin/unison-2.48+4.08.1 unison2.49 2.49.* 4.02.3 /usr/bin/unison-2.49 unison2.51 2.51.* 4.04.2 /usr/bin/unison-2.51 You can install any number of these packages side-by-side. Separate packages are needed because in order to synchronize your files, you have to run compatible versions of Unison on the client and server. Two Unison executables are compatible if and only if: (1) They have the same first two numbers of the Unison version. For example, all Unison versions 2.48.* are compatible with each other. But if you try to use version 2.51.x to sync with a server running version 2.48.y, Unison will issue an error message about incompatible versions and quit. AND (2) They were built with compatible versions of the OCaml compiler. OCaml has changed its format over time for "marshaling" or serializing data. If you run Unison executables that were built with OCaml versions that use different marshaling formats, even if the Unison versions are the same, you'll get the dreaded error message Fatal error: Fatal error during unmarshaling (input_value: ill-formed message), possibly because client and server have been compiled with different versions of the OCaml compiler. Apparently OCaml introduced breaking changes to its marshaling format in versions 4.08 and 4.11. So versions pre-4.08, between 4.08 and 4.11, or post-4.11 should be mutually compatible. But this hasn't been tested much. For discussion of OCaml version incompatibilities, see https://lists.seas.upenn.edu/pipermail/unison-hackers/2020-August/001972.html . By installing one or more of the packages listed above, you can run whichever version you need in order to synchronize with your server. If you need a different combination of Unison and OCaml versions than is available in the current packages, please send a report to cygwin@cygwin.com. It may be possible to create a new package for it. == Setting a default version The package postinstallation scripts use alternatives(8) to install a symlink /usr/bin/unison that points to one of the above-named executables. By default this symlink will track the highest-numbered version of Unison that you install on your system. You can change that using alternatives: alternatives --config unison (recommended) or manually. See "man alternatives" for details. If the server provides multiple versions of Unison, then you can invoke Unison on the client with e.g. '-servercmd /usr/bin/unison-2.48' to run the version you want on the server, or put 'servercmd /usr/bin/unison-2.48' into the client's preference file. == User interface All of the Unison packages for Cygwin use the text UI. There is also a GTK2 UI for Unison, but I haven't been able to get it working yet under Cygwin. At some time in the future I may make unison*+gtk2 packages available for Cygwin. 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
New: unison2.48+4.04.2, unison2.48+4.08.1 [test]
Two new Unison packages are now available in test: unison2.48+4.04.2 unison2.48+4.08.1 Both of these are Unison 2.48.4, but compiled with OCaml 4.04.2 and 4.08.1, respectively. For the reasons explained below, we now need separate Unison packages for compatible versions of both Unison and OCaml. If you use Unison 2.48, please test these packages to see if one of them works to synchronize with your server, and report the results here. If they don't work for you, we can add other combinations. Once these packages move to the current release, they'll obsolete the current unison2.48 package, so please test them now. Unison is a file synchronizer for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other. == Unison versions and packages Unison comes in several complementary packages for Cygwin: Unison OCaml Package name version version Unison executable --- --- - unison2.27 2.27.* 4.01.0 /usr/bin/unison-2.27 unison2.32 2.32.* 4.01.0 /usr/bin/unison-2.32 unison2.40 2.40.* 4.02.3 /usr/bin/unison-2.40 unison2.45 2.45.* 4.01.1 /usr/bin/unison-2.45 unison2.48+4.04.2 2.48.* 4.04.2 /usr/bin/unison-2.48+4.04.2 unison2.48+4.08.1 2.48.* 4.08.1 /usr/bin/unison-2.48+4.08.1 unison2.49 2.49.* 4.02.3 /usr/bin/unison-2.49 unison2.51 2.51.* 4.04.2 /usr/bin/unison-2.51 You can install any number of these packages side-by-side. Separate packages are needed because in order to synchronize your files, you have to run compatible versions of Unison on the client and server. Two Unison executables are compatible if and only if: (1) They have the same first two numbers of the Unison version. For example, all Unison versions 2.48.* are compatible with each other. But if you try to use version 2.51.x to sync with a server running version 2.48.y, Unison will issue an error message about incompatible versions and quit. AND (2) They were built with compatible versions of the OCaml compiler. OCaml has changed its format over time for "marshaling" or serializing data. If you run Unison executables that were built with OCaml versions that use different marshaling formats, even if the Unison versions are the same, you'll get the dreaded error message Fatal error: Fatal error during unmarshaling (input_value: ill-formed message), possibly because client and server have been compiled with different versions of the OCaml compiler. Apparently OCaml introduced breaking changes to its marshaling format in versions 4.08 and 4.11. So versions pre-4.08, between 4.08 and 4.11, or post-4.11 should be mutually compatible. But this hasn't been tested much. For discussion of OCaml version incompatibilities, see https://lists.seas.upenn.edu/pipermail/unison-hackers/2020-August/001972.html . By installing one or more of the packages listed above, you can run whichever version you need in order to synchronize with your server. If you need a different combination of Unison and OCaml versions than is available in the current packages, please send a report to cyg...@cygwin.com. It may be possible to create a new package for it. == Setting a default version The package postinstallation scripts use alternatives(8) to install a symlink /usr/bin/unison that points to one of the above-named executables. By default this symlink will track the highest-numbered version of Unison that you install on your system. You can change that using alternatives: alternatives --config unison (recommended) or manually. See "man alternatives" for details. If the server provides multiple versions of Unison, then you can invoke Unison on the client with e.g. '-servercmd /usr/bin/unison-2.48' to run the version you want on the server, or put 'servercmd /usr/bin/unison-2.48' into the client's preference file. == User interface All of the Unison packages for Cygwin use the text UI. There is also a GTK2 UI for Unison, but I haven't been able to get it working yet under Cygwin. At some time in the future I may make unison*+gtk2 packages available for Cygwin. Andrew E. Schulman
Re: ag 2 <(echo 2) gets assertion "p >= path" failed: .. /cygwin-3.1.7 ... /cygwin/path.cc", line 3065, function: int symlink_info::check
On 9/8/2020 3:26 PM, Ken Brown via Cygwin wrote:
On 9/7/2020 4:35 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 4:28 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 3:47 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
This command triggers an assertion failure
"ag" is from the_silver_searcher
$ ag 2 <(echo 2)
assertion "p >= path" failed: file
"/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc",
line 3065, function: int symlink_info::check(char*, const
suffix_info*, fs_info&, path_conv_handle&)
Aborted (core dumped)
3473k 2020/08/22 C:\cygwin64\bin\cygwin1.dll
Cygwin DLL version info:
DLL version: 3.1.7
bash 4.4.12-3 OK
the_silver_searcher 2.2.0-1 OK
[...]
assertion "p >= path" failed: file
"/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc",
line 3065, function: int symlink_info::check(char*, const
suffix_info*, fs_info&, path_conv_handle&)
Aborted (core dumped)
[...]
I've reported this on github as an "ag" bug, but I think it is a bug in cygwin
An assertion failure in Cygwin code is a Cygwin bug. I'll take a look.
Running
bash -c '/usr/bin/ag 2 <(echo 2)'
under strace yields the following:
242 191767 [main] ag 33659 open: open(/dev/fd/63/.ignore, 0x0)
[...]
30 192584 [main] ag 33659 mount_info::conv_to_win32_path: src_path
/proc/self/fd/63/.ignore, dst /proc/self/fd/63/.ignore, flags 0x0, rc 0
[...]
31 193366 [main] ag 33659 mount_info::conv_to_win32_path:
conv_to_win32_path (pipe:[4295036184]/.ignore)
[...]
31 193550 [main] ag 33659 mount_info::conv_to_win32_path:
conv_to_win32_path (pipe:[4295036184])
[...]
34 193615 [main] ag 33659 symlink_info::check: 0xC034 = NtCreateFile
(\??\C:pipe:[4295036184])
The assertion fails because the path 'C:pipe:[4295036184]' doesn't contain a
backslash. But probably we should never have allowed ourselves to get to the
point of considering that path.
I've made some progress but haven't figured out the fix yet. First, for
easier debugging, here's a simpler way to reproduce the problem:
$ cat proc_bug.c
#include
#include
#include
#include
int
main ()
{
int fd[2];
char fname[100];
if (pipe (fd) < 0)
{
perror ("pipe");
exit (1);
}
sprintf (fname, "/dev/fd/%d/foo", fd[0]);
if (open (fname, O_RDONLY) < 0)
{
perror ("open");
exit (1);
}
}
$ gcc -o proc_bug proc_bug.c
$ ./proc_bug.exe
assertion "p >= path" failed: file
"../../../../newlib-cygwin/winsup/cygwin/path.cc", line 3065, function: int
symlink_info::check(char*, const suffix_info*, fs_info&, path_conv_handle&)
Aborted (core dumped)
Here's what happens. The program is trying to open /dev/fd/3/foo, where file
descriptor 3 is the read end of a pipe. path_conv check resolves this to
/proc//fd/3/foo, creates an fhandler_process for this path, and calls (at
path.cc:782) fhandler_process::exists. The latter fills the filebuf with
"pipe:[xx]/foo" and returns virt_fsdir. We're now at path.cc:808, and
everything is set up for the assertion failure.
This is now fixed. David, you can test it as soon as Corinna has a chance to
make a new Cygwin snapshot.
That's now done:
https://cygwin.com/snapshots/
Ken
--
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: ag 2 <(echo 2) gets assertion "p >= path" failed: .. /cygwin-3.1.7 ... /cygwin/path.cc", line 3065, function: int symlink_info::check
On 9/7/2020 4:35 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 4:28 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 3:47 PM, Ken Brown via Cygwin wrote:
On 9/6/2020 2:43 PM, David Dyck via Cygwin wrote:
This command triggers an assertion failure
"ag" is from the_silver_searcher
$ ag 2 <(echo 2)
assertion "p >= path" failed: file
"/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc",
line 3065, function: int symlink_info::check(char*, const
suffix_info*, fs_info&, path_conv_handle&)
Aborted (core dumped)
3473k 2020/08/22 C:\cygwin64\bin\cygwin1.dll
Cygwin DLL version info:
DLL version: 3.1.7
bash 4.4.12-3 OK
the_silver_searcher 2.2.0-1 OK
[...]
assertion "p >= path" failed: file
"/home/corinna/src/cygwin/cygwin-3.1.7/cygwin-3.1.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/path.cc",
line 3065, function: int symlink_info::check(char*, const
suffix_info*, fs_info&, path_conv_handle&)
Aborted (core dumped)
[...]
I've reported this on github as an "ag" bug, but I think it is a bug in cygwin
An assertion failure in Cygwin code is a Cygwin bug. I'll take a look.
Running
bash -c '/usr/bin/ag 2 <(echo 2)'
under strace yields the following:
242 191767 [main] ag 33659 open: open(/dev/fd/63/.ignore, 0x0)
[...]
30 192584 [main] ag 33659 mount_info::conv_to_win32_path: src_path
/proc/self/fd/63/.ignore, dst /proc/self/fd/63/.ignore, flags 0x0, rc 0
[...]
31 193366 [main] ag 33659 mount_info::conv_to_win32_path:
conv_to_win32_path (pipe:[4295036184]/.ignore)
[...]
31 193550 [main] ag 33659 mount_info::conv_to_win32_path:
conv_to_win32_path (pipe:[4295036184])
[...]
34 193615 [main] ag 33659 symlink_info::check: 0xC034 = NtCreateFile
(\??\C:pipe:[4295036184])
The assertion fails because the path 'C:pipe:[4295036184]' doesn't contain a
backslash. But probably we should never have allowed ourselves to get to the
point of considering that path.
I've made some progress but haven't figured out the fix yet. First, for easier
debugging, here's a simpler way to reproduce the problem:
$ cat proc_bug.c
#include
#include
#include
#include
int
main ()
{
int fd[2];
char fname[100];
if (pipe (fd) < 0)
{
perror ("pipe");
exit (1);
}
sprintf (fname, "/dev/fd/%d/foo", fd[0]);
if (open (fname, O_RDONLY) < 0)
{
perror ("open");
exit (1);
}
}
$ gcc -o proc_bug proc_bug.c
$ ./proc_bug.exe
assertion "p >= path" failed: file
"../../../../newlib-cygwin/winsup/cygwin/path.cc", line 3065, function: int
symlink_info::check(char*, const suffix_info*, fs_info&, path_conv_handle&)
Aborted (core dumped)
Here's what happens. The program is trying to open /dev/fd/3/foo, where file
descriptor 3 is the read end of a pipe. path_conv check resolves this to
/proc//fd/3/foo, creates an fhandler_process for this path, and calls (at
path.cc:782) fhandler_process::exists. The latter fills the filebuf with
"pipe:[xx]/foo" and returns virt_fsdir. We're now at path.cc:808, and
everything is set up for the assertion failure.
This is now fixed. David, you can test it as soon as Corinna has a chance to
make a new Cygwin snapshot.
Thanks for reporting the problem.
Ken
--
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: cygwin1.dll: uname_x not found
On Sep 8 21:21, Corinna Vinschen wrote: > On Sep 8 11:28, L A Walsh wrote: > > > > > > On 9/8/2020 12:18 AM, Corinna Vinschen wrote: > > > On Sep 7 14:34, L A Walsh wrote: > > >>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/ > > >>> > > >>> Please give them a try. > > >> --- > > >> Got: > > >> > > >> "The procedure entry point uname_x could not be located in the dynamic > > >> link library cygwin1.dll" > > > > > > uname_x is exported just fine. You're doing something wrong. > > > > > > Corinna > > --- > > I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll > > to cygwin1.dll-. I 'copy'd the new dll in place and tried to run something. > > > > What step did I miss? > > > > Sorry, I know whatever I missed is obvious to you -- it always is obvious > > to someone who knows the answer, but to those that don't know the answer, > > it isn't at all obvious. > > No, it's not at all obvious to me what you did wrong. Still, the > snapshot DLL works fine for me and, apparently, Thomas had no problem > either. Btw., if the snapshot DLL doesn't export uname_x, then you're actually using a very old DLL (pre 2.0 or so) accidentally. Corinna -- Corinna Vinschen Cygwin Maintainer -- 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: cygwin1.dll: uname_x not found
On Sep 8 11:28, L A Walsh wrote: > > > On 9/8/2020 12:18 AM, Corinna Vinschen wrote: > > On Sep 7 14:34, L A Walsh wrote: > >>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/ > >>> > >>> Please give them a try. > >> --- > >> Got: > >> > >> "The procedure entry point uname_x could not be located in the dynamic > >> link library cygwin1.dll" > > > > uname_x is exported just fine. You're doing something wrong. > > > > Corinna > --- > I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll > to cygwin1.dll-. I 'copy'd the new dll in place and tried to run something. > > What step did I miss? > > Sorry, I know whatever I missed is obvious to you -- it always is obvious > to someone who knows the answer, but to those that don't know the answer, > it isn't at all obvious. No, it's not at all obvious to me what you did wrong. Still, the snapshot DLL works fine for me and, apparently, Thomas had no problem either. ¯\_(ツ)_/¯ Corinna -- Corinna Vinschen Cygwin Maintainer -- 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: cygwin1.dll: uname_x not found
On Sep 8 20:47, Thomas Wolff wrote: > > > Am 08.09.2020 um 20:28 schrieb L A Walsh: > > > > On 9/8/2020 12:18 AM, Corinna Vinschen wrote: > > > On Sep 7 14:34, L A Walsh wrote: > > > > > I uploaded new snapshots for testing to https://cygwin.com/snapshots/ > > > > > > > > > > Please give them a try. > For me, the snapshot dll fixes the issue I observed. Thanks for testing and confirming, Corinna -- Corinna Vinschen Cygwin Maintainer -- 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: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"
On Sep 8 18:45, Takashi Yano via Cygwin-patches wrote: > Hi Corinna, > > On Tue, 8 Sep 2020 10:40:34 +0200 > Corinna Vinschen wrote: > > On Sep 7 13:45, Takashi Yano via Cygwin-patches wrote: > > > On Mon, 7 Sep 2020 01:04:13 +0900 > > > > > Chages: > > > > > - If global locale is set, it takes precedence. > > > > > > > > Changes: > > > > - Use __get_current_locale() instead of __get_global_locale(). > > > > - Fix a bug for ISO-8859-* charset. > > > > > > Changes: > > > - Use envblock if it is passed to CreateProcess in spawn.cc. > > > > For the time being and to make at least *some* progress and with my > > upcoming "away from keyboard"-time , I pushed the gist of my patch, > > replacing the locale evaluating code in fhandler_tty with the function > > __eval_codepage_from_internal_charset in its most simple form. > > I didn't touch anything else, given that this discussion is still > > ongoing. > > Your patch pushed does the magic! > > Even cygterm works even though the code does not check environment. > > The point is here. > > @@ -1977,9 +1807,6 @@ fhandler_pty_slave::fixup_after_exec () >if (!close_on_exec ()) > fixup_after_fork (NULL); /* No parent handle required. */ > > - /* Set locale */ > - setup_locale (); > - >/* Hook Console API */ > #define DO_HOOK(module, name) \ >if (!name##_Orig) \ > > Without this deletion, term_code_page is determined when > cygwin shell is executed. Since it is in fixup_after_exec(), > setlocale() does not called yet in the shell. As a result, > term_code_page cannot be determined correctly. > > In your new patch, term_code_page is determined when the first > non-cygwin program is execed in the shell. The shell process > already calls setlocale(), so term_code_page can be determined > using global locale. > > Thanks for the excellent idea! > > Only the problem I noticed is that cygterm does not work if the > shell does not call setlocale(). This happens if the shell is > non-cygwin program, for example, cmd.exe, however, it is unusual > case. This is unexpected, but I'm glad this could be much simplfied. Thanks, Corinna
Re: [PATCH v2 2/3] Cygwin: path_conv::check: handle error from fhandler_process::exists
On Sep 8 15:05, Ken Brown via Cygwin-patches wrote:
> On 9/8/2020 3:02 PM, Ken Brown via Cygwin-patches wrote:
> > fhandler_process::exists is called when we are checking a path
> > starting with "/proc//fd". If it returns virt_none and sets an
> > errno, there is no need for further checking. Just set 'error' and
> > return.
> > ---
> > winsup/cygwin/path.cc | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
> > index 95faf8ca7..1d0c38a20 100644
> > --- a/winsup/cygwin/path.cc
> > +++ b/winsup/cygwin/path.cc
> > @@ -809,6 +809,15 @@ path_conv::check (const char *src, unsigned opt,
> > delete fh;
> > goto retry_fs_via_processfd;
> > }
> > + else if (file_type == virt_none && dev == FH_PROCESSFD)
> > + {
> > + error = get_errno ();
> > + if (error)
> > + {
> > + delete fh;
> > + return;
> > + }
> > + }
> > delete fh;
> > }
> > switch (file_type)
> >
>
> The subject should say "2/2", not "2/3". I have a local third patch
> documenting the bug fix, which I didn't bother to send.
ACk to both patches, 2 and 3 ;)
Corinna
Re: [PATCH 1/2] Cygwin: format_process_fd: add directory check
Hi Ken,
On Sep 8 12:50, Ken Brown via Cygwin-patches wrote:
> The incoming path is allowed to have the form "$PID/fd/[0-9]*/.*"
> provided the descriptor symlink points to a directory. Check that
> this is indeed the case.
> ---
> winsup/cygwin/fhandler_process.cc | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/winsup/cygwin/fhandler_process.cc
> b/winsup/cygwin/fhandler_process.cc
> index a6c358217..888604e3d 100644
> --- a/winsup/cygwin/fhandler_process.cc
> +++ b/winsup/cygwin/fhandler_process.cc
> @@ -398,6 +398,21 @@ format_process_fd (void *data, char *)
> *((process_fd_t *) data)->fd_type = virt_fdsymlink;
>else /* trailing path */
> {
> + /* Does the descriptor link point to a directory? */
> + bool dir;
> + if (*destbuf != '/') /* e.g., "pipe:[" or "socket:[" */
> + dir = false;
> + else
> + {
> + path_conv pc (destbuf);
> + dir = pc.isdir ();
> + }
> + if (!dir)
> + {
> + set_errno (ENOTDIR);
> + cfree (destbuf);
> + return -1;
> + }
> char *newbuf = (char *) cmalloc_abort (HEAP_STR, strlen (destbuf)
> + strlen (e) + 1);
> stpcpy (stpcpy (newbuf, destbuf), e);
> --
> 2.28.0
Huh, I'd never realized this check is missing. I was just puzzeling
over your patch, searching for the directory check, but yeah, there is
none. Please push.
Thanks,
Corinna
Re: [PATCH v2 2/3] Cygwin: path_conv::check: handle error from fhandler_process::exists
On 9/8/2020 3:02 PM, Ken Brown via Cygwin-patches wrote:
fhandler_process::exists is called when we are checking a path
starting with "/proc//fd". If it returns virt_none and sets an
errno, there is no need for further checking. Just set 'error' and
return.
---
winsup/cygwin/path.cc | 9 +
1 file changed, 9 insertions(+)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 95faf8ca7..1d0c38a20 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -809,6 +809,15 @@ path_conv::check (const char *src, unsigned opt,
delete fh;
goto retry_fs_via_processfd;
}
+ else if (file_type == virt_none && dev == FH_PROCESSFD)
+ {
+ error = get_errno ();
+ if (error)
+ {
+ delete fh;
+ return;
+ }
+ }
delete fh;
}
switch (file_type)
The subject should say "2/2", not "2/3". I have a local third patch documenting
the bug fix, which I didn't bother to send.
Ken
[PATCH v2 2/3] Cygwin: path_conv::check: handle error from fhandler_process::exists
fhandler_process::exists is called when we are checking a path
starting with "/proc//fd". If it returns virt_none and sets an
errno, there is no need for further checking. Just set 'error' and
return.
---
winsup/cygwin/path.cc | 9 +
1 file changed, 9 insertions(+)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 95faf8ca7..1d0c38a20 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -809,6 +809,15 @@ path_conv::check (const char *src, unsigned opt,
delete fh;
goto retry_fs_via_processfd;
}
+ else if (file_type == virt_none && dev == FH_PROCESSFD)
+ {
+ error = get_errno ();
+ if (error)
+ {
+ delete fh;
+ return;
+ }
+ }
delete fh;
}
switch (file_type)
--
2.28.0
Re: [PATCH 2/2] Cygwin: path_conv::check: handle error from fhandler_process::exists
On 9/8/2020 12:50 PM, Ken Brown via Cygwin-patches wrote:
fhandler_process::exists is called when we are checking a path
starting with "/proc//fd". If it returns virt_none and sets an
errno, there is no need for further checking. Just set 'error' and
return.
---
winsup/cygwin/path.cc | 6 ++
1 file changed, 6 insertions(+)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 95faf8ca7..092261939 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -809,6 +809,12 @@ path_conv::check (const char *src, unsigned opt,
delete fh;
goto retry_fs_via_processfd;
}
+ else if (file_type == virt_none && dev == FH_PROCESSFD)
+ {
+ error = get_errno ();
+ if (error)
+ return;
+ }
delete fh;
}
switch (file_type)
There's a missing 'delete fh' above. I'll send v2 shortly.
Ken
Re: cygwin1.dll: uname_x not found
Am 08.09.2020 um 20:28 schrieb L A Walsh: On 9/8/2020 12:18 AM, Corinna Vinschen wrote: On Sep 7 14:34, L A Walsh wrote: I uploaded new snapshots for testing to https://cygwin.com/snapshots/ Please give them a try. For me, the snapshot dll fixes the issue I observed. Thomas --- Got: "The procedure entry point uname_x could not be located in the dynamic link library cygwin1.dll" uname_x is exported just fine. You're doing something wrong. Corinna --- I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll to cygwin1.dll-. I 'copy'd the new dll in place and tried to run something. What step did I miss? Sorry, I know whatever I missed is obvious to you -- it always is obvious to someone who knows the answer, but to those that don't know the answer, it isn't at all obvious. I have used test libraries before the same way and had them work. So I don't know what I missed. -- 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 -- 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: [PATCH] Cygwin: pty: Fix input charset for non-cygwin apps with disable_pcon.
Hi Takashi,
On Sep 8 18:57, Takashi Yano via Cygwin-patches wrote:
> - If the non-cygwin apps is executed under pseudo console disabled,
> multibyte input for the apps are garbled. This patch fixes the
> issue.
> ---
> winsup/cygwin/fhandler_tty.cc | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
> index 6de591d9b..afaa4546e 100644
> --- a/winsup/cygwin/fhandler_tty.cc
> +++ b/winsup/cygwin/fhandler_tty.cc
> @@ -271,8 +271,17 @@ fhandler_pty_master::accept_input ()
>bytes_left = eat_readahead (-1);
>
>HANDLE write_to = get_output_handle ();
> + char *buf = NULL;
>if (to_be_read_from_pcon ())
> -write_to = to_slave;
> +{
> + write_to = to_slave;
> + size_t nlen;
> + buf = convert_mb_str (GetConsoleCP (), ,
> + get_ttyp ()->term_code_page,
> + (const char *) p, bytes_left);
> + p = buf;
> + bytes_left = nlen;
> +}
How big are chances that the string in p is larger than 32767 chars?
I'd like to see convert_mb_str use a tmp_pathbuf buffer instead of
calling HeapAlloc/HeapFree every time. That also drops the mb_str_free
entirely.
Isn't there a problem anyway with calling convert_mb_str? Consider
a write call which stops in the middle of a multibyte char, the
second half only sent with the next write call. convert_mb_str
only allows to convert complete multibyte chars, and the caller does
not keep something like an mbstate_t around, which would allow
continuation of split multibyte chars.
Corinna
Re: Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities
What are you complaining about? What erroneous behavior? We can't read your mind, but it isn't clear what you think is going wrong -- so how are we supposed to figure out what the erroneous behavior is? Please give an example of what you think is wrong and what you expected instead. Please be clear enough that your own mother and father would clearly understand the problem. Also, is there a reason you submitted this to the cygwin list instead of the bug-b...@gnu.org list? On 9/7/2020 11:24 PM, johnb...@email.com wrote: -- 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: cygwin1.dll: uname_x not found
On 9/8/2020 12:18 AM, Corinna Vinschen wrote: > On Sep 7 14:34, L A Walsh wrote: >>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/ >>> >>> Please give them a try. >> --- >> Got: >> >> "The procedure entry point uname_x could not be located in the dynamic >> link library cygwin1.dll" > > uname_x is exported just fine. You're doing something wrong. > > Corinna --- I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll to cygwin1.dll-. I 'copy'd the new dll in place and tried to run something. What step did I miss? Sorry, I know whatever I missed is obvious to you -- it always is obvious to someone who knows the answer, but to those that don't know the answer, it isn't at all obvious. I have used test libraries before the same way and had them work. So I don't know what I missed. -- 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
[PATCH 2/2] Cygwin: path_conv::check: handle error from fhandler_process::exists
fhandler_process::exists is called when we are checking a path
starting with "/proc//fd". If it returns virt_none and sets an
errno, there is no need for further checking. Just set 'error' and
return.
---
winsup/cygwin/path.cc | 6 ++
1 file changed, 6 insertions(+)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 95faf8ca7..092261939 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -809,6 +809,12 @@ path_conv::check (const char *src, unsigned opt,
delete fh;
goto retry_fs_via_processfd;
}
+ else if (file_type == virt_none && dev == FH_PROCESSFD)
+ {
+ error = get_errno ();
+ if (error)
+ return;
+ }
delete fh;
}
switch (file_type)
--
2.28.0
[PATCH 0/2] Fix problems with /proc//fd checking
This fixes the assertion failure reported here: https://sourceware.org/pipermail/cygwin/2020-September/246160.html with a simple test case here: https://sourceware.org/pipermail/cygwin/2020-September/246188.html That test case now fails as follows, as on Linux: $ ./proc_bug.exe open: Not a directory I'm not completely sure about the second patch. The path_conv::check code is so complicated that I could easily have missed something. But I think it's correct. Ken Brown (2): Cygwin: format_process_fd: add directory check Cygwin: path_conv::check: handle error from fhandler_process::exists winsup/cygwin/fhandler_process.cc | 15 +++ winsup/cygwin/path.cc | 6 ++ 2 files changed, 21 insertions(+) -- 2.28.0
[PATCH 1/2] Cygwin: format_process_fd: add directory check
The incoming path is allowed to have the form "$PID/fd/[0-9]*/.*"
provided the descriptor symlink points to a directory. Check that
this is indeed the case.
---
winsup/cygwin/fhandler_process.cc | 15 +++
1 file changed, 15 insertions(+)
diff --git a/winsup/cygwin/fhandler_process.cc
b/winsup/cygwin/fhandler_process.cc
index a6c358217..888604e3d 100644
--- a/winsup/cygwin/fhandler_process.cc
+++ b/winsup/cygwin/fhandler_process.cc
@@ -398,6 +398,21 @@ format_process_fd (void *data, char *)
*((process_fd_t *) data)->fd_type = virt_fdsymlink;
else /* trailing path */
{
+ /* Does the descriptor link point to a directory? */
+ bool dir;
+ if (*destbuf != '/') /* e.g., "pipe:[" or "socket:[" */
+ dir = false;
+ else
+ {
+ path_conv pc (destbuf);
+ dir = pc.isdir ();
+ }
+ if (!dir)
+ {
+ set_errno (ENOTDIR);
+ cfree (destbuf);
+ return -1;
+ }
char *newbuf = (char *) cmalloc_abort (HEAP_STR, strlen (destbuf)
+ strlen (e) + 1);
stpcpy (stpcpy (newbuf, destbuf), e);
--
2.28.0
Re: Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities
On 2020-09-08 10:22, Brian Inglis wrote: > On 2020-09-08 00:24, johnb...@email.com wrote: > You are demonstrating erroneous behaviour. What erroneous behaviour, what other utilities? You need to include your console or terminal log, or a copy and paste of (*relevant* selections of) the input and output as *text*. [Graphics screenshots are rarely trimmed of irrelevant surroundings, almost always too small, seldom enlarged to show input and output clearly, and unless you use a portrait monitor and/or windows, often do not include enough needed context.] You need to demonstrate the problem, showing the commands and outputs, telling us where your expectations differ from the results, and for files, showing us details with ls -l or stat, as well as attaching cygcheck.out. Please read and understand: https://cygwin.com/problems.html and its links: http://www.catb.org/~esr/faqs/smart-questions.html https://www.chiark.greenend.org.uk/~sgtatham/bugs.html which I have tersely summarized above. -- 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. [Data in IEC units and prefixes, physical quantities in SI.] -- 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: Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities
On 2020-09-08 00:24, johnb...@email.com wrote: > You are demonstrating erroneous behaviour. -- 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. [Data in IEC units and prefixes, physical quantities in SI.] -- 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: postinstall: fontconfig abnormal exit
On 2020-09-08 09:18, Fergus Daly via Cygwin wrote:
>> Greetings, Fergus Daly!
>
>>> Sorry if this has been asked 4 million times already.
>>> During postinstall, both at ground-zero installation and at every update
>>> thereafter, and for both Cygwin-32 and -64,
>>> (both using the appropriate setup-x86[_64].exe) I get:
>>> running: {pathToCygwin}\bin\bash.exe --norc --noprofile
>>> "/etc/postinstall/fontconfig_dtd.sh"
>>> abnormal exit: exit code=2
>>> Is there something that can be done to address this "error", if that is
>>> what it is, or is it just a quirk of setup?
>
>> Run the same command manually and see where it's failing.
>> IIRC (as this has been raised before), the problem is that a certain
>> file/directory not exists.
>> Check the mailing list archive?
>
> Thank you for this advice.
>
> 1
> For a long time (years) I have included an empty file
> /etc/X11/fontpath.d/thisisafile
> in my architecture as a workaround to address some installation problem,
> the nature of which I have completely forgotten.
> Having incorporated this dummy file, I should then re-install some package,
> but precisely which one I have regrettably also forgotten.
>
> 2
> This kind suggestion came from Ken Brown. By a strange coincidence, less than
> a week ago,
> https://cygwin.com/pipermail/cygwin/2020-September/246128.html,
> I lamented the lack of ease with which one may search this archive. I just
> searched in a limited way
> to try to discover the problem for which Ken's workaround provided the cure,
> but without success.
>
> 3
> I also just now added "fontconfig" to my setup using "setup -P fontconfig"
> and then also ran the command
> fc-cache -v
> at the bash prompt, and whilst achieving a raft of checks, this has not
> addressed the original postinstall error
> message.
> I did not really think it would, guessing that if the fontconfig package were
> to successfully address such a
> basic (and recurrent) fault, then it would necessarily have been included in
> Base.
>
> So: nil progress, but thank you for your suggestion.
$ cygcheck -f /etc/postinstall/fontconfig_dtd.sh
libfontconfig-common-2.13.1-1
$ cygcheck -f /usr/bin/xmlcatalog
libxml2-2.9.10-1
$ cygcheck -f /usr/share/xml/fontconfig/fonts.dtd
libfontconfig-common-2.13.1-1
$ head /etc/postinstall/{fontconfig_dtd,libxml2}.*
==> /etc/postinstall/fontconfig_dtd.sh.done <==
if [ -x /usr/bin/xmlcatalog ] ; then
/usr/bin/xmlcatalog --noout --add "system" "fonts.dtd"
/usr/share/xml/fontconfig/fonts.dtd /etc/xml/catalog
fi
==> /etc/postinstall/libxml2.sh.done <==
if test ! -f /etc/xml/catalog; then
/bin/mkdir -p /etc/xml
/usr/bin/xmlcatalog --noout --create /etc/xml/catalog
fi
$ llgo /{etc/xml/,usr/bin/xml}catalog /usr/share/xml/fontconfig/fonts.dtd
/etc/postinstall/{fontconfig_dtd,libxml2}.*
-rw-r--r-- 1 152 Jul 28 2019 /etc/postinstall/fontconfig_dtd.sh.done
-rw-r--r-- 1 118 Mar 25 2019 /etc/postinstall/libxml2.sh.done
-rw-r--r-- 1 1.2K Jul 30 2019 /etc/xml/catalog
-rwxr-xr-x 1 18K Aug 15 10:35 /usr/bin/xmlcatalog*
-rw-r--r-- 1 7.1K Jul 28 2019 /usr/share/xml/fontconfig/fonts.dtd
So check the existence of all the files and all the postinstall scripts,
re-execute the latter if necessary, re-install packages if necessary to make
repairs, and ensure the postinstall scripts are renamed with .done appended when
successfully completed.
--
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.
[Data in IEC units and prefixes, physical quantities in SI.]
--
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: postinstall: fontconfig abnormal exit
> Greetings, Fergus Daly!
>> Sorry if this has been asked 4 million times already.
>> During postinstall, both at ground-zero installation and at every update
>> thereafter, and for both Cygwin-32 and -64,
>> (both using the appropriate setup-x86[_64].exe) I get:
>> running: {pathToCygwin}\bin\bash.exe --norc --noprofile
>> "/etc/postinstall/fontconfig_dtd.sh"
>> abnormal exit: exit code=2
>> Is there something that can be done to address this "error", if that is
>> what it is, or is it just a quirk of setup?
> Run the same command manually and see where it's failing.
> IIRC (as this has been raised before), the problem is that a certain
> file/directory not exists.
> Check the mailing list archive?
Thank you for this advice.
1
For a long time (years) I have included an empty file
/etc/X11/fontpath.d/thisisafile
in my architecture as a workaround to address some installation problem,
the nature of which I have completely forgotten.
Having incorporated this dummy file, I should then re-install some package,
but precisely which one I have regrettably also forgotten.
2
This kind suggestion came from Ken Brown. By a strange coincidence, less than a
week ago,
https://cygwin.com/pipermail/cygwin/2020-September/246128.html,
I lamented the lack of ease with which one may search this archive. I just
searched in a limited way
to try to discover the problem for which Ken's workaround provided the cure,
but without success.
3
I also just now added "fontconfig" to my setup using "setup -P fontconfig" and
then also ran the command
fc-cache -v
at the bash prompt, and whilst achieving a raft of checks, this has not
addressed the original postinstall error
message.
I did not really think it would, guessing that if the fontconfig package were
to successfully address such a
basic (and recurrent) fault, then it would necessarily have been included in
Base.
So: nil progress, but thank you for your suggestion.
--
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: postinstall: fontconfig abnormal exit
Greetings, Fergus Daly!
> Sorry if this has been asked 4 million times already.
> During postinstall, both at ground-zero installation and at every update
> thereafter, and for both Cygwin-32 and -64,
> (both using the appropriate setup-x86[_64].exe) I get:
> running: {pathToCygwin}\bin\bash.exe --norc --noprofile
> "/etc/postinstall/fontconfig_dtd.sh"
> abnormal exit: exit code=2
> Is there something that can be done to address this "error", if that is
> what it is, or is it just a quirk of setup?
Run the same command manually and see where it's failing.
IIRC (as this has been raised before), the problem is that a certain
file/directory not exists.
Check the mailing list archive?
--
With best regards,
Andrey Repin
Tuesday, September 8, 2020 17:16:06
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: Linux
>1 [main] ssh 11260 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer >The information contained in this message is proprietary and/or confidential. >If you are not the intended recipient, please: (i) delete the message and all >copies; (ii) do not disclose, distribute or use the message in any manner; and >(iii) notify the sender immediately. In addition, please be aware that any >message addressed to our domain is subject to archiving and review by persons >other than the intended recipient. Thank you. 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
Linux
1 [main] ssh 11260 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- 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
[ANNOUNCEMENT] Updated: znc-1.8.2-1
Version 1.8.2-1 of "znc" has been uploaded. ZNC is an IRC network bouncer (BNC). It can detach the client from the actual IRC server, and also from selected channels. Multiple clients from different locations can connect to a single ZNC account simultaneously and therefore appear under the same nickname on IRC. It supports SSL connections, IPv6, and is extensible via various modules. This is new upstream minor release. See https://wiki.znc.in/ChangeLog/1.8.2 for details. -- 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
Updated: znc-1.8.2-1
Version 1.8.2-1 of "znc" has been uploaded. ZNC is an IRC network bouncer (BNC). It can detach the client from the actual IRC server, and also from selected channels. Multiple clients from different locations can connect to a single ZNC account simultaneously and therefore appear under the same nickname on IRC. It supports SSL connections, IPv6, and is extensible via various modules. This is new upstream minor release. See https://wiki.znc.in/ChangeLog/1.8.2 for details.
Re: postinstall: fontconfig abnormal exit
On 08/09/2020 07:43, Fergus Daly via Cygwin wrote:
> Sorry if this has been asked 4 million times already.
> During postinstall, both at ground-zero installation and at every update
> thereafter, and for both Cygwin-32 and -64,
> (both using the appropriate setup-x86[_64].exe) I get:
> running: {pathToCygwin}\bin\bash.exe --norc --noprofile
> "/etc/postinstall/fontconfig_dtd.sh"
> abnormal exit: exit code=2
> Is there something that can be done to address this "error", if that is what
> it is, or is it just a quirk of setup?
> Thank you!
>
> --
> 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
I have this issue too, at least on first install. I just ignored it and
assumed it wasn't a big deal, but it would be nice to know why this
happens if others experience it too.
Hamish
0x87B761FE07F548D6.asc
Description: application/pgp-keys
signature.asc
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
[PATCH] Cygwin: pty: Fix input charset for non-cygwin apps with disable_pcon.
- If the non-cygwin apps is executed under pseudo console disabled,
multibyte input for the apps are garbled. This patch fixes the
issue.
---
winsup/cygwin/fhandler_tty.cc | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 6de591d9b..afaa4546e 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -271,8 +271,17 @@ fhandler_pty_master::accept_input ()
bytes_left = eat_readahead (-1);
HANDLE write_to = get_output_handle ();
+ char *buf = NULL;
if (to_be_read_from_pcon ())
-write_to = to_slave;
+{
+ write_to = to_slave;
+ size_t nlen;
+ buf = convert_mb_str (GetConsoleCP (), ,
+ get_ttyp ()->term_code_page,
+ (const char *) p, bytes_left);
+ p = buf;
+ bytes_left = nlen;
+}
if (!bytes_left)
{
@@ -305,6 +314,8 @@ fhandler_pty_master::accept_input ()
}
}
}
+ if (buf)
+mb_str_free (buf);
SetEvent (input_available_event);
ReleaseMutex (input_mutex);
--
2.28.0
Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"
Hi Corinna, On Tue, 8 Sep 2020 10:40:34 +0200 Corinna Vinschen wrote: > On Sep 7 13:45, Takashi Yano via Cygwin-patches wrote: > > On Mon, 7 Sep 2020 01:04:13 +0900 > > > > Chages: > > > > - If global locale is set, it takes precedence. > > > > > > Changes: > > > - Use __get_current_locale() instead of __get_global_locale(). > > > - Fix a bug for ISO-8859-* charset. > > > > Changes: > > - Use envblock if it is passed to CreateProcess in spawn.cc. > > For the time being and to make at least *some* progress and with my > upcoming "away from keyboard"-time , I pushed the gist of my patch, > replacing the locale evaluating code in fhandler_tty with the function > __eval_codepage_from_internal_charset in its most simple form. > I didn't touch anything else, given that this discussion is still > ongoing. Your patch pushed does the magic! Even cygterm works even though the code does not check environment. The point is here. @@ -1977,9 +1807,6 @@ fhandler_pty_slave::fixup_after_exec () if (!close_on_exec ()) fixup_after_fork (NULL); /* No parent handle required. */ - /* Set locale */ - setup_locale (); - /* Hook Console API */ #define DO_HOOK(module, name) \ if (!name##_Orig) \ Without this deletion, term_code_page is determined when cygwin shell is executed. Since it is in fixup_after_exec(), setlocale() does not called yet in the shell. As a result, term_code_page cannot be determined correctly. In your new patch, term_code_page is determined when the first non-cygwin program is execed in the shell. The shell process already calls setlocale(), so term_code_page can be determined using global locale. Thanks for the excellent idea! Only the problem I noticed is that cygterm does not work if the shell does not call setlocale(). This happens if the shell is non-cygwin program, for example, cmd.exe, however, it is unusual case. -- Takashi Yano
Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"
On Sep 7 13:45, Takashi Yano via Cygwin-patches wrote: > On Mon, 7 Sep 2020 01:04:13 +0900 > > > Chages: > > > - If global locale is set, it takes precedence. > > > > Changes: > > - Use __get_current_locale() instead of __get_global_locale(). > > - Fix a bug for ISO-8859-* charset. > > Changes: > - Use envblock if it is passed to CreateProcess in spawn.cc. For the time being and to make at least *some* progress and with my upcoming "away from keyboard"-time , I pushed the gist of my patch, replacing the locale evaluating code in fhandler_tty with the function __eval_codepage_from_internal_charset in its most simple form. I didn't touch anything else, given that this discussion is still ongoing. Corinna
Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"
On Mon, 7 Sep 2020 23:17:36 +0200 (CEST)
Johannes Schindelin wrote:
> Hi Takashi,
>
> On Sat, 5 Sep 2020, Takashi Yano wrote:
>
> > On Fri, 4 Sep 2020 08:23:42 +0200 (CEST)
> > Johannes Schindelin wrote:
> > >
> > > On Fri, 4 Sep 2020, Takashi Yano via Cygwin-patches wrote:
> > >
> > > > On Tue, 1 Sep 2020 18:19:16 +0200 (CEST)
> > > > Johannes Schindelin wrote:
> > > >
> > > > > When `LANG=en_US.UTF-8`, the detected `LCID` is 0x0409, which is
> > > > > correct, but after that (at least if Pseudo Console support is
> > > > > enabled),
> > > > > we try to find the default code page for that `LCID`, which is ASCII
> > > > > (437). Subsequently, we set the Console output code page to that
> > > > > value,
> > > > > completely ignoring that we wanted to use UTF-8.
> > > > >
> > > > > Let's not ignore the specifically asked-for UTF-8 character set.
> > > > >
> > > > > While at it, let's also set the Console output code page even if
> > > > > Pseudo
> > > > > Console support is disabled; contrary to the behavior of v3.0.7, the
> > > > > Console output code page is not ignored in that case.
> > > > >
> > > > > The most common symptom would be that console applications which do
> > > > > not
> > > > > specifically call `SetConsoleOutputCP()` but output UTF-8-encoded text
> > > > > seem to be broken with v3.1.x when they worked plenty fine with
> > > > > v3.0.x.
> > > > >
> > > > > This fixes https://github.com/msys2/MSYS2-packages/issues/1974,
> > > > > https://github.com/msys2/MSYS2-packages/issues/2012,
> > > > > https://github.com/rust-lang/cargo/issues/8369,
> > > > > https://github.com/git-for-windows/git/issues/2734,
> > > > > https://github.com/git-for-windows/git/issues/2793,
> > > > > https://github.com/git-for-windows/git/issues/2792, and possibly
> > > > > quite a
> > > > > few others.
> > > > >
> > > > > Signed-off-by: Johannes Schindelin
> > > > > ---
> > > > > winsup/cygwin/fhandler_tty.cc | 9 +
> > > > > 1 file changed, 9 insertions(+)
> > > > >
> > > > > diff --git a/winsup/cygwin/fhandler_tty.cc
> > > > > b/winsup/cygwin/fhandler_tty.cc
> > > > > index 06789a500..414c26992 100644
> > > > > --- a/winsup/cygwin/fhandler_tty.cc
> > > > > +++ b/winsup/cygwin/fhandler_tty.cc
> > > > > @@ -2859,6 +2859,15 @@ fhandler_pty_slave::setup_locale (void)
> > > > >char charset[ENCODING_LEN + 1] = "ASCII";
> > > > >LCID lcid = get_langinfo (locale, charset);
> > > > >
> > > > > + /* Special-case the UTF-8 character set */
> > > > > + if (strcasecmp (charset, "UTF-8") == 0)
> > > > > +{
> > > > > + get_ttyp ()->term_code_page = CP_UTF8;
> > > > > + SetConsoleCP (CP_UTF8);
> > > > > + SetConsoleOutputCP (CP_UTF8);
> > > > > + return;
> > > > > +}
> > > > > +
> > > > >/* Set console code page from locale */
> > > > >if (get_pseudo_console ())
> > > > > {
> > > > > --
> > > > > 2.27.0
> > > >
> > > > I would like to propose a counter patch attached.
> > > > What do you think of this patch?
> > > >
> > > > This patch does not treat UTF-8 as special.
> > >
> > > Sure, but it only fixes the issue in `disable_pcon` mode in the current
> > > tip commit. That's because a new Pseudo Console is created for every
> > > spawned non-Cygwin console application, and that new Pseudo Console does
> > > _not_ have the code page set by your patch.
> >
> > You are right. However, if pseudo console is enabled, the app
> > which works correclty in command prompt should work as well in
> > pseudo console. Therefore, there is nothing to be fixed.
>
> I am coming to the conclusion that your definition what is correct differs
> from my definition of what is correct.
>
> For me, it matters what users see. And what users actually see is the
> output of UTF-8 encoded text that is now interpreted via the default code
> page of their LCID, i.e. it is incorrect.
>
> Sure, you can argue all you want that those console applications are _all
> wrong_. _All of them_.
>
> In practice, that matters very little, as many users have
> `LANG=en_US.UTF-8` (meaning your patches force their console applications'
> output to be interpreted with code page 437) and therefore for those
> users, things looked fine before, and now they don't.
>
> Note that I am not talking about developers who develop said console
> applications. I am talking about users who use those console applications.
> In other words, I am talking about a vastly larger group of affected
> people.
>
> All of those people (or at least a substantial majority) will now have to
> be told to please disable Pseudo Console support in v3.2.0 because they
> would have to patch and rebuild those console applications that don't call
> `SetConsoleOutputCP()`, and that is certainly unreasonable to expect of
> the majority of users. Not even the `cmd /c chcp 65001` work-around (that
> helps with v3.1.7) will work with v3.2.0 when Pseudo Console support is
> enabled.
In the case where pseudo console is disabled, the patch I
Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"
On Sep 7 22:40, Takashi Yano via Cygwin-patches wrote:
> Here is a summary of my points:
>
> [Senario 1]
> 1) Start mintty (UTF-8).
> 2) Start another mintty by
> mintty -o charset=SJIS
>from the first mintty.
>
> [Senario 2]
> int pm = getpt();
> if (fork()) {
> [do the master operations]
> } else {
> setsid();
> ps = open(ptsname(pm), O_RDWR);
> close(pm);
> dup2(ps, 0);
> dup2(ps, 1);
> dup2(ps, 2);
> close(ps);
> setenv("LANG", "ja_JP.SJIS", 1);
> [exec shell]
> }
>
>
> Q1) cygheap or tty shared memory?
>
> Consider senario 1. If the term_code_page is in cygheap,
> it is inherited to child process. Therefore, the second
> mintty cannot update term_code_page while locale is changed.
>
> Consider senario 2. Since only the child process knows the
> locale, master (parent process) cannot get term_code_page
> if it is in cygheap.
>
> Q2) Is checking environment necessary?
>
> As for senario 2, setlocale() is not called. So it is
> necessary to check environment to know locale.
>
> Q3) Where and when should term_code_page be set?
>
> In senario 2, LANG is set just before exec() in the CHILD
> process. Therefore, term_code_page should be determined
> in the child_info_spawn:worker or in the execed process.
What bugs me here is that in scenario 1, the codeset of the master side
is the defining factor, while in case 2 the slave side is the defining
factor.
Actually, the only defining factor is the codeset of the master side of
the pty. If the master side interprets all input as utf-8, then the
slave side should either send utf-8, or live with the consequences.
It's the task of the *user* on the slave side, to set the env setting
matching to the master side.
I tend to agree with Johannes. We should not enforce a codepage setting
inside Cygwin. The bytes should go to the master side and the master
side interprets them. If native apps produce garbage, well, I'm not
overly sympathetic. Especially given the fact that even Microsoft is
now doing a lot to switch to UTF-8 as much as possible. It's the only
sane option anyway.
Corinna
Re: update with apt-cyg ?
On Sun 2020-09-06 (19:11), Brian Inglis wrote: > If using unattended (--quiet) mode, you have to specify everything else: > > $ ./setup-x86_64 -gq -R "$rootdir" -l "$pkgdir" -s $site > > otherwise try semi-attended (--package-manager) chooser-only mode: > > $ ./setup-x86_64 -gM -R "$rootdir" -l "$pkgdir" -s $site My cygwin installation directory is in the users windows home directory, eg: W10dev:/: cygpath -w / C:\Users\framstag\cygwin Shall I use setup-x86_64 -B ... ? I found a directory named C:\Users\framstag\cygwin\.pkg-cache Is this the value I sould use for $pkgdir ? > Defaults should have been saved in /etc/setup/setup.rc This seems not to be true for my installations. How can I add the defaults for $rootdir $pkgdir $site afterwards? -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de Allmandring 30aTel:++49-711-68565868 70569 Stuttgart (Germany) WWW:http://www.tik.uni-stuttgart.de/ REF:<8a6a9c60-5c8a-a322-0b5e-2210be28e...@systematicsw.ab.ca> -- 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: cygwin1.dll: uname_x not found
On Sep 7 14:34, L A Walsh wrote: > > > > > I uploaded new snapshots for testing to https://cygwin.com/snapshots/ > > > > Please give them a try. > --- > Got: > > "The procedure entry point uname_x could not be located in the dynamic > link library cygwin1.dll" > > :-( uname_x is exported just fine. You're doing something wrong. Corinna -- Corinna Vinschen Cygwin Maintainer -- 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
Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities
Cygwin Configuration Diagnostics Current System Time: Mon Sep 07 07:11:16 2020 Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1 Path: C:\CygWin\home\The.User\bin C:\CygWin\usr\local\bin C:\CygWin\bin C:\CygWin\lib\lapack Output from C:\CygWin\bin\id.exe UID: 197608(The.User) GID: 197121(None) 197121(None) 114(Local account and member of Administrators group) 544(Administrators) 545(Users) 4(INTERACTIVE) 66049(CONSOLE LOGON) 11(Authenticated Users) 15(This Organization) 113(Local account) 4095(CurrentSession) 66048(LOCAL) 262154(NTLM Authentication) 405504(High Mandatory Level) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'The.User' PWD = '/home/The.User' HOME = '/home/The.User' USERDOMAIN = 'The_Computer' OS = 'Windows_NT' LS_COLORS = 'rs=0:di=01;35:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01 ;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' PROCESSOR_LEVEL = '6' PSModulePath = 'C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules' CommonProgramW6432 = 'C:\Program Files\Common Files' TEMPHOME = 'C:\TEMP' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' FP_NO_HOST_CHECK = 'NO' LANG = 'en_US.UTF-8' TZ = 'America/Phoenix' HOSTNAME = 'The_Computer' PUBLIC = 'C:\Users\Public' OLDPWD = '/tmp' DIRCMD = '/a/r/o:gn' USERNAME = 'The.User' LOGONSERVER = '\\The_Computer' PROCESSOR_ARCHITECTURE = 'AMD64' TMP0 = 'C:\Users\The.User\AppData\Local\Temp' PHPRC = 'C:\PHP' LOCALAPPDATA = 'C:\Users\The.User\AppData\Local' COMPUTERNAME = 'The_Computer' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Users\The.User' PHP_INI_PATH = 'C:\PHP' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PHP' SYSTEMROOT = 'C:\Windows' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 42 Stepping 7, GenuineIntel' TMP = '/tmp' TERM_PROGRAM = 'mintty' TERM_PROGRAM_VERSION = '3.3.0' windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log' TEMP0 = 'C:\Users\The.User\AppData\Local\Temp' UNWEEDED_PATH = '/home/The.User/bin:/usr/local/bin:/usr/bin:/cygdrive/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/usr/bin:/cygdrive/c/MY FOLDERS/UTILS:/cygdrive/c/MY FOLDERS/SYSINTERNALS:/cygdrive/c/MY FOLDERS/UTILITIES/BeCy:/cygdrive/c/MY_FOLDERS/UTILITIES/EXIFTool:/cygdrive/c/PHP:/cygdrive/c/Perl64/site/bin:/cygdrive/c/Perl64/bin:/cygdrive/c/Program Files/Oracle/VirtualBox:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/MY FOLDERS/POWERSHELL:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/MY FOLDERS/UTILITIES/Windows7XSupportTools:/usr/lib/lapack' PROCESSOR_REVISION = '2a07' INDENT_PROFILE = '/home/The.User/INDENT.PROFILE' PROFILEREAD = 'true' PROMPT = '[$D$S$T$H$H$H$H$H$H]$S$C$P$F:$S$S' NUMBER_OF_PROCESSORS = '8' ProgramW6432 = 'C:\Program Files' windows_tracing_flags = '3' PATH_ORIG = 'C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\' COMSPEC = 'C:\Windows\system32\cmd.exe' APPDATA = 'C:\Users\The.User\AppData\Roaming' SHELL = '/bin/bash' TERM = 'xterm' WINDIR = 'C:\Windows' ProgramData = 'C:\ProgramData' SHLVL = '1' MINTTY_SHORTCUT = '/cygdrive/c/Users/Public/Desktop/Cygwin64 Terminal.lnk' PRINTER = 'Canon MG6800 series Printer' PROGRAMFILES = 'C:\Program Files' ALLUSERSPROFILE = 'C:\ProgramData' TEMP = '/tmp' SESSIONNAME = 'Console' My_Current_Path = 'C:\Program Files\Python38\Scripts\;C:\Program
