Re: Display text file using less in Cygwin terminal or xterm incorrect when lines are longer than window width
On 2021-08-13 22:05, C Linus Hicks via Cygwin wrote: On Sat, 2021-08-14 at 12:59 +0900, Takashi Yano wrote: On Fri, 13 Aug 2021 23:46:35 -0400 C Linus Hicks wrote: On Fri, 2021-08-13 at 23:27 -0400, C Linus Hicks via Cygwin wrote: On Sat, 2021-08-14 at 11:48 +0900, Takashi Yano wrote: On Fri, 13 Aug 2021 21:47:53 -0400 C Linus Hicks wrote: On Mon, 2021-08-09 at 15:17 -0400, C Linus Hicks via Cygwin wrote: On Sat, 2021-08-07 at 13:33 -0600, Brian Inglis wrote: Works Just Fine For Me! This is Cygwin 64 on Windows 10 in a VirtualBox VM, cygcheck output attached. It has been a while since I updated Cygwin; as long as it serves my purpose, I generally don't focus on that; it is just a tool I use. Since I did open this thread, of course I need to make sure I am up-to-date. I have now done that and I don't see issues with Cygwin terminal and less, although that is not really where I am focusing. I mostly use xterm windows just because there are several characteristics I like about it. I am still seeing issues with xterm and less, as I stated in my original post. Did I post this in the wrong list? I have not gotten a response since my update. 1) Does your problem also happen even if the text file contains only ASCII chars? 2) What does 'which less' say? 3) What does 'infocmp' say? Most of the files I view have only ASCII text. lhicks@ESG-Win10-1 ~ $ echo $TERM xterm lhicks@ESG-Win10-1 ~ $ which less /usr/bin/less lhicks@ESG-Win10-1 ~ $ infocmp # Reconstructed via infocmp from file: /usr/share/terminfo/78/xterm I should further note that much of the time I am ssh'ed into one of several different Linux machines, so in that case, I would be running less from the Linux machine and displaying in the Cygwin xterm. Hmmm, so now I'm starting to think the combination I have trouble with is an older less on a Linux machine and Cygwin xterm. I don't control what is installed on some of these Linux machines. Do you know if there were known issues with less, for example, the following is one that has significant issues: [appldev3@ebs-app-dev3 HAF]$ less --version less 458 (POSIX regular expressions) Copyright (C) 1984-2012 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Homepage: http://www.greenwoodsoftware.com/less Then, could you please let us know the result of infocmp in the Linux machine you run the less obove in cygwin xterm? CentOS 7? xterm 295? ncurses 5.9? -- 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 binary 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: Display text file using less in Cygwin terminal or xterm incorrect when lines are longer than window width
On Sat, 14 Aug 2021 00:05:17 -0400
C Linus Hicks wrote:
> On Sat, 2021-08-14 at 12:59 +0900, Takashi Yano wrote:
> > On Fri, 13 Aug 2021 23:46:35 -0400
> > C Linus Hicks wrote:
> >
> > > On Fri, 2021-08-13 at 23:27 -0400, C Linus Hicks via Cygwin wrote:
> > > > On Sat, 2021-08-14 at 11:48 +0900, Takashi Yano wrote:
> > > > > On Fri, 13 Aug 2021 21:47:53 -0400
> > > > > C Linus Hicks wrote:
> > > > > > On Mon, 2021-08-09 at 15:17 -0400, C Linus Hicks via Cygwin wrote:
> > > > > > > On Sat, 2021-08-07 at 13:33 -0600, Brian Inglis wrote:
> > > > > > > > Works Just Fine For Me!
> > > > > > > >
> > > > > > > This is Cygwin 64 on Windows 10 in a VirtualBox VM, cygcheck
> > > > > > > output attached.
> > > > > > >
> > > > > > > It has been a while since I updated Cygwin; as long as it serves
> > > > > > > my purpose, I generally don't focus
> > > > > > > on that; it is just a tool I use.
> > > > > > >
> > > > > > > Since I did open this thread, of course I need to make sure I am
> > > > > > > up-to-date. I have now done that
> > > > > > > and I don't see issues with Cygwin terminal and less, although
> > > > > > > that is not really where I am
> > > > > > > focusing. I mostly use xterm windows just because there are
> > > > > > > several characteristics I like about it.
> > > > > > >
> > > > > > > I am still seeing issues with xterm and less, as I stated in my
> > > > > > > original post.
> > > > > > >
> > > > > > Did I post this in the wrong list? I have not gotten a response
> > > > > > since my update.
> > > > >
> > > > > 1) Does your problem also happen even if the text file contains only
> > > > >ASCII chars?
> > > > > 2) What does 'which less' say?
> > > > > 3) What does 'infocmp' say?
> > > > >
> > > >
> > > > Most of the files I view have only ASCII text.
> > > >
> > > > lhicks@ESG-Win10-1 ~
> > > > $ echo $TERM
> > > > xterm
> > > >
> > > > lhicks@ESG-Win10-1 ~
> > > > $ which less
> > > > /usr/bin/less
> > > >
> > > > lhicks@ESG-Win10-1 ~
> > > > $ infocmp
> > > > # Reconstructed via infocmp from file:
> > > > /usr/share/terminfo/78/xterm
> > > >
> > >
> > > I should further note that much of the time I am ssh'ed into one of
> > > several different Linux
> > > machines, so in that case, I would be running less from the Linux machine
> > > and displaying in the
> > > Cygwin xterm.
> > >
> > > Hmmm, so now I'm starting to think the combination I have trouble with is
> > > an older less on a Linux
> > > machine and Cygwin xterm. I don't control what is installed on some of
> > > these Linux machines. Do you
> > > know if there were known issues with less, for example, the following is
> > > one that has significant
> > > issues:
> > >
> > > [appldev3@ebs-app-dev3 HAF]$ less --version
> > > less 458 (POSIX regular expressions)
> > > Copyright (C) 1984-2012 Mark Nudelman
> > >
> > > less comes with NO WARRANTY, to the extent permitted by law.
> > > For information about the terms of redistribution,
> > > see the file named README in the less distribution.
> > > Homepage: http://www.greenwoodsoftware.com/less
> >
> > Then, could you please let us know the result of infocmp in the Linux
> > machine you run the less obove in cygwin xterm?
> >
>
> [appldev3@ebs-app-dev3 HAF]$ infocmp
> # Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm
> xterm|xterm terminal emulator (X Window System),
> am, bce, km, mc5i, mir, msgr, npc, xenl,
> colors#8, cols#80, it#8, lines#24, pairs#64,
> acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
> bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
> clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M,
> csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
> cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
> cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
> cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
> dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K,
> flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG,
> ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L,
> ind=^J, indn=\E[%p1%dS, invis=\E[8m,
> is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F,
> kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~,
> kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=\177, kcbt=\E[Z,
> kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
> kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
> kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
> kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
> kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
> kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
> kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
> kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
> kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
> kf35=\E[23;5~, kf36=\E[24;5~,
Re: Display text file using less in Cygwin terminal or xterm incorrect when lines are longer than window width
On Sat, 2021-08-14 at 12:59 +0900, Takashi Yano wrote:
> On Fri, 13 Aug 2021 23:46:35 -0400
> C Linus Hicks wrote:
>
> > On Fri, 2021-08-13 at 23:27 -0400, C Linus Hicks via Cygwin wrote:
> > > On Sat, 2021-08-14 at 11:48 +0900, Takashi Yano wrote:
> > > > On Fri, 13 Aug 2021 21:47:53 -0400
> > > > C Linus Hicks wrote:
> > > > > On Mon, 2021-08-09 at 15:17 -0400, C Linus Hicks via Cygwin wrote:
> > > > > > On Sat, 2021-08-07 at 13:33 -0600, Brian Inglis wrote:
> > > > > > > Works Just Fine For Me!
> > > > > > >
> > > > > > This is Cygwin 64 on Windows 10 in a VirtualBox VM, cygcheck output
> > > > > > attached.
> > > > > >
> > > > > > It has been a while since I updated Cygwin; as long as it serves my
> > > > > > purpose, I generally don't focus
> > > > > > on that; it is just a tool I use.
> > > > > >
> > > > > > Since I did open this thread, of course I need to make sure I am
> > > > > > up-to-date. I have now done that
> > > > > > and I don't see issues with Cygwin terminal and less, although that
> > > > > > is not really where I am
> > > > > > focusing. I mostly use xterm windows just because there are several
> > > > > > characteristics I like about it.
> > > > > >
> > > > > > I am still seeing issues with xterm and less, as I stated in my
> > > > > > original post.
> > > > > >
> > > > > Did I post this in the wrong list? I have not gotten a response since
> > > > > my update.
> > > >
> > > > 1) Does your problem also happen even if the text file contains only
> > > >ASCII chars?
> > > > 2) What does 'which less' say?
> > > > 3) What does 'infocmp' say?
> > > >
> > >
> > > Most of the files I view have only ASCII text.
> > >
> > > lhicks@ESG-Win10-1 ~
> > > $ echo $TERM
> > > xterm
> > >
> > > lhicks@ESG-Win10-1 ~
> > > $ which less
> > > /usr/bin/less
> > >
> > > lhicks@ESG-Win10-1 ~
> > > $ infocmp
> > > # Reconstructed via infocmp from file: /usr/share/terminfo/78/xterm
> > >
> >
> > I should further note that much of the time I am ssh'ed into one of several
> > different Linux
> > machines, so in that case, I would be running less from the Linux machine
> > and displaying in the
> > Cygwin xterm.
> >
> > Hmmm, so now I'm starting to think the combination I have trouble with is
> > an older less on a Linux
> > machine and Cygwin xterm. I don't control what is installed on some of
> > these Linux machines. Do you
> > know if there were known issues with less, for example, the following is
> > one that has significant
> > issues:
> >
> > [appldev3@ebs-app-dev3 HAF]$ less --version
> > less 458 (POSIX regular expressions)
> > Copyright (C) 1984-2012 Mark Nudelman
> >
> > less comes with NO WARRANTY, to the extent permitted by law.
> > For information about the terms of redistribution,
> > see the file named README in the less distribution.
> > Homepage: http://www.greenwoodsoftware.com/less
>
> Then, could you please let us know the result of infocmp in the Linux
> machine you run the less obove in cygwin xterm?
>
[appldev3@ebs-app-dev3 HAF]$ infocmp
# Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm
xterm|xterm terminal emulator (X Window System),
am, bce, km, mc5i, mir, msgr, npc, xenl,
colors#8, cols#80, it#8, lines#24, pairs#64,
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K,
flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG,
ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L,
ind=^J, indn=\E[%p1%dS, invis=\E[8m,
is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F,
kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~,
kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=\177, kcbt=\E[Z,
kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
kf51=\E[1;3R,
Re: Display text file using less in Cygwin terminal or xterm incorrect when lines are longer than window width
On Fri, 13 Aug 2021 23:46:35 -0400 C Linus Hicks wrote: > On Fri, 2021-08-13 at 23:27 -0400, C Linus Hicks via Cygwin wrote: > > On Sat, 2021-08-14 at 11:48 +0900, Takashi Yano wrote: > > > On Fri, 13 Aug 2021 21:47:53 -0400 > > > C Linus Hicks wrote: > > > > On Mon, 2021-08-09 at 15:17 -0400, C Linus Hicks via Cygwin wrote: > > > > > On Sat, 2021-08-07 at 13:33 -0600, Brian Inglis wrote: > > > > > > Works Just Fine For Me! > > > > > > > > > > > This is Cygwin 64 on Windows 10 in a VirtualBox VM, cygcheck output > > > > > attached. > > > > > > > > > > It has been a while since I updated Cygwin; as long as it serves my > > > > > purpose, I generally don't focus > > > > > on that; it is just a tool I use. > > > > > > > > > > Since I did open this thread, of course I need to make sure I am > > > > > up-to-date. I have now done that > > > > > and I don't see issues with Cygwin terminal and less, although that > > > > > is not really where I am > > > > > focusing. I mostly use xterm windows just because there are several > > > > > characteristics I like about it. > > > > > > > > > > I am still seeing issues with xterm and less, as I stated in my > > > > > original post. > > > > > > > > > Did I post this in the wrong list? I have not gotten a response since > > > > my update. > > > > > > 1) Does your problem also happen even if the text file contains only > > >ASCII chars? > > > 2) What does 'which less' say? > > > 3) What does 'infocmp' say? > > > > > > > Most of the files I view have only ASCII text. > > > > lhicks@ESG-Win10-1 ~ > > $ echo $TERM > > xterm > > > > lhicks@ESG-Win10-1 ~ > > $ which less > > /usr/bin/less > > > > lhicks@ESG-Win10-1 ~ > > $ infocmp > > # Reconstructed via infocmp from file: /usr/share/terminfo/78/xterm > > > > I should further note that much of the time I am ssh'ed into one of several > different Linux > machines, so in that case, I would be running less from the Linux machine and > displaying in the > Cygwin xterm. > > Hmmm, so now I'm starting to think the combination I have trouble with is an > older less on a Linux > machine and Cygwin xterm. I don't control what is installed on some of these > Linux machines. Do you > know if there were known issues with less, for example, the following is one > that has significant > issues: > > [appldev3@ebs-app-dev3 HAF]$ less --version > less 458 (POSIX regular expressions) > Copyright (C) 1984-2012 Mark Nudelman > > less comes with NO WARRANTY, to the extent permitted by law. > For information about the terms of redistribution, > see the file named README in the less distribution. > Homepage: http://www.greenwoodsoftware.com/less Then, could you please let us know the result of infocmp in the Linux machine you run the less obove in cygwin xterm? -- Takashi Yano -- 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: Display text file using less in Cygwin terminal or xterm incorrect when lines are longer than window width
On Fri, 2021-08-13 at 23:27 -0400, C Linus Hicks via Cygwin wrote: > On Sat, 2021-08-14 at 11:48 +0900, Takashi Yano wrote: > > On Fri, 13 Aug 2021 21:47:53 -0400 > > C Linus Hicks wrote: > > > On Mon, 2021-08-09 at 15:17 -0400, C Linus Hicks via Cygwin wrote: > > > > On Sat, 2021-08-07 at 13:33 -0600, Brian Inglis wrote: > > > > > Works Just Fine For Me! > > > > > > > > > This is Cygwin 64 on Windows 10 in a VirtualBox VM, cygcheck output > > > > attached. > > > > > > > > It has been a while since I updated Cygwin; as long as it serves my > > > > purpose, I generally don't focus > > > > on that; it is just a tool I use. > > > > > > > > Since I did open this thread, of course I need to make sure I am > > > > up-to-date. I have now done that > > > > and I don't see issues with Cygwin terminal and less, although that is > > > > not really where I am > > > > focusing. I mostly use xterm windows just because there are several > > > > characteristics I like about it. > > > > > > > > I am still seeing issues with xterm and less, as I stated in my > > > > original post. > > > > > > > Did I post this in the wrong list? I have not gotten a response since my > > > update. > > > > 1) Does your problem also happen even if the text file contains only > >ASCII chars? > > 2) What does 'which less' say? > > 3) What does 'infocmp' say? > > > > Most of the files I view have only ASCII text. > > lhicks@ESG-Win10-1 ~ > $ echo $TERM > xterm > > lhicks@ESG-Win10-1 ~ > $ which less > /usr/bin/less > > lhicks@ESG-Win10-1 ~ > $ infocmp > # Reconstructed via infocmp from file: /usr/share/terminfo/78/xterm > I should further note that much of the time I am ssh'ed into one of several different Linux machines, so in that case, I would be running less from the Linux machine and displaying in the Cygwin xterm. Hmmm, so now I'm starting to think the combination I have trouble with is an older less on a Linux machine and Cygwin xterm. I don't control what is installed on some of these Linux machines. Do you know if there were known issues with less, for example, the following is one that has significant issues: [appldev3@ebs-app-dev3 HAF]$ less --version less 458 (POSIX regular expressions) Copyright (C) 1984-2012 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Homepage: http://www.greenwoodsoftware.com/less -- 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: Display text file using less in Cygwin terminal or xterm incorrect when lines are longer than window width
On Fri, 13 Aug 2021 23:27:44 -0400
C Linus Hicks wrote:
> On Sat, 2021-08-14 at 11:48 +0900, Takashi Yano wrote:
> > On Fri, 13 Aug 2021 21:47:53 -0400
> > C Linus Hicks wrote:
> > > On Mon, 2021-08-09 at 15:17 -0400, C Linus Hicks via Cygwin wrote:
> > > > On Sat, 2021-08-07 at 13:33 -0600, Brian Inglis wrote:
> > > > > Works Just Fine For Me!
> > > > >
> > > > This is Cygwin 64 on Windows 10 in a VirtualBox VM, cygcheck output
> > > > attached.
> > > >
> > > > It has been a while since I updated Cygwin; as long as it serves my
> > > > purpose, I generally don't focus
> > > > on that; it is just a tool I use.
> > > >
> > > > Since I did open this thread, of course I need to make sure I am
> > > > up-to-date. I have now done that
> > > > and I don't see issues with Cygwin terminal and less, although that is
> > > > not really where I am
> > > > focusing. I mostly use xterm windows just because there are several
> > > > characteristics I like about it.
> > > >
> > > > I am still seeing issues with xterm and less, as I stated in my
> > > > original post.
> > > >
> > > Did I post this in the wrong list? I have not gotten a response since my
> > > update.
> >
> > 1) Does your problem also happen even if the text file contains only
> >ASCII chars?
> > 2) What does 'which less' say?
> > 3) What does 'infocmp' say?
> >
>
> Most of the files I view have only ASCII text.
>
> lhicks@ESG-Win10-1 ~
> $ echo $TERM
> xterm
>
> lhicks@ESG-Win10-1 ~
> $ which less
> /usr/bin/less
>
> lhicks@ESG-Win10-1 ~
> $ infocmp
> # Reconstructed via infocmp from file: /usr/share/terminfo/78/xterm
> xterm|xterm terminal emulator (X Window System),
> am, bce, km, mc5i, mir, msgr, npc, xenl,
> colors#8, cols#80, it#8, lines#24, pairs#64,
> acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
> bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
> clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
> csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
> cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
> cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
> cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
> dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
> el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
> hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
> il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS,
> invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
> kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
> kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, ka1=\EOw,
> ka3=\EOy, kb2=\EOu, kbs=^H, kc1=\EOq, kc3=\EOs, kcbt=\E[Z,
> kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
> kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
> kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
> kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
> kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
> kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
> kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
> kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
> kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
> kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
> kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
> kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
> kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
> kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
> kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
> kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
> kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
> kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
> kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
> kind=\E[1;2B, kmous=\E[<, knp=\E[6~, kpp=\E[5~,
> kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
> memu=\Em, mgc=\E[?69l, op=\E[39;49m, rc=\E8,
> rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM,
> rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l,
> rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, rmkx=\E[?1l\E>,
> rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
> rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7, setab=\E[4%p1%dm,
> setaf=\E[3%p1%dm,
>
> setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
>
> setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
>
> sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7
> %t;8%;m,
> sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
> smcup=\E[?1049h\E[22;0;0t,
> smglr=\E[?69h\E[%i%p1%d;%p2%ds, smir=\E[4h,
> smkx=\E[?1h\E=, smm=\E[?1034h, smso=\E[7m, smul=\E[4m,
> tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
>
Re: Just updated cygutils and cygstart no longer works
On Fri, 13 Aug 2021 20:17:58 -0700 Mark Geisert wrote: > Brian Inglis wrote: > > On 2021-08-13 19:54, Takashi Yano via Cygwin wrote: > >> On Fri, 13 Aug 2021 15:20:40 -0700, Mark Geisert wrote: > >>> Jay Abel via Cygwin wrote: > On Fri, Aug 13, 2021 at 10:27 AM Jay Abel wrote: > > > Sorry, more information. I'm running Windows 10, 64-bit, AMD. > > I've reverted cygutils back to 1.4.16-2 and the problem is resolved. > > > > Run cygstart with anything and no window opens. I've tried URLS > > cygstart > > http://www.cygwin.com, directories cygstart . and cygstart ./ as well > > as > > pdf files cygstart example.pdf. > > None of these seems to do anything anymore. > > > >>> I have the same setup as you but all seems well here. With 1.4.16-3 > >>> installed all > >>> four of your testcases work for me. I don't know what to suggest. > >>> When you have a chance, what does 'echo $?' say at the prompt after > >>> cygstart > >>> finishes one of your testcases? 0 means successful, 1 (or something > >>> else) means > >>> failure. > > > >> I have the same issue with cygstart in cygutils 1.4.16-3. > >> "cygstart .; echo $?" says 0. > >> This issue only happens in 64bit cygwin and cygstart in 32bit cygwin works. > >> To look into this problem, I tried to build cygutils from source, > >> however, it fails in the link stage of getclip with the error: > >> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: > >> src/clip/getclip.o: in function `getclip': > >> /usr/src/debug/cygutils-1.4.16-3/src/clip/getclip.c:431: undefined > >> reference to > >> `__imp_RtlUnicodeToUTF8N' > >> It seems that -lntdll flag is required to build it. Doesn't this error > >> happen in your environment? > >> So I modified Makefile.am to: > >> src_clip_getclip_LDADD = -lpopt -lntdll > >> src_clip_putclip_LDADD = -lpopt -lntdll > >> and tried to build again and succeeded. > >> The cygstart built locally works fine. > >> So I tried to debug cygstart using gdb and it says: > >> Thread 1 received signal SIGILL, Illegal instruction. > >> The disassembling result at $rip is: > >> => 0x000100401c15 <+389>: vmovdqa 0x18c3(%rip),%xmm0 # > >> 0x1004034e0 > >> This is a AVX instruction. > >> My CPU is Core i7-870, which does not support AVX. > >> Then I ran cygstart in another machine whose CPU is Core i7-4790 > >> and it works without the issue. > >> Conclusion: > >> cygstart in cygutils 1.4.16-3 is compiled with AVX extentions, > >> therefore it can not run in old machine. > > > > Any chance this could have been built with test gcc 11 using non-standard > > values > > instead of defaults -march=x86-64/i686 -mtune=generic? > > No, gcc 10.2.0 was used with those defaults. In my environment: $ objdump -d /usr/bin/cygstart |grep vmovdqa 100401c15: c5 f9 6f 05 c3 18 00vmovdqa 0x18c3(%rip),%xmm0# 0x1004034e0 100401c21: c5 f9 6f 0d c7 18 00vmovdqa 0x18c7(%rip),%xmm1# 0x1004034f0 100401c2e: c5 f9 6f 15 ca 18 00vmovdqa 0x18ca(%rip),%xmm2# 0x100403500 100401c3b: c5 f9 6f 1d cd 18 00vmovdqa 0x18cd(%rip),%xmm3# 0x100403510 $ objdump -d cygutils-1.4.16-3.src/cygutils-1.4.16-3.x86_64/inst/usr/bin/cygstart | grep vmovdqa $ -- Takashi Yano -- 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: Display text file using less in Cygwin terminal or xterm incorrect when lines are longer than window width
On Sat, 2021-08-14 at 11:48 +0900, Takashi Yano wrote:
> On Fri, 13 Aug 2021 21:47:53 -0400
> C Linus Hicks wrote:
> > On Mon, 2021-08-09 at 15:17 -0400, C Linus Hicks via Cygwin wrote:
> > > On Sat, 2021-08-07 at 13:33 -0600, Brian Inglis wrote:
> > > > Works Just Fine For Me!
> > > >
> > > This is Cygwin 64 on Windows 10 in a VirtualBox VM, cygcheck output
> > > attached.
> > >
> > > It has been a while since I updated Cygwin; as long as it serves my
> > > purpose, I generally don't focus
> > > on that; it is just a tool I use.
> > >
> > > Since I did open this thread, of course I need to make sure I am
> > > up-to-date. I have now done that
> > > and I don't see issues with Cygwin terminal and less, although that is
> > > not really where I am
> > > focusing. I mostly use xterm windows just because there are several
> > > characteristics I like about it.
> > >
> > > I am still seeing issues with xterm and less, as I stated in my original
> > > post.
> > >
> > Did I post this in the wrong list? I have not gotten a response since my
> > update.
>
> 1) Does your problem also happen even if the text file contains only
>ASCII chars?
> 2) What does 'which less' say?
> 3) What does 'infocmp' say?
>
Most of the files I view have only ASCII text.
lhicks@ESG-Win10-1 ~
$ echo $TERM
xterm
lhicks@ESG-Win10-1 ~
$ which less
/usr/bin/less
lhicks@ESG-Win10-1 ~
$ infocmp
# Reconstructed via infocmp from file: /usr/share/terminfo/78/xterm
xterm|xterm terminal emulator (X Window System),
am, bce, km, mc5i, mir, msgr, npc, xenl,
colors#8, cols#80, it#8, lines#24, pairs#64,
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS,
invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, ka1=\EOw,
ka3=\EOy, kb2=\EOu, kbs=^H, kc1=\EOq, kc3=\EOs, kcbt=\E[Z,
kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
kind=\E[1;2B, kmous=\E[<, knp=\E[6~, kpp=\E[5~,
kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
memu=\Em, mgc=\E[?69l, op=\E[39;49m, rc=\E8,
rep=%p1%c\E[%p2%{1}%-%db, rev=\E[7m, ri=\EM,
rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l,
rmcup=\E[?1049l\E[23;0;0t, rmir=\E[4l, rmkx=\E[?1l\E>,
rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7, setab=\E[4%p1%dm,
setaf=\E[3%p1%dm,
setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7
%t;8%;m,
sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
smcup=\E[?1049h\E[22;0;0t,
smglr=\E[?69h\E[%i%p1%d;%p2%ds, smir=\E[4h,
smkx=\E[?1h\E=, smm=\E[?1034h, smso=\E[7m, smul=\E[4m,
tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
u8=\E[?%[;0123456789]c, u9=\E[c, vpa=\E[%i%p1%dd,
--
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: Just updated cygutils and cygstart no longer works
Hi Takashi, Thanks for that lead. It appears the Makefile.am change didn't make it into the commit for the getclip update. I'll remedy this shortly. I compiled the package with gcc 10.2.0 using the default options. Let me investigate further to find some kind of solution for the AVX usage, likely by using more/different gcc options. Thanks again, ..mark Takashi Yano via Cygwin wrote: Hi Mark, On Fri, 13 Aug 2021 15:20:40 -0700 Mark Geisert wrote: Hello Jay, Jay Abel via Cygwin wrote: Sorry, more information. I'm running Windows 10, 64-bit, AMD. I've reverted cygutils back to 1.4.16-2 and the problem is resolved. Jay On Fri, Aug 13, 2021 at 10:27 AM Jay Abel wrote: Run cygstart with anything and no window opens. I've tried URLS cygstart http://www.cygwin.com, directories cygstart . and cygstart ./ as well as pdf files cygstart example.pdf. None of these seems to do anything anymore. I have the same setup as you but all seems well here. With 1.4.16-3 installed all four of your testcases work for me. I don't know what to suggest. When you have a chance, what does 'echo $?' say at the prompt after cygstart finishes one of your testcases? 0 means successful, 1 (or something else) means failure. I have the same issue with cygstart in cygutils 1.4.16-3. "cygstart .; echo $?" says 0. This issue only happens in 64bit cygwin and cygstart in 32bit cygwin works. To look into this problem, I tried to build cygutils from source, however, it fails in the link stage of getclip with the error: /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: src/clip/getclip.o: in function `getclip': /usr/src/debug/cygutils-1.4.16-3/src/clip/getclip.c:431: undefined reference to `__imp_RtlUnicodeToUTF8N' It seems that -lntdll flag is required to build it. Doesn't this error happen in your environment? So I modified Makefile.am to: src_clip_getclip_LDADD = -lpopt -lntdll src_clip_putclip_LDADD = -lpopt -lntdll and tried to build again and succeeded. The cygstart built locally works fine. So I tried to debug cygstart using gdb and it says: Thread 1 received signal SIGILL, Illegal instruction. The disassembling result at $rip is: => 0x000100401c15 <+389>: vmovdqa 0x18c3(%rip),%xmm0# 0x1004034e0 This is a AVX instruction. My CPU is Core i7-870, which does not support AVX. Then I ran cygstart in another machine whose CPU is Core i7-4790 and it works without the issue. Conclusion: cygstart in cygutils 1.4.16-3 is compiled with AVX extentions, therefore it can not run in old machine. -- 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: Package Requests: Update: bash-completion, coreutils - New: linux-manpages
On 2021-08-13 14:48, Richard Beels via Cygwin wrote:
At 8/13/2021 at 01:11, Shakespearean monkeys danced on Brian Inglis's
keyboard and said:
I suggested linux-manpages a while back, as it comes from the same
source as posix-manpages, and I install it myself, but did not get
voted to package, due to duplication with conflicting priorities and
no easy way to resolve under existing paths.
Huh... they go to /usr/local by default (easily changeable with `make
prefix=...`), which is pretty bare to begin with and with the fact that
they don't package hardly anything in man1, the conflict potential goes
down even further. Ah well, I guess I just keep making it manually from
a cloned repo.
That's the issue - Cygwin supports project man pages installed under FHS
locations like /usr/share/man/ where there would be "duplication", not
installing in non-standard locations under /usr/local/{share/,}man/ nor
under /usr/share/man/linux/ (man -m linux)!
I could probably look at bash-completion if I can get around to bash,
as I would worry about dependencies, fixes, and tweaks. There are big
challenges in bash and coreutils being years out of date as parts of
those need customized for Cygwin, and the customization patches are
likely to have issues, or even need redesign, if there have been major
changes.
bash-completion is a separate/disconnected project (now located at
https://github.com/scop/bash-completion), it doesn't align its releases
with bash itself. bash-completion 2.7-2.10 require bash 4.1+, 2.11
bumped that to 4.2. Since we're at 4.4, I don't think that's a
showstopper (BICBW).
BYCBC|BYCBR
And thanks again for the findutils update. 4.7 gave us comma-delimited
-type/-xtype specs, so a "( -type p -o -type s )" (shown non-quoted for
sanity's sake) becomes "-type p,s". :thumbsup:
--
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 binary 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: Just updated cygutils and cygstart no longer works
Brian Inglis wrote: On 2021-08-13 19:54, Takashi Yano via Cygwin wrote: On Fri, 13 Aug 2021 15:20:40 -0700, Mark Geisert wrote: Jay Abel via Cygwin wrote: On Fri, Aug 13, 2021 at 10:27 AM Jay Abel wrote: Sorry, more information. I'm running Windows 10, 64-bit, AMD. I've reverted cygutils back to 1.4.16-2 and the problem is resolved. Run cygstart with anything and no window opens. I've tried URLS cygstart http://www.cygwin.com, directories cygstart . and cygstart ./ as well as pdf files cygstart example.pdf. None of these seems to do anything anymore. I have the same setup as you but all seems well here. With 1.4.16-3 installed all four of your testcases work for me. I don't know what to suggest. When you have a chance, what does 'echo $?' say at the prompt after cygstart finishes one of your testcases? 0 means successful, 1 (or something else) means failure. I have the same issue with cygstart in cygutils 1.4.16-3. "cygstart .; echo $?" says 0. This issue only happens in 64bit cygwin and cygstart in 32bit cygwin works. To look into this problem, I tried to build cygutils from source, however, it fails in the link stage of getclip with the error: /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: src/clip/getclip.o: in function `getclip': /usr/src/debug/cygutils-1.4.16-3/src/clip/getclip.c:431: undefined reference to `__imp_RtlUnicodeToUTF8N' It seems that -lntdll flag is required to build it. Doesn't this error happen in your environment? So I modified Makefile.am to: src_clip_getclip_LDADD = -lpopt -lntdll src_clip_putclip_LDADD = -lpopt -lntdll and tried to build again and succeeded. The cygstart built locally works fine. So I tried to debug cygstart using gdb and it says: Thread 1 received signal SIGILL, Illegal instruction. The disassembling result at $rip is: => 0x000100401c15 <+389>: vmovdqa 0x18c3(%rip),%xmm0 # 0x1004034e0 This is a AVX instruction. My CPU is Core i7-870, which does not support AVX. Then I ran cygstart in another machine whose CPU is Core i7-4790 and it works without the issue. Conclusion: cygstart in cygutils 1.4.16-3 is compiled with AVX extentions, therefore it can not run in old machine. Any chance this could have been built with test gcc 11 using non-standard values instead of defaults -march=x86-64/i686 -mtune=generic? No, gcc 10.2.0 was used with those defaults. ..mark -- 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: Display text file using less in Cygwin terminal or xterm incorrect when lines are longer than window width
On Fri, 13 Aug 2021 21:47:53 -0400 C Linus Hicks wrote: > On Mon, 2021-08-09 at 15:17 -0400, C Linus Hicks via Cygwin wrote: > > On Sat, 2021-08-07 at 13:33 -0600, Brian Inglis wrote: > > > Works Just Fine For Me! > > > > > This is Cygwin 64 on Windows 10 in a VirtualBox VM, cygcheck output > > attached. > > > > It has been a while since I updated Cygwin; as long as it serves my > > purpose, I generally don't focus > > on that; it is just a tool I use. > > > > Since I did open this thread, of course I need to make sure I am > > up-to-date. I have now done that > > and I don't see issues with Cygwin terminal and less, although that is not > > really where I am > > focusing. I mostly use xterm windows just because there are several > > characteristics I like about it. > > > > I am still seeing issues with xterm and less, as I stated in my original > > post. > > > Did I post this in the wrong list? I have not gotten a response since my > update. 1) Does your problem also happen even if the text file contains only ASCII chars? 2) What does 'which less' say? 3) What does 'infocmp' say? -- Takashi Yano -- 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: Just updated cygutils and cygstart no longer works
On 2021-08-13 19:54, Takashi Yano via Cygwin wrote: On Fri, 13 Aug 2021 15:20:40 -0700, Mark Geisert wrote: Jay Abel via Cygwin wrote: On Fri, Aug 13, 2021 at 10:27 AM Jay Abel wrote: Sorry, more information. I'm running Windows 10, 64-bit, AMD. I've reverted cygutils back to 1.4.16-2 and the problem is resolved. Run cygstart with anything and no window opens. I've tried URLS cygstart http://www.cygwin.com, directories cygstart . and cygstart ./ as well as pdf files cygstart example.pdf. None of these seems to do anything anymore. I have the same setup as you but all seems well here. With 1.4.16-3 installed all four of your testcases work for me. I don't know what to suggest. When you have a chance, what does 'echo $?' say at the prompt after cygstart finishes one of your testcases? 0 means successful, 1 (or something else) means failure. I have the same issue with cygstart in cygutils 1.4.16-3. "cygstart .; echo $?" says 0. This issue only happens in 64bit cygwin and cygstart in 32bit cygwin works. To look into this problem, I tried to build cygutils from source, however, it fails in the link stage of getclip with the error: /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: src/clip/getclip.o: in function `getclip': /usr/src/debug/cygutils-1.4.16-3/src/clip/getclip.c:431: undefined reference to `__imp_RtlUnicodeToUTF8N' It seems that -lntdll flag is required to build it. Doesn't this error happen in your environment? So I modified Makefile.am to: src_clip_getclip_LDADD = -lpopt -lntdll src_clip_putclip_LDADD = -lpopt -lntdll and tried to build again and succeeded. The cygstart built locally works fine. So I tried to debug cygstart using gdb and it says: Thread 1 received signal SIGILL, Illegal instruction. The disassembling result at $rip is: => 0x000100401c15 <+389>: vmovdqa 0x18c3(%rip),%xmm0# 0x1004034e0 This is a AVX instruction. My CPU is Core i7-870, which does not support AVX. Then I ran cygstart in another machine whose CPU is Core i7-4790 and it works without the issue. Conclusion: cygstart in cygutils 1.4.16-3 is compiled with AVX extentions, therefore it can not run in old machine. Any chance this could have been built with test gcc 11 using non-standard values instead of defaults -march=x86-64/i686 -mtune=generic? Could validate by posting /proc/cpuinfo output from non-/working systems using e.g. $ awk '/^processor\t+: +0$/,/^$/' /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 101 model name : AMD A10-9700 RADEON R7, 10 COMPUTE CORES 4C+6G stepping: 1 microcode : 0x6006118 cpu MHz : 3500.000 cache size : 1024 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl tsc_reliable nonstop_tsc cpuid aperfmperf pni pclmuldq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decode_assists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov bogomips: 7000.00 TLB size: 1536 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro acc_power $ awk '/^processor\t+: +0$/,/^$/' /proc/cpuinfo | fgrep avx flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl tsc_reliable nonstop_tsc cpuid aperfmperf pni pclmuldq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave *avx* f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate fsgsbase bmi1 *avx*2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decode_assists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov -- 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 binary units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ:
Re: Display text file using less in Cygwin terminal or xterm incorrect when lines are longer than window width
On Fri, 13 Aug 2021 21:47:53 -0400 C Linus Hicks wrote: > On Mon, 2021-08-09 at 15:17 -0400, C Linus Hicks via Cygwin wrote: > > On Sat, 2021-08-07 at 13:33 -0600, Brian Inglis wrote: > > > Works Just Fine For Me! > > > > > This is Cygwin 64 on Windows 10 in a VirtualBox VM, cygcheck output > > attached. > > > > It has been a while since I updated Cygwin; as long as it serves my > > purpose, I generally don't focus > > on that; it is just a tool I use. > > > > Since I did open this thread, of course I need to make sure I am > > up-to-date. I have now done that > > and I don't see issues with Cygwin terminal and less, although that is not > > really where I am > > focusing. I mostly use xterm windows just because there are several > > characteristics I like about it. > > > > I am still seeing issues with xterm and less, as I stated in my original > > post. > > > Did I post this in the wrong list? I have not gotten a response since my > update. No you did not. Perhaps, nobody can reproduce your problem. What does 'echo $TERM' say in your environment with the issue? -- Takashi Yano -- 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: Just updated cygutils and cygstart no longer works
Hi Mark, On Fri, 13 Aug 2021 15:20:40 -0700 Mark Geisert wrote: > Hello Jay, > > Jay Abel via Cygwin wrote: > > Sorry, more information. I'm running Windows 10, 64-bit, AMD. > > > > I've reverted cygutils back to 1.4.16-2 and the problem is resolved. > > > > Jay > > > > On Fri, Aug 13, 2021 at 10:27 AM Jay Abel wrote: > > > >> Run cygstart with anything and no window opens. I've tried URLS cygstart > >> http://www.cygwin.com, directories cygstart . and cygstart ./ as well as > >> pdf files cygstart example.pdf. > >> > >> None of these seems to do anything anymore. > > I have the same setup as you but all seems well here. With 1.4.16-3 > installed all > four of your testcases work for me. I don't know what to suggest. > > When you have a chance, what does 'echo $?' say at the prompt after cygstart > finishes one of your testcases? 0 means successful, 1 (or something else) > means > failure. I have the same issue with cygstart in cygutils 1.4.16-3. "cygstart .; echo $?" says 0. This issue only happens in 64bit cygwin and cygstart in 32bit cygwin works. To look into this problem, I tried to build cygutils from source, however, it fails in the link stage of getclip with the error: /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: src/clip/getclip.o: in function `getclip': /usr/src/debug/cygutils-1.4.16-3/src/clip/getclip.c:431: undefined reference to `__imp_RtlUnicodeToUTF8N' It seems that -lntdll flag is required to build it. Doesn't this error happen in your environment? So I modified Makefile.am to: src_clip_getclip_LDADD = -lpopt -lntdll src_clip_putclip_LDADD = -lpopt -lntdll and tried to build again and succeeded. The cygstart built locally works fine. So I tried to debug cygstart using gdb and it says: Thread 1 received signal SIGILL, Illegal instruction. The disassembling result at $rip is: => 0x000100401c15 <+389>: vmovdqa 0x18c3(%rip),%xmm0# 0x1004034e0 This is a AVX instruction. My CPU is Core i7-870, which does not support AVX. Then I ran cygstart in another machine whose CPU is Core i7-4790 and it works without the issue. Conclusion: cygstart in cygutils 1.4.16-3 is compiled with AVX extentions, therefore it can not run in old machine. -- Takashi Yano -- 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: Display text file using less in Cygwin terminal or xterm incorrect when lines are longer than window width
On Mon, 2021-08-09 at 15:17 -0400, C Linus Hicks via Cygwin wrote: > On Sat, 2021-08-07 at 13:33 -0600, Brian Inglis wrote: > > Works Just Fine For Me! > > > This is Cygwin 64 on Windows 10 in a VirtualBox VM, cygcheck output attached. > > It has been a while since I updated Cygwin; as long as it serves my purpose, > I generally don't focus > on that; it is just a tool I use. > > Since I did open this thread, of course I need to make sure I am up-to-date. > I have now done that > and I don't see issues with Cygwin terminal and less, although that is not > really where I am > focusing. I mostly use xterm windows just because there are several > characteristics I like about it. > > I am still seeing issues with xterm and less, as I stated in my original post. > Did I post this in the wrong list? I have not gotten a response since my update. -- 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: Just updated cygutils and cygstart no longer works
Hello Jay, Jay Abel via Cygwin wrote: Sorry, more information. I'm running Windows 10, 64-bit, AMD. I've reverted cygutils back to 1.4.16-2 and the problem is resolved. Jay On Fri, Aug 13, 2021 at 10:27 AM Jay Abel wrote: Run cygstart with anything and no window opens. I've tried URLS cygstart http://www.cygwin.com, directories cygstart . and cygstart ./ as well as pdf files cygstart example.pdf. None of these seems to do anything anymore. I have the same setup as you but all seems well here. With 1.4.16-3 installed all four of your testcases work for me. I don't know what to suggest. When you have a chance, what does 'echo $?' say at the prompt after cygstart finishes one of your testcases? 0 means successful, 1 (or something else) means failure. ..mark -- 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: Package Requests: Update: bash-completion, coreutils - New: linux-manpages
At 8/13/2021 at 01:11, Shakespearean monkeys danced on Brian Inglis's keyboard and said: I suggested linux-manpages a while back, as it comes from the same source as posix-manpages, and I install it myself, but did not get voted to package, due to duplication with conflicting priorities and no easy way to resolve under existing paths. Huh... they go to /usr/local by default (easily changeable with `make prefix=...`), which is pretty bare to begin with and with the fact that they don't package hardly anything in man1, the conflict potential goes down even further. Ah well, I guess I just keep making it manually from a cloned repo. I could probably look at bash-completion if I can get around to bash, as I would worry about dependencies, fixes, and tweaks. There are big challenges in bash and coreutils being years out of date as parts of those need customized for Cygwin, and the customization patches are likely to have issues, or even need redesign, if there have been major changes. bash-completion is a separate/disconnected project (now located at https://github.com/scop/bash-completion), it doesn't align its releases with bash itself. bash-completion 2.7-2.10 require bash 4.1+, 2.11 bumped that to 4.2. Since we're at 4.4, I don't think that's a showstopper (BICBW). And thanks again for the findutils update. 4.7 gave us comma-delimited -type/-xtype specs, so a "( -type p -o -type s )" (shown non-quoted for sanity's sake) becomes "-type p,s". :thumbsup: -- 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: Duplicates in /proc/partitions
> So the second listing shows sdb twice. Also E: does not seem to exist Hi David, I've seen double too, but was told that there's something off with my Windows (7, Home), which I hardly believe is true... but anyways, can you do the cat command from an elevated prompt, by any chance? On my box, I saw that it prints everything correctly then. Just trying to see it I'm not actually "seeing double" :-) Thanks, Anton Lavrentiev Contractor NIH/NLM/NCBI -- 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
CI Build Job Shows Pending but Github Actions Scallywag shows Success Completed
CI build job 3160 gzip shown as still Pending https://cygwin.com/cgi-bin2/jobs.cgi?id=3160 but Github Actions Scallywag #146 job status shows Success and each arch shows as Completed https://github.com/cygwin/scallywag/actions/runs/1125132438 -- 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 binary units and prefixes, physical quantities in SI.]
Re: Just updated cygutils and cygstart no longer works
Sorry, more information. I'm running Windows 10, 64-bit, AMD. I've reverted cygutils back to 1.4.16-2 and the problem is resolved. Jay On Fri, Aug 13, 2021 at 10:27 AM Jay Abel wrote: > Run cygstart with anything and no window opens. I've tried URLS cygstart > http://www.cygwin.com, directories cygstart . and cygstart ./ as well as > pdf files cygstart example.pdf. > > None of these seems to do anything anymore. > -- 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
Just updated cygutils and cygstart no longer works
Run cygstart with anything and no window opens. I've tried URLS cygstart http://www.cygwin.com, directories cygstart . and cygstart ./ as well as pdf files cygstart example.pdf. None of these seems to do anything anymore. -- 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: virtualenv 20.2.2-1 dependencies: filelock and distlib
Hi,
Am Di., 10. Aug. 2021 um 11:30 Uhr schrieb Russell VT :
>
> Well, it's been a hot minute since I've used virtualenv, by itself... but,
> generally you're going to want to use "mkvirtualenv" and related tools to
> create and then access your Python libraries (often under the projects 'venv'
> directory).Your mileage may vary, trying to invoke it directly from the
> command line with a module argument.
'mkvirtualenv' is part of the 'virtualenvwrapper' package.
https://virtualenvwrapper.readthedocs.io/en/latest/ says
"virtualenvwrapper is a set of extensions to Ian Bicking’s virtualenv
tool."
> Myself, I tend to like to distance my Python environments from the Operating
> System version(s)... and I use pyenv with pyenv-virtualenv, and then provided
> I have a decent compiler environment, you can install Python from
> distribution (though, full disclosure and in all fairness, I've had a few
> issues with non-standard directory locations for things like ffi/cffi (IIRC),
> when compiling newer Python versions (though I've not checked, recently).
'pyenv-virtualenv' (https://github.com/pyenv/pyenv-virtualenv) says
"pyenv-virtualenv is a pyenv plugin that provides features to manage
virtualenvs and conda environments for Python on UNIX-like systems.",
so it looks like if 'pyenv-virtualenv' is *another wrapper more* for
'virtualenv'.
I appreciate this two approaches to making 'virtualenv' more easily
accessible; I did not know about these before. However, my issue
reported on 9 August 2021 about the basic 'virtualenv' package
('python38-virtualenv' and related in the Cygwin package database)
would not be remedied by using 'virtualenenvwrapper' or
'pyenv-virtualenv'; even more, these pieces of software would suffer
from the same regressions as my direct use of 'virtualenv'.
Notice that as far as I know running '$ python -m virtualenv <>'
should be, in effect, identical to running '$ virtualenv <...>' with
the same arguments. The former is useful when, as in my case, the
'virtualenv' script is not as easily accessible as the Python
interpreter 'python'.
I am proposing to just include the dependency of the 'virtualenv'
Cygwin package resp. packages on the Cygwin packages for 'filelock'
and 'distlib'. I believe this issue hasn't been reported yet because
the Cygwin packages for 'filelock' and 'distlib' easily can be pulled
in by other pieces of software.
So far,
Friedrich
--
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: AF_UNIX/SOCK_DGRAM is dropping messages
On 8/12/2021 8:56 AM, sten.kristian.ivars...@gmail.com wrote: [snip] I'm going to follow up on cygwin-developers. Great, I'll read about it there Does anyone know anything about the progress of this issue ? I'm afraid there has not been any progress. We weren't able to find a solution using the existing AF_UNIX implementation. The proposed implementation based on Windows named pipes (topic/af_unix branch) stalled because of an issue you reported, which I referred to as a performance problem. But it's a pretty severe performance problem. An alternative proposed by Mark Geisert based on Posix message queues (topic/af_unix_mq branch) also has issues, which may or may not be surmountable. Sorry I don't have better news. 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
Duplicates in /proc/partitions
Before, during and after plugging in a n USB stick: $ cat /proc/partitions major minor #blocks name win-mounts 8 0 1000204632 sda 8 1102400 sda1 8 2 16384 sda2 8 3 999571820 sda3 C:\ 8 4510976 sda4 $ cat /proc/partitions major minor #blocks name win-mounts 8 0 1000204632 sda 8 1102400 sda1 8 2 16384 sda2 8 3 999571820 sda3 C:\ 8 4510976 sda4 816 62522712 sdb 817 4096000 sdb1 D:\ 818 58424664 sdb2 816 62522712 sdb 817 4096000 sdb1 D:\ 818 58424664 sdb2 E:\ $ cat /proc/partitions major minor #blocks name win-mounts 8 0 1000204632 sda 8 1102400 sda1 8 2 16384 sda2 8 3 999571820 sda3 C:\ 8 4510976 sda4 816 62522712 sdb 817 4096000 sdb1 D:\ 818 58424664 sdb2 E:\ So the second listing shows sdb twice. Also E: does not seem to exist (see below). After that I run: $ cygcheck -s -v -r > cygcheck.out cygcheck: dump_sysinfo: GetVolumeInformation() for drive E: failed: 1005 In attached cygcheck.out i swapped out company name and abbreviation with . Windows sees no E: drive: DISKPART> list volume Volume ### Ltr LabelFs TypeSize Status Info -- --- --- - -- --- - Volume 0 CNTFS Partition953 GB HealthyBoot Volume 1 FAT32 Partition100 MB HealthySystem Volume 2 NTFS Partition499 MB HealthyHidden Volume 3 D FFT2 FATRemovable 4000 MB Healthy (there is no mention of E: in Disk Management GUI either) Regards, David -- 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: [ITP] Qemu
Am 09.08.21 um 22:01 schrieb Jon Turney: On 09/08/2021 09:37, Helge Konetzka wrote: Am 04.08.21 um 15:03 schrieb Jon Turney: On 26/07/2021 21:15, Helge Konetzka wrote: Name: Helge Konetzka BEGIN SSH2 PUBLIC KEY Done. I've added 'qemu-integration' to your authorized uploads. Please see [1] for how to upload packages and push to the packaging git repository. [1] https://cygwin.com/packages.html Thanks, and sorry for the delay in processing this. I've uploaded the packages and pushed the cygport stuff. Is there anybody who wants to have a look before I add the ready-file? Looks good to me. Please go ahead. qemu-integration is available via Cygwin Setup since tuesday. I've manually sent the "cygport announce"-based text to cygwin-annou...@cygwin.com as proposed in https://cygwin.com/packaging-contributors-guide.html on wednesday. I am still waiting for delivery to the list... Is anything wrong with the mail? Is is lost perhaps? Just asking because I've seen a new ANNOUNCEMENT a few minutes ago. BTW: cygport doesn't append the unsubscribe info to the mail text, so I forgot to include it. Regards
[ANNOUNCEMENT] cygutils 1.4.16-3
The following packages have been uploaded to the Cygwin distribution: * cygutils-1.4.16-3 * cygutils-extra-1.4.16-3 * cygutils-x11-1.4.16-3 They have been promoted from test to current. The only change is an updated getclip that handles Unicode text from the clipboard. Thanks for the feedback! ..mark -- 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
cygutils 1.4.16-3
The following packages have been uploaded to the Cygwin distribution: * cygutils-1.4.16-3 * cygutils-extra-1.4.16-3 * cygutils-x11-1.4.16-3 They have been promoted from test to current. The only change is an updated getclip that handles Unicode text from the clipboard. Thanks for the feedback! ..mark
