Re: native symlinks and non-existent targets
On Mon, Apr 29, 2024 at 4:11 PM Csaba Ráduly wrote: > > On 25/04/2024 15:15, Jon Turney via Cygwin wrote: > > On 24/04/2024 23:36, Christopher Layne via Cygwin wrote: > > [...] > >> If it isn't true then this seems trivial to fix. > > > > This assertion is trivially disproven by the lack of a patch attached. :) > > > > > I don't think this is worth a gold star, but a jester's cap is surely > warranted :) I disagree. "This assertion is trivially disproven by the lack of a patch attached." is totally worth a gold star Regards, Lee -- 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: Change for the initial installation of Cygwin to set the default terminal terminal 256 color
On Fri, Apr 12, 2024 at 4:05 AM J M wrote: > > Some examples that I view that can do Cygwin better by default: > > tput colors > 8 > > echo $TERM > xterm I made my mintty changes by point & click experimentation - if you want to make system-wide changes the place to do that is in /etc/minttyrc https://github.com/mintty/mintty/wiki/Tips Configuring mintty For its configuration, it reads configuration files in this order: /etc/minttyrc ... etc. $ grep -i term .minttyrc Term=xterm-256color $ tput colors 256 $ echo $TERM xterm-256color > And if use vim, comparing with one Ubuntu terminal: > > I need to set "set mouse-=a" because the copy paste is difficult. > The colors are very bright. > The cursor does not look good when doing a search and moves over the yellow > background text. > > What settings would I need to make it look like Ubuntu's vim? I'd suggest doing a 'man vim' to find out where all the possible configuration files are & then copy them to your cygwin machine. Regards, Lee > El jue., 11 abr. 2024 14:36, J M escribió: > > > Hi, > > > > You can change in the initial install setup of Cygwin to set the default > > terminal to 256 color as Ubuntu does? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin a bit slow
On Fri, Apr 5, 2024 at 11:18 AM J M wrote: > > Hi, > > I'm seeing that Cygwin is a bit slow, directly and after comparing to > simple ubuntu virtual machines by example. > > Specifically: > > - Copy and paste texts in vim, I see clearly the slow in paste. I don't know about the rest, but paste being slow is an old problem - eg: Subject: speeding up a paste operation To: cygwin@cygwin.com Date:Fri, Aug 24, 2018 at 7:30 PM at least on my machine, there's a clear winner for pasting in an absurdly large amount of text: $ time d2u < /dev/clipboard > hosts-3.txt real0m11.372s user0m3.749s sys 0m6.984s $ time cat /dev/clipboard | tr -d '\r' > hosts-2.txt real0m4.405s user0m0.124s sys 0m3.577s $ time getclip -u > hosts.txt real0m0.734s user 0m0.031s sys 0m0.031s Regards, Lee -- 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: Suggestion: [setup] Add an option to allow user to add "Open Cygwin Terminal Here" to Right-click menu
On Fri, Feb 9, 2024 at 11:21 PM Yang Yu Lin via Cygwin wrote: > > It would be convenient for users to open specific folder in terminal by just > right-click it, like Git Bash and Windows Terminal. search for the 'chere' package in setup I use this .reg file: C:\Installed>cat cygwinHere.reg Windows Registry Editor Version 5.00 ; add a Windows Explorer right-click option for folders to ; Open Bash Shell Here [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\bashShell] @="Open Bash Shell Here" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\bashShell\command] @="C:\\Windows\\system32\\cmd.exe /c \"pushd %L && set CHERE_INVOKING=1 && c:\\cygwin\\bin\\bash.exe --login -i\"" ; @="C:\Windows\system32\cmd.exe /c \"pushd %L && set CHERE_INVOKING=1 && c:\cygwin\bin\mintty.exe - \"" ; which has the annoying flash of the DOS cmd window opening & closing before the mintty window opens C:\Installed> > Note: I hope this change would work on Windows 11 right-click menu. (Because > I don't like "Show more options" or Shift + Right-click) I'm still on Windows 10; I have no idea what does/doesn't work on Windows 11 Regards, Lee -- 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: vim: errors launching "/usr/bin/vi
On Wed, Dec 20, 2023 at 2:45 PM gs-cygwin wrote: > > On Wed, Dec 20, 2023 at 02:23:49PM -0500, Lee via Cygwin wrote: > > If anyone has access to a redhat linux system, do they 'alias vi=vim' > > or put vi under /etc/alternatives? > > FYI: neither. Wow! I would have never guessed 'wrapper script' Thank you! Lee > > $ cat /etc/fedora-release > Fedora release 39 (Thirty Nine) > > $ cat /usr/bin/vi > #!/usr/bin/sh > > # run vim if: > # - 'vi' command is used and 'vim' binary is available > # - 'vim' command is used > # NOTE: Set up a local alias if you want vim -> vi functionality. We will not > # do it globally, because it messes up with available startup options (see > # ':help starting', 'vi' is not capable of '-d'). The introducing an > environment > # variable, which an user must set to get the feature, will do the same trick > # as setting an alias (needs user input, does not work with sudo), so it is > left > # on user whether he decides to use an alias: > # > # alias vim=vi > # > # in bashrc file. > > if test -f /usr/bin/vim > then > exec /usr/bin/vim "$@" > fi > > # run vi otherwise > exec /usr/libexec/vi "$@" -- 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: vim: errors launching "/usr/bin/vi
On Wed, Dec 20, 2023 at 2:44 PM Brian Inglis wrote: > > On 2023-12-20 12:30, matthew patton via Cygwin wrote: > >> I'd say vi/vim needs to be put under /etc/alternatives > > > No, because that's system-wide. > > Vi vs Vim is a personal choice. Also alternatives is for supporting multiple > > versions. Say v8.02 versus v9.1 of 'vim' on a system, one being in /usr/bin > > and the other in /usr/local/bin just as an example. And the sysadmin > > choosing > > (for whatever good reason) to preference the v9 software over the v8. > > Most of us run Cygwin on a device called a /Personal Computer/ that allows us > to > make our own choices about OS, desktop UI, services, and configuration. ;^> > > How many of you run shared server or administered Cygwin desktop setups? I have a normal user login with no privs and an administer login for doing things like installing programs or updating the system. I love Nancy Reagans' "Just Say No" to UAC prompts when I'm logged in as a normal user :) I suspect my wife has forgotten her password on this machine. Lee -- 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: vim: errors launching "/usr/bin/vi
On Wed, Dec 20, 2023 at 2:30 PM matthew patton wrote: > > > I'd say vi/vim needs to be put under /etc/alternatives > > No, because that's system-wide. Which is what I want. > Vi vs Vim is a personal choice. Which I've made :) Anyone that doesn't like that decision can make their own work-around, but me with my normal and admin logins wants 'vi' to always behave the same way. I kinda doubt my wife would notice.. except maybe if syntax hilighting/coloring broke > Also alternatives is for supporting multiple versions. Say v8.02 versus v9.1 > of 'vim' on a system, one being in /usr/bin and the other in /usr/local/bin > just as an example. And the sysadmin choosing (for whatever good reason) to > preference the v9 software over the v8. man alternatives NAME alternatives - maintain symbolic links determining default commands It allows picking among multiple versions but it also allows picking between different programs. Regards, Lee > > -- > 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: vim: errors launching "/usr/bin/vi
On Wed, Dec 20, 2023 at 2:24 PM Ken Brown via Cygwin wrote: > > On 12/20/2023 1:34 PM, Lee via Cygwin wrote: > > On Wed, Dec 20, 2023 at 9:01 AM marco atzeri wrote: > >> > >> On Wed, Dec 20, 2023 at 6:04 AM Marco Atzeri wrote: > >>> > >>> On 20/12/2023 03:47, Beau James via Cygwin wrote: > >>>> This problem appeared with my most recent Cygwin update that included an > >>>> update to "vim". > >>> > >>> vi is usually an alias to vim > >>> > >>> $ alias | grep vi > >>> > >>>alias vi='vim' > >>> > >>> so you are in reality calling vim > >>> > >>> $ which vim > >>> /usr/bin/vim > >>> > >>> > >>> I am investigating the /usr/bin/vi issue > >>> > >> > >> -2 version should have solved the issue > > > > I don't get any error or warning messages now but 'vi' still doesn't > > always get me the same thing: > > > > $ vi --version | head -5 > > VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:57:02) > > Included patches: 1-2155 > > Modified by > > Compiled by > > Huge version without GUI. Features included (+) or not (-): > > > > $ /bin/sh > > > > $ vi --version | head -5 > > VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:53:22) > > Included patches: 1-2155 > > Modified by > > Compiled by > > Tiny version without GUI. Features included (+) or not (-): > > Your second shell is not a login shell. Could that be the problem? You need to define "problem" first :) I want "vi" to always call "vim" .. hrmm.. unless I've explicitly done something to explicitly over-ride that. So anytime I type in 'vi' and don't get the VIM Huge version without GUI I'd say that's a problem. I've got "export EDITOR=vi" in my .bash_profile, so anytime $EDITOR is called I want the huge version of vim. If that doesn't happen I'd say that is a problem. If I'm in a bash sheel & do /bin/sh I expect typing in 'vi' will get me the same results as when I was in bash Same deal with dash -- I still want my expected version of vim to run So ... a very long way of saying No, I don't think the second shell not being a login shell is 'the problem.' My experience is that Debian always does the right thing wrt vi/vim. Cygwin does not. It'd be interesting to know if redhat linux uses alternatives or an alias to decide which vi/vim gets called. Regards, Lee -- 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: vim: errors launching "/usr/bin/vi
On Wed, Dec 20, 2023 at 1:57 PM matthew patton wrote: > > > Would you please let me know how to make an /etc/alternatives for vi/vim? > > did you install the alternatives package? I installed cygwin back in 2017; I don't remember what all I've installed but it seems to be there: $ ls -l /usr/sbin/alt* -rwxr-xr-x 1 root None 20499 Apr 4 2013 /usr/sbin/alternatives.exe > I just use aliases (actually I set EDITOR=xxx) after I enumerate the editors > I consider worthy of inclusion and resident. That's my current work-around # set the bash prompt # "$SHLVL" = 1 is true for the 1st shell, and incremented # each time another instance of bash is started. eg # vi /tmp/foo # :sh # and you're in a new shell so SHLVL was incremented # if [ "$SHLVL" = 1 ]; then PS1='\[\e]2;\u@\h \w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' else PS1='\[\e]2;\u@\h \w\a\]\n\u@\h \w\n\$ ' alias vi=vim fi > What DOES need nuking is the forced alias in /etc/profile.d. That's > inexcusable interference in the system. I'd say vi/vim needs to be put under /etc/alternatives If anyone has access to a redhat linux system, do they 'alias vi=vim' or put vi under /etc/alternatives? Debian uses alternatives: $ update-alternatives --query vi Name: vi Link: /usr/bin/vi Slaves: vi.1.gz /usr/share/man/man1/vi.1.gz vi.da.1.gz /usr/share/man/da/man1/vi.1.gz vi.de.1.gz /usr/share/man/de/man1/vi.1.gz vi.fr.1.gz /usr/share/man/fr/man1/vi.1.gz vi.it.1.gz /usr/share/man/it/man1/vi.1.gz vi.ja.1.gz /usr/share/man/ja/man1/vi.1.gz vi.pl.1.gz /usr/share/man/pl/man1/vi.1.gz vi.ru.1.gz /usr/share/man/ru/man1/vi.1.gz Status: auto Best: /usr/bin/vim.basic Value: /usr/bin/vim.basic Alternative: /usr/bin/vim.basic Priority: 30 Slaves: vi.1.gz /usr/share/man/man1/vim.1.gz vi.da.1.gz /usr/share/man/da/man1/vim.1.gz vi.de.1.gz /usr/share/man/de/man1/vim.1.gz vi.fr.1.gz /usr/share/man/fr/man1/vim.1.gz vi.it.1.gz /usr/share/man/it/man1/vim.1.gz vi.ja.1.gz /usr/share/man/ja/man1/vim.1.gz vi.pl.1.gz /usr/share/man/pl/man1/vim.1.gz vi.ru.1.gz /usr/share/man/ru/man1/vim.1.gz $ update-alternatives --query vim Name: vim Link: /usr/bin/vim Status: auto Best: /usr/bin/vim.basic Value: /usr/bin/vim.basic Alternative: /usr/bin/vim.basic Priority: 30 Regards, Lee -- 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: vim: errors launching "/usr/bin/vi
On Wed, Dec 20, 2023 at 9:01 AM marco atzeri wrote: > > On Wed, Dec 20, 2023 at 6:04 AM Marco Atzeri wrote: > > > > On 20/12/2023 03:47, Beau James via Cygwin wrote: > > > This problem appeared with my most recent Cygwin update that included an > > > update to "vim". > > > > vi is usually an alias to vim > > > > $ alias | grep vi > > > > alias vi='vim' > > > > so you are in reality calling vim > > > > $ which vim > > /usr/bin/vim > > > > > > I am investigating the /usr/bin/vi issue > > > > -2 version should have solved the issue I don't get any error or warning messages now but 'vi' still doesn't always get me the same thing: $ vi --version | head -5 VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:57:02) Included patches: 1-2155 Modified by Compiled by Huge version without GUI. Features included (+) or not (-): $ /bin/sh $ vi --version | head -5 VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Dec 20 2023 06:53:22) Included patches: 1-2155 Modified by Compiled by Tiny version without GUI. Features included (+) or not (-): Would you please let me know how to make an /etc/alternatives for vi/vim? I want 'vi' to always invoke 'vim' and everything I tried with alternatives failed :( Thanks Lee -- 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: /usr/bin/vi: errors parsing .vim files from vim-common package
tl,dr: Did vi/vim change from /etc/alternatives to an alias?
$ ls -l $(which vi) $(which vim)
-rwxr-xr-x 1 root Administrators 1507859 Dec 12 09:07 /usr/bin/vi.exe
-rwxr-xr-x 1 root Administrators 3565587 Dec 12 09:07 /usr/bin/vim.exe
$ alias vi
alias vi='vim'
On Sat, Dec 16, 2023 at 3:11 PM John Hein wrote:
>
> I just updated vim packages (including vim-minimal and vim-common) to
> 9.0.2155-1
I've got the same version installed
$ grep '^vi' cygcheck-srv_2023-12-17.txt
vim 9.0.2155-1OK
vim-common 9.0.2155-1OK
vim-minimal 9.0.2155-1OK
> Now when I run 'vi', I get this:
>
> Error detected while processing /usr/share/vim/vim90/filetype.vim:
> line 11:
<.. snip ..>
> and so on.
I can duplicate the problem by
cd /tmp
touch f1 f2
vi f1
:sh
vi f2
... and I get the same thing:
Error detected while processing /usr/share/vim/vim90/filetype.vim:
line 11:
E319: Sorry, the command is not available in this version: let
did_load_filetypes = 1
line 14:
... etc.
Tracking down bash startup processing is not my thing, so I could be wrong but
/etc/profile has this bit:
for file in /etc/profile.d/*.$1; do
[ -e "${file}" ] && . "${file}"
done
and /etc/profile.d/vim.sh has this bit:
if [ -n "$BASH_VERSION" -o -n "$KSH_VERSION" -o -n "$ZSH_VERSION" ]; then
# for bash and zsh, only if no alias is already set
alias vi >/dev/null 2>&1 || alias vi=vim
fi
So I end up with
$ alias | grep ' vi'
alias vi='vim'
and vi works in the shell but gives all those errors in a sub shell - eg
vi /tmp/f1
no error messages
bash
vi /tmp/f1
lots of error messages
Regards,
Lee
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.9 - how to install ssh-keygen
On Tue, Nov 21, 2023 at 2:07 PM Hans-Bernhard Bröker wrote: > > I can't see a command like > > cygcheck -p ssh-keygen > > as noticeably more cumbersome than comparable commands of other > distributions But you _can_ see/realize the implications of that command :) I did a 'man cygcheck' before posting my reply, but somehow didn't notice -p, --package-query search for REGEXP in the entire cygwin.com package repository (requires internet connectivity) which, in hindsight, seems really obvious but somehow I did miss it so thanks for pointing it out! Regards, Lee > > Lee via Cygwin schrieb am Mo., 20. Nov. 2023, 23:42: > > > On Mon, Nov 20, 2023 at 11:54 AM Matthias wrote: > > > > > > Dear all, > > > > > > I've installed cygwin 3.4.9-1 in my virtualbox running on Windows 10. > > > After installing defaults plus openssh 9.5p 1-1, I open the > > Cygwin64-Terminal as Administrator and > > > run ssh-host-config. > > > * Answered "yes" to create the /etc/ssh_config and /etc/sshd_config > > > * Answered "no" to use StrictMode > > > * and "yes" to install sshd as a service > > > * I just press for the question for "Value of CYGWIN for the > > daemon". > > > cygrunsrv -S cygsshd will not start the sshd. The logfile say "no > > hostkeys available". > > > > > > Unfortunately I can't find ssh-keygen in the installable packages. > > > Howto install ssh-keygen or how to create hostkeys? > > > > The easy way to see if it's already installed > > $ which ssh-keygen > > /usr/bin/ssh-keygen > > > > If no, Cygwin is a bit of a pain when looking for a program that's > > included in another package. > > > > There's probably a better way, but I use the cygwin package search - eg: > > https://cygwin.com/cgi-bin2/package-grep.cgi?grep=ssh-keygen > > and then take a guess as the most likely candidate in the results list > > and click on that link to see if it's included in that package - eg > > > > https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fopenssh%2Fopenssh-9.5p1-1=ssh-keygen > > > > > > Regards > > Lee -- 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: Please support download setup-x86_64.exe on IPv6-only network
On Tue, Nov 21, 2023 at 12:35 AM Brian Inglis wrote: > > On 2023-11-20 17:45, Lee via Cygwin wrote: > > On Mon, Nov 20, 2023 at 7:13 PM Backwoods BC via Cygwin wrote: > >> > >> On Thu, Nov 16, 2023 at 12:41 PM Brian Inglis via Cygwin wrote: > >>> The whole IP v4 internet is available as a compatibility subnet > >>> :::0:a.b.c.d > >>> on IP v6, so there is no excuse for not supporting interconnection, as it > >>> will > >>> be required until the last backbone routers drop IP v4 support. > >> > >> Just a small correction for the mail archives as this appears solved. > >> The correct IPV6 address for the IPV4 address range is > >> :::a.b.c.d (no '0') > > > > If you're going for correcting the record, let's make it correct. > > :::a.b.c.d is not a solution for IPv6 => IPv4 interconnection over > > the Internet. > > > > from: https://www.rfc-editor.org/rfc/rfc5156 > > > > 2.2. IPv4-Mapped Addresses > > > > :::0:0/96 are the IPv4-mapped addresses [RFC4291]. Addresses > > within this block should not appear on the public Internet. > > These internal addresses are used by dual stack hosts to allow clients or > servers to handle connections to IPv4 hosts the same as IPv6 hosts. I think that at best you're terribly confused, but let's play this out. > Whereas :::0:0:0/96 == :::0:a.b.c.d allows IPv6 only hosts without > assigned IPv4 addresses to connect to IPv4 only hosts via SIIT see: > > https://www.rfc-editor.org/rfc/rfc7915 Stateless IP/ICMP Translation. I did see RFC 7915. I searched for '' and there were no matches. You need something else to back up your claim that :::0:0:0/96 == :::0:a.b.c.d allows IPv6 only hosts without assigned IPv4 addresses to connect to IPv4 only hosts. And please explain how an ipv6 host is going to get a packet with a 0::/8 address delivered across the internet. see: https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml An ipv6 prefix of 2000::/3 is defined as Global Unicast. In other words, an ipv6 unicast address MUST start off with 2000::/3 to be routed across the Internet. And look at footnotes 3 and 4 :::0:0/96 reserved for IPv4-mapped Address [RFC4291]. 0::/96 deprecated by [RFC4291]. Formerly defined as the "IPv4-compatible IPv6 address" prefix. Nothing about :::0:0:0/96 Regards, Lee -- 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: Please support download setup-x86_64.exe on IPv6-only network
On Mon, Nov 20, 2023 at 7:13 PM Backwoods BC via Cygwin wrote: > > On Thu, Nov 16, 2023 at 12:41 PM Brian Inglis via Cygwin wrote: > > The whole IP v4 internet is available as a compatibility subnet > > :::0:a.b.c.d > > on IP v6, so there is no excuse for not supporting interconnection, as it > > will > > be required until the last backbone routers drop IP v4 support. > > Just a small correction for the mail archives as this appears solved. > The correct IPV6 address for the IPV4 address range is > :::a.b.c.d (no '0') If you're going for correcting the record, let's make it correct. :::a.b.c.d is not a solution for IPv6 => IPv4 interconnection over the Internet. from: https://www.rfc-editor.org/rfc/rfc5156 2.2. IPv4-Mapped Addresses :::0:0/96 are the IPv4-mapped addresses [RFC4291]. Addresses within this block should not appear on the public Internet. Regards, Lee -- 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: Please support download setup-x86_64.exe on IPv6-only network
On Mon, Nov 20, 2023 at 8:55 AM Jon Turney wrote: > > On 16/11/2023 01:40, Bin W via Cygwin wrote: > > https://www.cygwin.com/setup-x86_64.exe > > IPv6-only network can't download the installer. > > I've spoken to the people who speak to the people who actually > administer the DNS for us, and an IPv6 DNS record has been added for > cygwin.com. Thank you!! As admin: ipconfig /release so the only IPv4 address I've got is a 169.254.x.x address and I can - open https://cygwin.com/ - download and run https://cygwin.com/setup-x86_64.exe - get the current package info and update an already installed package Regards, Lee -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.9 - how to install ssh-keygen
On Mon, Nov 20, 2023 at 11:54 AM Matthias wrote: > > Dear all, > > I've installed cygwin 3.4.9-1 in my virtualbox running on Windows 10. > After installing defaults plus openssh 9.5p 1-1, I open the Cygwin64-Terminal > as Administrator and > run ssh-host-config. > * Answered "yes" to create the /etc/ssh_config and /etc/sshd_config > * Answered "no" to use StrictMode > * and "yes" to install sshd as a service > * I just press for the question for "Value of CYGWIN for the daemon". > cygrunsrv -S cygsshd will not start the sshd. The logfile say "no hostkeys > available". > > Unfortunately I can't find ssh-keygen in the installable packages. > Howto install ssh-keygen or how to create hostkeys? The easy way to see if it's already installed $ which ssh-keygen /usr/bin/ssh-keygen If no, Cygwin is a bit of a pain when looking for a program that's included in another package. There's probably a better way, but I use the cygwin package search - eg: https://cygwin.com/cgi-bin2/package-grep.cgi?grep=ssh-keygen and then take a guess as the most likely candidate in the results list and click on that link to see if it's included in that package - eg https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fopenssh%2Fopenssh-9.5p1-1=ssh-keygen Regards Lee -- 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: Difference between cygwin versions
On 8/28/23, Cary Lewis via Cygwin wrote: > On one machine I have cygwin version 3.1.7(0.340/5/3), I can copy cygwin > binaries and the corresponding dlls to a folder and then run the cygwin > programs without any problems. > > But on another machine I have a newer cygwin, 3.4.7-1.x86_64, and when I > do the same thing, the programs do not work: > > e.g. > > mkdir /tmp/test > cd /tmp/test > $ ls -1 > bash.exe > chroot.exe > cygiconv-2.dll > cygintl-8.dll > cygncursesw-10.dll > cygreadline7.dll > cygwin1.dll > > I copied all of bash's required dlls to /tmp/test > > When I do a ./bash, it exits immediately on 3.4.7, but on 3.1.7 it works > correctly. *forward slash* ?? That doesn't work for me, but .\bash does $ uname -a CYGWIN_NT-10.0-19044 i3668 3.4.7-1.x86_64 2023-06-16 14:04 UTC x86_64 Cygwin works for me: C:\Temp\test>dir Directory of C:\Temp\test 08/28/2023 10:04 AM . 08/28/2023 10:04 AM .. 08/28/2023 09:59 AM 854,035 bash.exe 08/28/2023 10:04 AM43,539 chroot.exe 08/28/2023 10:00 AM 1,088,019 cygiconv-2.dll 08/28/2023 10:00 AM 108,563 cygintl-8.dll 08/28/2023 10:01 AM 334,867 cygncursesw-10.dll 08/28/2023 10:00 AM 262,675 cygreadline7.dll 08/28/2023 09:59 AM 2,952,245 cygwin1.dll C:\Temp\test>.\bash.exe bash.exe: warning: could not find /tmp, please create! bash-5.2$ uname windows32 bash-5.2$ exit exit Regards, Lee -- 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: Entering Cygwin command line (bash login) from Windows cmd.exe ?
On 8/7/23, Roland Mainz via Cygwin wrote: > On Sat, Jul 29, 2023 at 6:18 AM Roland Mainz wrote: >> Is there an official way to enter the Cygwin command line (e.g. bash >> login) from Windows cmd.exe, e.g. if someone ssh's into a Windows >> machine he/she ends/up in a cmd.exe and not bash... > > ping! Years ago this was the default way to start cygwin (I don't think I've changed it, but who knows??) C:\cygwin>type Cygwin.bat @echo off C: chdir C:\cygwin\bin bash --login -i There's a Cygwin.bat in /etc/defaults that needs to be copied to the cygwin root directory: C:\cygwin>type etc\defaults\Cygwin.bat @echo off setlocal enableextensions set TERM= cd /d "%~dp0bin" && .\bash --login -i C:\cygwin> "cd /d" - Use the /D switch to change current drive in addition to changing current directory for a drive. "%~dp0" gives the path of the script, so if the .bat file is in C:\cygwin then "%~dp0bin" expands to C:\cygwin\bin Regards Lee -- 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: [EXTERNAL] dig and host don't work in IPv6
On 7/29/23, Andrew Schulman via Cygwin wrote: >> Sorry... Did you try using the -d option to see what DNS servers these >> commands try to actually connect to (and time out, eventually). > > No help unfortunately. > > $ host -d6 cygwin.com > Trying "cygwin.com" > ;; connection timed out; no servers could be reached Have you tried the windows version of bind from isc.org? I don't remember when ISC dropped (will drop?) support for windows, but I've been using dig from the bind9.16.41 package for a while. Not that I use it all that much, but it works for me.. or at least dig does. named on windows has something funky going on that I never figured out, so I'm running named on Debian. Get it here https://ftp.isc.org/isc/bind9/9.16.41/BIND9.16.41.x64.zip unzip and put that directory in your path $ which dig /cygdrive/c/Temp/BIND/dig and have fun! $ dig @2600:x:x:x::x:x www.google.com +short 2607:f8b0:4004:c09::67 2607:f8b0:4004:c09::69 2607:f8b0:4004:c09::93 2607:f8b0:4004:c09::63 Lee@i3668 ~ $ dig @2600:x:x:x::x:x www.google.com a +short 172.253.122.147 172.253.122.103 172.253.122.99 172.253.122.104 172.253.122.105 172.253.122.106 ipv6 address hidden to protect the guilty :) ... hrmmm ... I just tried your "host -d6 cygwin.com" and got $ host -d6 cygwin.com Trying "cygwin.com" ;; connection timed out; no servers could be reached Do you have a firewall blocking outbound udp/tcp to port 53? I do, which is most probably why I get the timeout. But this works: $ host cygwin.com 2600:x:x:x::x:x Using domain server: Name: 2600:x:x:202::x:x Address: 2600:x:x:202::x:x#53 Aliases: cygwin.com has address 8.43.85.97 cygwin.com mail is handled by 10 sourceware.org. Maybe try using whatever dig you already have installed and do ipconfig /all | grep "DNS Server" and then dig @ cygwin.com Regards, Lee > >> (strace can help as well, I think.) > > Posted at https://pastebin.com/XWwxJ41b. I'm not able to make much sense of > it, > except that on line 1339, I waited almost 5 seconds for sendmsg: > > 4964291 6958349 [isc-worker] host 20999 cygwin_sendmsg: 28 = > sendmsg(20, > 0x7FFDFC830, 0x0) > > Thanks for taking a look. I'm looking at other options in resolv.conf, but > haven't found anything useful. > > I can't find any documention of the osquery option. This answer[1] says > "res_init() uses the Windows resolver if either /etc/resolv.conf does not > exist, > or /etc/resolv.conf contains options osquery." Doesn't help in this case > though. > > Andrew > > [1] > https://stackoverflow.com/questions/10523828/how-does-gcc-cygwin-get-the-dns-server > > > -- > 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
cygcheck: Missing file:
I just noticed this Missing file: /etc/preremove/openssl.sh from package libssl1.1 Missing file: /etc/preremove/openssl.sh from package libssl3 in the output of 'cygcheck -srv'? Is there something I should do about it? TIA, Lee -- 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
OpenSSL: FATAL
I've been getting random OpenSSL: FATAL OPENSSL_Uplink(008A7C34,08): no OPENSSL_Applink crashes in an app built using ./configure --host=i686-w64-mingw32 https://www.openssl.org/docs/faq.html has this bit under I’ve compiled a program under Windows and it crashes: why? As per 0.9.8 the above limitation is eliminated for .DLLs. OpenSSL .DLLs compiled with some specific run-time option [we insist on the default /MD] can be deployed with application compiled with different option or even different compiler. But there is a catch! Instead of re-compiling OpenSSL toolkit, as you would have to with prior versions, you have to compile small C snippet with compiler and/or options of your choice. The snippet gets installed as /include/openssl/applink.c and should be either added to your application project or simply #include-d in one [and only one] of your application source files. Failure to link this shim module into your application manifests itself as fatal “no OPENSSL_Applink” run-time error. I'm statically linking the app, so it isn't pulling in any mingw openssl DLLs, but adding a #include to one of the source files in the app does seem to fix the crashing. So here's my questions: 1. Is including really the fix for the no OPENSSL_Applink crashes or am I just (un?)lucky that the app hasn't crashed again in my very limited testing? 2. I have mingw64-i686-openssl 3.0.9-0.1 installed. Assuming I do need the new include now, is this going to be a permanent requirement or might a later mingw64-i686-openssl fix ??something?? and I won't need that include? TIA Lee -- 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: Noticeable delay in copy paste
On 7/4/23, ravi r via Cygwin wrote: > After two years of using an older version of cygwin, a week ago, I >CYGWIN_NT-10.0-19045 version 3.4.7-1.x86_64 > (runneradmin@fv-az416-306) (gcc version 11.4.0 (GCC) ) 2023-06-16 > 14:04 UTC > upgraded cygwin to the latest version. > > Ever since the upgrade, I see noticeable delay in copy pasting text > from Chrome browser to 'vim' editor session > running inside a xterm under fvwm. > > Need assistance on additional commands that I could run to find the > cause of this issue. Maybe this will help https://cygwin.com/pipermail/cygwin/2018-August/238351.html Regards, Lee -- 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] openh264 (2.3.1)
On 2/6/23, Yaakov Selkowitz via Cygwin-apps wrote: > On Sun, 2023-02-05 at 22:11 -0700, Brian Inglis wrote: >> On 2023-02-05 19:44, Yaakov Selkowitz via Cygwin-apps wrote: >> > On Sun, 2023-02-05 at 17:37 +0900, Takashi Yano via Cygwin-apps wrote: >> > > I would like to propose new package openh264, which is >> > > a H264 video codec library. This is needed by ffmpeg >> > > package I had proposed, and also provided for ffmpeg-free >> > > package in fedora. >> > > >> > > I already prepared the package at the following location. >> > > >> > > https://tyan0.yr32.net/cygwin/x86_64/release/openh264/ >> >> > Unfortunately, this cannot be included in the Cygwin distribution. >> > Cisco's >> > patent license only covers binaries they distribute. Fedora has a >> > special >> > arrangement with Cisco where they build their RPMs on Fedora >> > infrastructure, >> > but the packages are hosted by Cisco in a separate repository. >> >> http://www.openh264.org/ >> "Cisco has taken their H.264 implementation, and open sourced it under BSD >> >> license terms. Development and maintenance will be overseen by a board >> from >> industry and the open source community. Furthermore, we have provided a >> binary >> form suitable for inclusion in applications across a number of different >> operating systems, and make this binary module available for download >> from >> the >> Internet. We will not pass on our MPEG-LA licensing costs for this >> module, >> and >> based on the current licensing environment, this will effectively make >> H.264 >> free for use on supported platforms." > > This is exactly the point. Cisco paid for a license, but that license is > limited to binaries they distribute. IANAL but it sure looks like redistribution is allowed: cisco/openh264 is licensed under the BSD 2-Clause "Simplified" License https://github.com/cisco/openh264/blob/master/LICENSE <.. snip ..> Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Lee
gcc -mno-cygwin
The "-mno-cygwin" gcc option went away years ago. Correct? It still shows up in the output of 'man gcc': $ man gcc | grep mno-cygwin x86 Windows Options -mconsole -mcygwin -mno-cygwin -mdll -mnop-fun-dllimport -mthread -municode -mwin32 Is that a cygwin specific or a generic gcc man page oversight? TIA, Lee -- 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: resolv.conf and gnupg2
On 8/9/22, Christian Franke wrote:
> Brian Inglis wrote:
>> I've been running with /etc/resolv.conf for a few years now, generated
>> from the ISP info from ipconfig and lists of public DNS servers and
>> suffixes.
>>
>> The attached postinstall script 0p_l_etc_resolv_conf.dash generates a
>> new resolv.conf and replaces the current if different every update.
>> It is also run at cron startup and that covers system startup.
>>
>> The AWK script collects names and addresses from ipconfig ouput and
>> adds lists of public DNS servers and public suffixes in the proper order.
>>
>> How this works with other ISPs or in other network environments is not
>> anything I ever thought of testing externally.
>> Feel feel to try it and change it if curious or interested.
>
> This is an interesting approach, thanks for sharing.
Yes, interesting script
> Unfortunately the ipconfig output is always localized, so this does only
> work OOTB with English versions of Windows. The ipconfig parsing is also
> broken due to two reasons:
>
> - The current Cygwin versions of awk, grep and sed no longer convert
> CR/LF -> LF on stdin, so '/FooBar$/' patterns never match.
Which is handled by
/\r/ { sub( /\r/, "", $NF) } # trim \r
I get " ca. org. com. net." appended to the search suffix list; that
should be fixed.
Regards,
Lee
--
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: I got a '~' showing up as the Title of my Window
On 7/15/22, Kevin M. Wilson via Cygwin wrote: > > Greetings,Well, I've gone and done something, and I don't know how to > fix it...Please help! > I start a terminal window on my windows machine, ssh'g to my Linux box. At > the top lefthand corner of that window is a tilde, "~bash". The word > disappears, leaving behind the 'tilde'. Plus, on the screen next to the > prompt, a few seconds later...Another'tilde'. So...Suggestions? it's your PS1 setting man bash and search for PROMPTING Regards, Lee -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Perl has slowed in recent months
On 5/22/22, David Christensen wrote: > On 5/21/22 10:55, Hans-Bernhard Bröker wrote: >> Am 18.05.2022 um 03:53 schrieb David Christensen: >> >> > I am working on a Perl module that runs on various Unix-like platforms. >> > When I 'make test' on similar computers: >> > >> > FreeBSD 12.3-RELEASE 28 wallclock secs >> > Debian GNU/Linux 11.3 31 wallclock secs >> > macOS 11.6.2 36 wallclock secs >> > Windows 7 / Cygwin 3.3.5-1509 wallclock secs >> >> Given the complete lack of information about what that Perl module of >> yours might be doing, that's hard to have a meaningful discussion about. > > > Thank you for the response. I was hoping there was a known issue. > Apparently, not. What I consider a well known issue is that process start up time is _very_ slow. If your 'make test' starts lots of processes that could be a problem. Another huge slowdown is Windows Defender. Try turning that off and seeing how long your 'make test' takes then. Regards, Lee > > The above module is proprietary, so I thought I would profile some > similar CPAN modules to generate discussion information: > > 2022-05-22 01:25:39 dpchrist@dht4s3r1 ~ > $ systeminfo | egrep '^OS (Name|Version)' ; uname -a ; cygcheck -c cygwin > OS Name: Microsoft Windows 7 Professional > OS Version:6.1.7601 Service Pack 1 Build 7601 > CYGWIN_NT-6.1-7601 dht4s3r1 3.3.5-341.x86_64 2022-05-13 12:27 UTC x86_64 > Cygwin > Cygwin Package Information > Package VersionStatus > cygwin 3.3.5-1OK > > 2022-05-22 01:26:45 dpchrist@dht4s3r1 ~ > $ cpan install Devel::NYTProf > > t/50-errno.t . 1/8 > # Failed test '$! should not be altered by NYTProf i/o' > # at t/50-errno.t line 58. > # got: '0' > # expected: '3' > # Looks like you failed 1 test of 8. > t/50-errno.t . Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/8 subtests > > Test Summary Report > --- > t/50-errno.t (Wstat: 256 Tests: 8 Failed: 1) >Failed test: 6 >Non-zero exit status: 1 > Files=55, Tests=4736, 570 wallclock secs ( 0.64 usr 1.06 sys + 104.19 > cusr 403.73 csys = 509.62 CPU) > Result: FAIL > Failed 1/55 test programs. 1/4736 subtests failed. > make: *** [Makefile:1284: test_dynamic] Error 255 >JKEENAN/Devel-NYTProf-6.11.tar.gz >/usr/bin/make test -- NOT OK > //hint// to see the cpan-testers results for installing this module, try: >reports JKEENAN/Devel-NYTProf-6.11.tar.gz > > > STFW: > > https://github.com/Perl/perl5/issues/12389 > > > Any suggestions? > > 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
3.3.3: possible DLL breakage with network mounted drives running make
Hey Folks, Trying to track down why our builds started failing after upgrading to cygwin 3.3.3. Narrowed it down to a change in how make (gmake) is invoked with a specified directory to execute in and that directory is a network drive in windows (10, 21H2). simple Makefile attached and below: all: @echo CURDIR=$(CURDIR) my drive is mounted as "M:" in both tests on cygwin 3.3.3 dilkiel@fal-pc-100 /cygdrive/m $ make -C ./ -f Makefile make: Entering directory '//192.168.51.103/views' CURDIR=//192.168.51.103/views make: Leaving directory '//192.168.51.103/views' I used the '-C' option so you could more easily see the problem. on older cygwin (2.11.2) dilkiel@CA632444 /cygdrive/m $ make -C ./ -f Makefile make: Entering directory '/cygdrive/m' CURDIR=/cygdrive/m make: Leaving directory '/cygdrive/m' Problem: The '//192.168.51.103/views' version of a filename isn't going to work for a lot of parts of make that are expecting either a windows 'm:/' or cygwin style '/cygdrive/m' directory path. This directory get used with make targets and that path won't convert to windows format properly with cygpath and is unusable passed to most windows programs. BTW, even cygcheck didn't like being run from this directory. dilkiel@fal-pc-100 /cygdrive/m $ cygcheck -s -v -r > cygcheck.out '\\192.168.51.103\views' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. '\\192.168.51.103\views' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. '\\192.168.51.103\views' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. I couldn't find anything in the last few months of the mailing list so perhaps I have something odd in my enviro? (identical enviro on both machines, BTW, they are clones of each other). NOTE: works correctly on physically mounted drives. Can anyone help? thanks, -lee all: @echo CURDIR=$(CURDIR) Cygwin Configuration Diagnostics Current System Time: Fri Dec 03 19:07:03 2021 Windows 10 Professional Ver 10.0 Build 19044 Path: C:\cygwin64\usr\local\bin C:\cygwin64\bin C:\Program Files (x86)\Common Files\Oracle\Java\javapath C:\Perl64\site\bin C:\Perl64\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\IBM\RationalSDLC\clearcase\RemoteClient\cteapis C:\Program Files\Mitel\AutoSDK\CommonDlls C:\Program Files (x86)\Mitel\AutoSDK\VirtuaFone C:\Program Files (x86)\Mitel\AutoSDK\CommonDlls C:\Program Files\Microsoft SQL Server\110\Tools\Binn C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0 C:\WINDOWS\System32\OpenSSH C:\Go\bin C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR C:\Program Files\Docker\Docker\resources\bin C:\ProgramData\DockerDesktop\version-bin C:\Users\dilkiel\AppData\Local\Programs\Python\Python38-32\Scripts C:\Users\dilkiel\AppData\Local\Programs\Python\Python38-32 C:\Users\dilkiel\AppData\Local\Microsoft\WindowsApps C:\Users\dilkiel\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin C:\Users\dilkiel\AppData\Local\Programs\Microsoft VS Code\bin C:\Users\dilkiel\go\bin Output from C:\cygwin64\bin\id.exe UID: 197609(dilkiel) GID: 197121(None) 197121(None) 197611(docker-users) 559(Performance Log Users) 545(Users) 4(INTERACTIVE) 66049(CONSOLE LOGON) 11(Authenticated Users)15(This Organization) 113(Local account) 4095(CurrentSession) 66048(LOCAL) 262154(NTLM Authentication) 401408(Medium Mandatory Level) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'dilkiel' PWD = '/cygdrive/m' HOME = '/home/dilkiel' USERDOMAIN = 'FAL-PC-100' OS = 'Windows_NT' MACRIUM_1785_PASSWORD = '1' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' PROCESSOR_LEVEL = '6' PSModulePath = ';C:\Users\dilkiel\AppData\Local\Google\Cloud SDK\google-cloud-sdk\platform\PowerShell' CommonProgramW6432 = 'C:\Program Files\Common Files' tug_log_dir = 'b:/tmp' MACRIUM_1784_DIRECTORY = 'd:\MacriumBackupWin10\' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' tug_icpside_bind4 = '10.39.164.100' TZ = 'America/New_York' MACRIUM_1784_METHOD7 = '1' MACRIUM_1784_METHOD6 = '1' MACRIUM_1784_METHOD5 = '2' MACRIUM_1784_METHOD4 = '1' MACRIUM_1784_METHOD3 = '1' MACRIUM_1784_METHOD2 = '1' MACRIUM_1784_METHOD1 = '0' HOSTNAME = 'fal-pc-100' PUBLIC = 'C:\Users\Public' OLDPWD = '/cygdrive/c/build' MACRIUM_1785_CURRENT_INCREMENT = '7' MACRIUM_PREFIX = 'MACRIUM_1785' USERNAME = 'dilkiel' IDIR_TEMPDIR = 'd:\tmp' LOGONSERVER =
Re: Setting up toolchains
On 9/27/21, Anthony Webber wrote:
> Please excuse the naivety of this question, but I've looked elsewhere
> and can't find a good answer. Perhaps a good answer is to install MSYS2
> alongside Cygwin.
that seems to be the usual answer here :(
> Anyway, I am trying to set up my gcc toolchains in Cygwin, by which I
> mean that I'm trying to set up the environment so that the right
> programs are called at the right time by build systems like cmake and
> waf,
cmake supposedly supports cross-compilation. I've never figured out
how to do it :(
> or if I want to build in a more manual fashion. Particularly, I
> want to be able to switch between toolchains easily.
GNU autoconf. Switching between toolchains is as easy as
autoconf
autoheader
./configure --host=i686-w64-mingw32
> I have installed both the x86_64-pc-cygwin-gcc/g++ and
> x86_64-w64-mingw32-gcc/g++ packages using setup-x86_64.exe.
>
> The first thing I notice is that the gcc/g++ programs in /bin are
> identical to x86_64-pc-cygwin-gcc/g++, and that symbolic links aren't
> being used. I presume it's being done this way because this is
> considered the default, native Cygwin toolchain, and that there should
> be be relatively little to do in the way of configuration if I want to
> build Cygwin software.
>
> If I do want to cross-compile using x86_64-w64-mingw32-gcc/g++, then I
> imagine that the very least I should do is set a bunch of environment
> variables like CC and CXX (perhaps by sourcing a shell script), but
> really I'd like some advice here. What do you guys do?
I've never written anything that needed a make file; I just use the
correct compiler. eg
$ tail -3 getenv.c
}
/* i686-w64-mingw32-gcc -o getenv.exe getenv.c
*/
The only time I've had to use environment variables was for building mbedtls:
export WINDOWS_BUILD=1
# build for a Windows platform
export SHARED=1
# want the shared libraries created
export CC=i686-w64-mingw32-gcc
export LD=i686-w64-mingw32-gcc
export CFLAGS="-O2 -fstack-protector-strong -D_FORTIFY_SOURCE=2"
export LDFLAGS="${LDFLAGS} -fstack-protector-strong"
make lib
# build the libraries
PATH="${PWD}/library:/usr/i686-w64-mingw32/sys-root/mingw/bin:${PATH}"
# so the tests are able to find the mbedtls and mingw libraries
make check
# run the test suite
Regards,
Lee
--
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: Incompatible clipboard format between 32bit and 64bit cygwin
On 9/26/21, Thomas Wolff wrote:
>
> Am 26.09.2021 um 20:37 schrieb Thomas Wolff:
>>
>> Am 26.09.2021 um 11:50 schrieb Mark Geisert:
>>> Hi Takashi,
>>>
>>> Takashi Yano via Cygwin wrote:
>>>> I noticed that cygwin clipboard is not compatible
>>>> between 32bit and 64bit cygwin.
>>>>
>>>> If I run 'echo > /dev/clipboard' in 32bit cygwin,
>>>> and run 'cat /dev/clipboard' in 64bit cygwin, this result in
>>>> cat: /dev/clipboard: Bad address
>>>>
>>>> This is because the structure
>>>> typedef struct
>>>> {
>>>>timestruc_t timestamp;
>>>>size_tlen;
>>>>char data[1];
>>>> } cygcb_t;
>>>> defined in fhandler_clipboard.cc has different size.
>>>>
>>>> Is this the known issue?
>>>
>>> I doubt anybody has ever tried what you did.
>> I have and it failed; I just didn't find it important enough to report
>> it here... Thanks for the plan to fix it.
>>
>>> I have been testing getclip and putclip between 32- and 64-bit
>>> environments, but neglected to test Cygwin-internal clipboard format
>>> that prepends cygcb_t to the user-supplied data.
> As we're at it, what's the purpose of a cygwin-internal clipboard format
> at all?
speed?
Maybe I'm not understanding the question, but I put a question to this
list ~3 years ago about right-click/paste into a mintty window being
**really** slow and the answer was to use getclip:
$ time d2u < /dev/clipboard > hosts-3.txt
real0m11.372s
user0m3.749s
sys 0m6.984s
$ time cat /dev/clipboard | tr -d '\r' > hosts-2.txt
real0m4.405s
user0m0.124s
sys 0m3.577s
$ time getclip -u > hosts.txt
real0m0.734s
user0m0.031s
sys 0m0.031s
Lee
--
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: Previously-functional gawk script now failing to execute - PLEASE HELP!!!
On 9/15/21, Bryan VanSchouwen via Cygwin wrote:
> Hello.
>
> I just tried executing an old, previously-functional awk script using a
> version of gawk that I had downloaded last year, and a command of the
> following format (as recommended in a previous communication with the
> Cygwin mailing list):
> gawk -vRS="\r\n" -f data_collect_e_-_FF_4-state.awk
> but this time, the script failed to execute!!
The data file you attached doesn't have "\r\n" line endings:
$ file rpcg_FF_filtrd.txt
rpcg_FF_filtrd.txt: ASCII text
compare with one that does:
$ file test.txt
test.txt: ASCII text, with CRLF line terminators
<.. snip ..>
> What the heck is going on with this software, and is there a way to fix
> it?!
I don't use RS and start my awk scripts off with
sub("\r$", "", $0) # fix any \r\n line endings
so my scripts work with either flavor of line endings.
If you don't want to change your script try changing your input
unix2dos
Regards,
Lee
--
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: github password policy
On 8/16/21, Thomas Wolff wrote: > github have changed their authentication policy not to allow passwords > anymore. > So they are asking maintainers to acquire another kind of password (a > "token"), which I did a while ago. > But they refuse to support users with the transition, there is no > "plug-and-play" howto available, except for those who are willing to > dive into details of authentication stuff and spend a few study hours on > that useless policy change. > As I cannot update mintty anymore right now from the git command line, > is any maintainer here impacted by the same issue and can help out with > some advice how to get rid of this nuisance? ssh keys work - start here: https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh Regards Lee
Fw: Web Designing
Hi Cygwin, Hope this mail finds you good..! My Name is Lizella Lee, I am a professional Web design & Mobile App Developer; I can upgrade, Repair and Redesign your website. Would you be interested in: - We Provides SEO & Web services at a minimum cost, May I send you quote? If interested. Thanks.!!! Business Development Consultant -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin DLL 3.2.0 (W10) Problem with touch (8.26) for old dates < 1970
On 4/14/21, akiki--- via Cygwin wrote: > Hi, > I encountered problems with the use of timestamps in cygwin. > May be it's an old problem, I don't know, using essentially files "recently" > created/modified. > > > I want to say after 1970 No problem, but before ... > > > To day: > touch -m -t 190001011200.00 x gives touch: format de date « 190001011200.00 > » incorrect > touch -m -t 190101011200.00 x gives ok - with ls -l x: > -rw-r--r-- 1 user group 0 1 janv. 1910 x Do you have the 32 bit cygwin installed? x86_64 Cygwin looks OK to me: $ touch -m -t 190001011200.00 x $ ls -l x -rw-rw-rw- 1 Lee None 0 Jan 1 1900 x $ uname -a CYGWIN_NT-10.0 i3668 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin Regards, Lee -- 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
gcc -fsanitize supported?
Is the gcc option "-fsanitize=address" supported in cygwin? If yes, what else do I need to install? $ gcc -fsanitize=address args.c /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lasan collect2: error: ld returned 1 exit status $ i686-w64-mingw32-gcc -fsanitize=address args.c /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld: cannot find -lasan collect2: error: ld returned 1 exit status Thanks Lee -- 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: problem using gcc-core for compile qemu
On 1/8/21, juan carlos rebate rodriguez via Cygwin wrote: > > I think I expressed myself incorrectly or I am not able to be > understood, no matter what package I choose. gcc-core does not compile > using the cygwin dll, the one that compiles for that library is cygwin- > gcc. > now I will try to explain my case better, > 1 when I use the gcc-core package if it is able to detect the whole > set, the only thing that happens is that the script does not recognize > cygwin nt as a valid operating system. > 2 when I use the mingw64-x86_64-gcc package it is not able to compile > without add-ons. > for example when I compile with gcc-core if it is able to detect the > libcaca-devel library, this is the library that qemu asks me for sd- > card support, > However, when I use the package mingw64-x86_64-gcc it is not able to > find it in the system because it is not in its set, If you use the mingw cross compiler you'll also need some cross compiler tools. Take a look at https://cygwin.com/cgi-bin2/package-grep.cgi?grep=libcaca=x86_64 You probably need to install mingw64-x86_64-libcaca-0.99.beta19-1 - mingw64-x86_64-libcaca: Color ASCII art library for Win64 toolchain Regards, Lee -- 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: creating a current mingw64-i686-pcre package
On 12/22/20, gs-cygwin@gluelogic.com wrote:
> On Tue, Dec 22, 2020 at 02:38:19AM +0000, Lee via Cygwin-apps wrote:
>> I'd like to update the orphaned mingw64-i686-pcre package.
>>
>> The download and prep steps work but compile dies & I don't know why:
>>
>> >>> Preparing mingw64-i686-pcre-8.44-1.noarch
>> *** Info: SOURCE 1 signature follows:
>> gpg: Signature made Wed Feb 12 12:36:22 2020 EST
>> gpg:using RSA key 0x9766E084FB0F43D8
>> gpg: Good signature from "Philip Hazel "
>> gpg: aka "Philip Hazel "
>> gpg: aka "Philip Hazel "
>> gpg: WARNING: This key is not certified with a trusted signature!
>> gpg: There is no indication that the signature belongs to the
>> owner.
>> Primary key fingerprint: 45F6 8D54 BBE2 3FB3 039B 46E5 9766 E084 FB0F
>> 43D8
>> >>> Unpacking source pcre-8.44.tar.gz
>> >>> Preparing working source directory
>> >>> Compiling mingw64-i686-pcre-8.44-1.noarch
>> autoreconf-2.69: Entering directory `.'
>> autoreconf-2.69: configure.ac: not using Gettext
>> autoreconf-2.69: running: aclocal --force -I m4
>> autoreconf-2.69: configure.ac: tracing
>> autoreconf-2.69: running: libtoolize --copy --force
>> libtoolize: putting auxiliary files in '.'.
>> libtoolize: error: copying '/usr/share/libtool/build-aux/ltmain.sh'
>> to './' failed
>> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
>> libtoolize: error: copying '/usr/share/aclocal/libtool.m4' to 'm4/'
>> failed
>> libtoolize: error: copying '/usr/share/aclocal/ltoptions.m4' to 'm4/'
>> failed
>> libtoolize: error: copying '/usr/share/aclocal/ltsugar.m4' to 'm4/'
>> failed
>> libtoolize: error: copying '/usr/share/aclocal/ltversion.m4' to 'm4/'
>> failed
>> libtoolize: error: copying '/usr/share/aclocal/lt~obsolete.m4' to 'm4/'
>> failed
>> autoreconf-2.69: libtoolize failed with exit status: 1
>> *** ERROR: autoreconf failed
>>
>>
>> Hopefully I just need to install something else, but what?
>
> These are the usual suspects: autoconf automake libtool m4 pkg-config
> Do you have them installed?
Thanks for making me double-check. I was doing package searches using
the name from the warning message and not finding anything that looked
applicable for Gettext.
The missing package was lower-case-g
mingw64-i686-gettext
Should I be concerned about
CC libpcre16_la-pcre16_compile.lo
/ports/mingw64-i686-pcre/mingw64-i686-pcre-8.44-1.noarch/src/pcre-8.44/pcreposix.c:56:
warning: "PCREPOSIX_EXP_DECL" redefined
56 | # define PCREPOSIX_EXP_DECL extern __declspec(dllexport)
|
In file included from
/ports/mingw64-i686-pcre/mingw64-i686-pcre-8.44-1.noarch/src/pcre-8.44/pcreposix.c:46:
./config.h:254: note: this is the location of the previous definition
254 | #define PCREPOSIX_EXP_DECL extern __attribute__ ((visibility
("default")))
|
/ports/mingw64-i686-pcre/mingw64-i686-pcre-8.44-1.noarch/src/pcre-8.44/pcreposix.c:57:
warning: "PCREPOSIX_EXP_DEFN" redefined
57 | # define PCREPOSIX_EXP_DEFN __declspec(dllexport)
|
In file included from
/ports/mingw64-i686-pcre/mingw64-i686-pcre-8.44-1.noarch/src/pcre-8.44/pcreposix.c:46:
./config.h:257: note: this is the location of the previous definition
257 | #define PCREPOSIX_EXP_DEFN extern __attribute__ ((visibility
("default")))
|
Thanks,
Lee
creating a current mingw64-i686-pcre package
I'd like to update the orphaned mingw64-i686-pcre package. The download and prep steps work but compile dies & I don't know why: >>> Preparing mingw64-i686-pcre-8.44-1.noarch *** Info: SOURCE 1 signature follows: gpg: Signature made Wed Feb 12 12:36:22 2020 EST gpg:using RSA key 0x9766E084FB0F43D8 gpg: Good signature from "Philip Hazel " gpg: aka "Philip Hazel " gpg: aka "Philip Hazel " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 45F6 8D54 BBE2 3FB3 039B 46E5 9766 E084 FB0F 43D8 >>> Unpacking source pcre-8.44.tar.gz >>> Preparing working source directory >>> Compiling mingw64-i686-pcre-8.44-1.noarch autoreconf-2.69: Entering directory `.' autoreconf-2.69: configure.ac: not using Gettext autoreconf-2.69: running: aclocal --force -I m4 autoreconf-2.69: configure.ac: tracing autoreconf-2.69: running: libtoolize --copy --force libtoolize: putting auxiliary files in '.'. libtoolize: error: copying '/usr/share/libtool/build-aux/ltmain.sh' to './' failed libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. libtoolize: error: copying '/usr/share/aclocal/libtool.m4' to 'm4/' failed libtoolize: error: copying '/usr/share/aclocal/ltoptions.m4' to 'm4/' failed libtoolize: error: copying '/usr/share/aclocal/ltsugar.m4' to 'm4/' failed libtoolize: error: copying '/usr/share/aclocal/ltversion.m4' to 'm4/' failed libtoolize: error: copying '/usr/share/aclocal/lt~obsolete.m4' to 'm4/' failed autoreconf-2.69: libtoolize failed with exit status: 1 *** ERROR: autoreconf failed Hopefully I just need to install something else, but what? Thanks, Lee mingw64-i686-pcre.cygport Description: Binary data
Re: why does i686-w64-mingw32-gcc -static fail?
On 12/18/20, Brian Inglis wrote: > On 2020-12-17 20:45, Lee via Cygwin wrote: >> Would someone please explain why adding "-static" makes >> i686-w64-mingw32-gcc fail? >> >> This works (or at least the compiler doesn't complain) >> >> $ i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix >> -lpcre >> >> This does not work >> >> $ i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix >> -lpcre >> /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld: >> cannot find -lpcreposix >> /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld: >> cannot find -lpcre >> collect2: error: ld returned 1 exit status >> >> Why does adding "-static" make it fail? > > Because the mingw64-*86*-pcre/2 packages provide only dynamic libraries and > their linkage archives: <.. snip list of libpcre*.dll and .dll.a files ..> > where others provide both dynamic and static libraries e.g. > mingw64-i686-zstd: > > usr/i686-w64-mingw32/sys-root/mingw/bin/libzstd-1.dll > usr/i686-w64-mingw32/sys-root/mingw/lib/libzstd.a > usr/i686-w64-mingw32/sys-root/mingw/lib/libzstd.dll.a > > possibly where the size of useful library members are reasonably small > enough, > and unlikely to need significantly updated, to be statically linked into an > standalone executable or embedded system component, that itself may be > regularly > updated, rather than requiring large chunks of a framework to be linked that > may need regular updates. Thanks for the explanation :) I went looking to see how the mingw pcre package was built and ended up here: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/mingw64-i686-pcre.git;a=summary If that's correct and the latest then it looks to be a bit out of date; the current release is 8.44 https://ftp.pcre.org/pub/pcre/ Looking at the latest cygport info https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/mingw64-i686-pcre.git;a=blob;f=mingw64-i686-pcre.cygport;h=7456c41e6c45aad8403303aee413144fcf5d1b58;hb=3200774765aabbdda5cf4e5e9934c3d25e6e7196 and going off the current pcre doc included with the 8.44 tarball: The Autotools PCRE building process uses libtool to build both shared and static libraries by default. You can suppress one of these by adding one of --disable-shared --disable-static to the configure command, as required. The cygport info doesn't have "--disable-static" so maybe not having static libraries wasn't an intentional omission?? Thanks Lee -- 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
why does i686-w64-mingw32-gcc -static fail?
Would someone please explain why adding "-static" makes
i686-w64-mingw32-gcc fail?
This works (or at least the compiler doesn't complain)
$ i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix -lpcre
This does not work
$ i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix -lpcre
/usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
cannot find -lpcreposix
/usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
cannot find -lpcre
collect2: error: ld returned 1 exit status
Why does adding "-static" make it fail?
$ cat conftest-pcre.c
/* i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix -lpcre
* and yet this works
* i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix -lpcre
*/
char pcre_compile ();
char regcomp ();
int main () {
return pcre_compile ();
return regcomp ();
;
return 0;
}
Thanks
Lee
--
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
php memory errors
I've recently gotten out of memory errors with php, with tasks that previously have worked fine. Has anybody else experienced this too? -- 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
building net-snmp: (was: Updated: net-snmp-5.8-1)
> If you want to make a point or ask a question the Cygwin mailing list is
> the appropriate place.
You don't need this anymore
02-path-separator.patch
if you build net-snmp with
export ENV_SEPARATOR=":"
And maybe now they'll accept a patch so that building on cygwin
doesn't require an evar. I think "gcc -mno-cygwin ..." might still
have been supported when I tried to get it changed and the best they'd
do was an evar when building.
Is 06-winstub.patch necessary? Necessary if all you're using is the
command line tools?
The changelog has this
commit fda421625d20d8f8201479fa7f33c257fdc72015
Author: Bart Van Assche
Date: Sun Nov 27 11:25:40 2016 -0800
Cygwin: getnetent() / getnetbyaddr() build fix
Recent versions of Cygwin have prototypes but no implementation for
these functions. Hence avoid that the Cygwin prototypes conflict
with the implementation.
In other words, if I'm using just the snmp{get,set} command line
tools, should I be applying this patch?
Thanks,
Lee
On 4/27/20, David Rothenberger wrote:
> DESCRIPTION:
>
> Simple Network Management Protocol (SNMP) is a widely used protocol
> for monitoring the health and welfare of network equipment
> (eg. routers), computer equipment and even devices like
> UPSs. Net-SNMP is a suite of applications used to implement SNMP v1,
> SNMP v2c and SNMP v3 using both IPv4 and IPv6. The suite includes:
>
> * Command-line applications to:
> * retrieve information from an SNMP-capable device, either using
> single requests (snmpget, snmpgetnext), or multiple requests
> (snmpwalk, snmptable, snmpdelta).
> * manipulate configuration information on an SNMP-capable device
> (snmpset).
> * retrieve a fixed collection of information from an
> SNMP-capable device (snmpdf, snmpnetstat, snmpstatus).
> * convert between numerical and textual forms of MIB OIDs, and
> display MIB content and structure (snmptranslate).
> * A graphical MIB browser (tkmib), using Tk/perl.
> * A daemon application for receiving SNMP notifications
> (snmptrapd). Selected notifications can be logged (to syslog,
> the NT Event Log, or a plain text file), forwarded to another
> SNMP management system, or passed to an external application.
> * An extensible agent for responding to SNMP queries for
> management information (snmpd). This includes built-in support
> for a wide range of MIB information modules, and can be extended
> using dynamically loaded modules, external scripts and commands,
> and both the SNMP multiplexing (SMUX) and Agent Extensibility
> (AgentX) protocols.
> * A library for developing new SNMP applications, with both C and
> perl APIs.
>
> CYGWIN NOTES:
> =
> * The snmpd daemon does not provide much useful information.
>Installing it as a service under Cygwin is left as an exercise
>for the user.
>
> QUESTIONS:
> ==
> If you want to make a point or ask a question the Cygwin mailing list is
> the appropriate place.
>
>
> --
> David Rothenberger
>
> Remember: Silly is a state of Mind, Stupid is a way of Life.
> -- Dave Butler
> --
> 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: ASLR revisited
On 3/2/20, John Selbie wrote:
> And I just discovered that recompiling with this added to the g++ command
> line:
>
> -Xlinker --dynamicbase
>
> Seems to work. Or at the least, triggers the process to show up in Process
> Explorer as ASLR?
>
> Good idea to continue with this?
I haven't looked at this in ages, but for gcc I use
LDFLAGS="${LDFLAGS} -Wl,--nxcompat"
# https://en.wikipedia.org/wiki/Data_Execution_Prevention
# Enable DEP with -Wl,--nxcompat
LDFLAGS="${LDFLAGS} -Wl,--dynamicbase,--export-all-symbols"
# https://en.wikipedia.org/wiki/Address_space_layout_randomization
#
https://stackoverflow.com/questions/24283918/how-can-i-enable-aslr-dep-and-safeseh-on-an-exe-in-codeblocks-using-mingw
# ASLR with gcc has a problem: -Wl,--dynamicbase doesn't emit the
necessary relocation table.
# As a workaround, you can pass -Wl,--dynamicbase,--export-all-symbols
Regards,
Lee
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Has rename syntax changed?
On 2/28/20, Fergus Daly wrote: > I am almost certain that the command > $ rename "anything" "AnyThing" *.ext > would alter the string from lc to uc as shown, anywhere it occurred in any > filename in *.ext in the current directory. > What I remember as past behaviour now fails, leaving he filename unaltered. > (Failure in much the same way as mv would fail if the similar attempt was > made.) > (Good old DOS command rename (or the abbreviation ren) used to achieve > multiple-rename in an easy manner that just eludes bash.) > Anyway: has something altered (and quite recently, i think), or am I just > mis-remembering the versatility of the command rename? Try it with the '-v' option $ rename -v anything AnyThing *.ext `anything.ext' -> `AnyThing.ext' `xxanythingxx.ext' -> `xxAnyThingxx.ext' $ rename -v AnyThing anything *.exe rename: *.exe: not accessible: No such file or directory $ rename -v AnyThing anything *.ext `AnyThing.ext' -> `anything.ext' `xxAnyThingxx.ext' -> `xxanythingxx.ext' Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is Cygwin 3.1.X Stable Enough to Use?
On 2/21/20, Paul Moore wrote: > I had the same issue and it was fixed by 3.1.4, so yes upgrading was > likely the fix. > Paul So, getting back to the OPs question about the stability of the current cygwin.. I'd say yes, it is "stable" now. The only problem I've seen doesn't happen after I upgraded and other pty issues seem to be closing fast Lee > > On Fri, 21 Feb 2020 at 09:41, Takashi Yano > wrote: >> >> On Thu, 20 Feb 2020 21:47:25 -0500 >> Lee wrote: >> > On 2/20/20, Lee wrote: >> > > I'll try backing out the registry change & see if it still happens. >> > >> > It doesn't happen now. >> > >> > I deleted HKEY_CURRENT_USER\Console\VirtualTerminalLevel >> > rebooted >> > deleted all the .o files under /source/tidy & rebuilt >> > The output of cmake looks normal >> > >> > I updated cygwin this morning: >> > 2020/02/20 07:49:28 Augmented Transaction List: >> > 2020/02/20 07:49:280 install cygwin 3.1.4-1 >> > 2020/02/20 07:49:281 erase cygwin 3.1.2-1 >> > 2020/02/20 07:49:282 install cygwin-devel 3.1.4-1 >> > 2020/02/20 07:49:283 erase cygwin-devel 3.1.2-1 >> > >> > is it possible that fixed it? >> >> I am not sure. In my environment the problem does not occur >> even with cygwin 3.1.2. Therefore, the cause cannot be identified. >> >> -- >> Takashi Yano >> >> -- >> Problem reports: http://cygwin.com/problems.html >> FAQ: http://cygwin.com/faq/ >> Documentation: http://cygwin.com/docs.html >> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >> > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Lee wrote: > I'll try backing out the registry change & see if it still happens. It doesn't happen now. I deleted HKEY_CURRENT_USER\Console\VirtualTerminalLevel rebooted deleted all the .o files under /source/tidy & rebuilt The output of cmake looks normal I updated cygwin this morning: 2020/02/20 07:49:28 Augmented Transaction List: 2020/02/20 07:49:280 install cygwin 3.1.4-1 2020/02/20 07:49:281 erase cygwin 3.1.2-1 2020/02/20 07:49:282 install cygwin-devel 3.1.4-1 2020/02/20 07:49:283 erase cygwin-devel 3.1.2-1 is it possible that fixed it? Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Takashi Yano wrote: > On Thu, 20 Feb 2020 20:48:17 -0500 > Lee wrote: >> On 2/20/20, Takashi Yano wrote: >> > On Thu, 20 Feb 2020 16:28:26 -0500 >> > Lee wrote: >> >> For whatever it's worth, the only problem I've noticed with 3.1.4 was >> >> ansi control character handling and that was fixed by importing this >> >> bit into the registry: >> >> >> >> - >> >> Windows Registry Editor Version 5.00 >> >> >> >> [HKEY_CURRENT_USER\Console] >> >> "VirtualTerminalLevel"=dword:0001 >> >> - >> > >> > In what situation is registry modification obove necessary? >> >> see http://cygwin.com/ml/cygwin/2020-01/msg00217.html > > I cannot reproduce that. Without setting VirtualTerminalLevel, > I got: > [yano@Express5800-S70 ~...build/cmake]$ cmake ../.. > -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local > -DBUILD_SHARED_LIB:BOOL=YES -DTIDY_RC_NUMBER=next.2020.01.24 > -- The C compiler identification is GNU 7.4.0 > -- The CXX compiler identification is GNU 7.4.0 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /usr/bin/c++.exe > -- Check for working CXX compiler: /usr/bin/c++.exe -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- *** Debug Logging is NOT enabled. > -- *** Building support for runtime configuration files. > -- *** Also building DLL library SHARED, version 5.7.28, date 2019.07.08 > -- *** Generating man tidy.1 custom commands... > -- Configuring done > -- Generating done > -- Build files have been written to: /home/yano/tidy/tidy-html5/build/cmake > [yano@Express5800-S70 ~...build/cmake]$ make > Scanning dependencies of target tidy-share > [ 1%] Building C object CMakeFiles/tidy-share.dir/src/access.c.o > [ 3%] Building C object CMakeFiles/tidy-share.dir/src/attrs.c.o > [ 5%] Building C object CMakeFiles/tidy-share.dir/src/istack.c.o > [ 7%] Building C object CMakeFiles/tidy-share.dir/src/parser.c.o > [ 8%] Building C object CMakeFiles/tidy-share.dir/src/tags.c.o > [ 10%] Building C object CMakeFiles/tidy-share.dir/src/entities.c.o > [ 12%] Building C object CMakeFiles/tidy-share.dir/src/lexer.c.o > [ 14%] Building C object CMakeFiles/tidy-share.dir/src/pprint.c.o > [ 16%] Building C object CMakeFiles/tidy-share.dir/src/charsets.c.o > [ 17%] Building C object CMakeFiles/tidy-share.dir/src/clean.c.o > [ 19%] Building C object CMakeFiles/tidy-share.dir/src/message.c.o > [ 21%] Building C object CMakeFiles/tidy-share.dir/src/config.c.o > [ 23%] Building C object CMakeFiles/tidy-share.dir/src/alloc.c.o > [ 25%] Building C object CMakeFiles/tidy-share.dir/src/attrdict.c.o > [ 26%] Building C object CMakeFiles/tidy-share.dir/src/buffio.c.o > [ 28%] Building C object CMakeFiles/tidy-share.dir/src/fileio.c.o > [ 30%] Building C object CMakeFiles/tidy-share.dir/src/streamio.c.o > [ 32%] Building C object CMakeFiles/tidy-share.dir/src/tagask.c.o > [ 33%] Building C object CMakeFiles/tidy-share.dir/src/tmbstr.c.o > [ 35%] Building C object CMakeFiles/tidy-share.dir/src/utf8.c.o > [ 37%] Building C object CMakeFiles/tidy-share.dir/src/tidylib.c.o > [ 39%] Building C object CMakeFiles/tidy-share.dir/src/mappedio.c.o > [ 41%] Building C object CMakeFiles/tidy-share.dir/src/gdoc.c.o > [ 42%] Building C object CMakeFiles/tidy-share.dir/src/language.c.o > [ 44%] Building C object CMakeFiles/tidy-share.dir/src/messageobj.c.o > [ 46%] Building C object CMakeFiles/tidy-share.dir/src/sprtf.c.o > [ 48%] Linking C shared library cygtidy-5.dll > [ 48%] Built target tidy-share > Scanning dependencies of target tidy-static > [ 50%] Building C object CMakeFiles/tidy-static.dir/src/access.c.o > [ 51%] Building C object CMakeFiles/tidy-static.dir/src/attrs.c.o > [ 53%] Building C object CMakeFiles/tidy-static.dir/src/istack.c.o > [ 55%] Building C object CMakeFiles/tidy-static.dir/src/parser.c.o > [ 57%] Building C object CMakeFiles/tidy-static.dir/src/tags.c.o > [ 58%] Building C object CMakeFiles/tidy-static.dir/src/entities.c.o > [ 60%] Building C object CMakeFiles/tidy-static.dir/src/lexer.c.o > [ 62%] Building C object CMakeFiles/tidy-static.dir/src/pprint.c.o > [ 64%] Building C object CMakeFiles/tidy-static.dir/src/charsets.c.o > [ 66%] Building C object CMakeFiles/tidy-static.dir/src/clean.c.o > [ 67%] Building C objec
Re: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Takashi Yano wrote: > On Thu, 20 Feb 2020 18:34:59 -0700 > Brian Inglis wrote: >> Windows programs which emit (or use?) console ANSI escape sequences run >> from cmd >> (which by default switches off Virtual Terminal ANSI Escape Sequence >> handling >> for programs run from it) and which do not themselves set that console >> mode (or >> can not because they were written for earlier Windows which does not >> support >> that flag). > > I see. Since it appeared in the context of cygwin stability, > I thought it is a cygwin problem. It seems to be a cygwin problem; I've never seen anything like that with cmake before. & like I said earlier, this was from a mintty session started from a desktop shortcut I don't see that problem on my old PC $ uname -a CYGWIN_NT-10.0 i3668 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Brian Inglis wrote: > On 2020-02-20 18:27, Takashi Yano wrote: >> On Thu, 20 Feb 2020 18:15:59 -0700 >> Brian Inglis wrote: >>> On 2020-02-20 17:20, Takashi Yano wrote: >>>> On Thu, 20 Feb 2020 16:28:26 -0500 >>>> Lee wrote: >>>>> For whatever it's worth, the only problem I've noticed with 3.1.4 was >>>>> ansi control character handling and that was fixed by importing this >>>>> bit into the registry: >>>>> >>>>> - >>>>> Windows Registry Editor Version 5.00 >>>>> >>>>> [HKEY_CURRENT_USER\Console] >>>>> "VirtualTerminalLevel"=dword:0001 >>>>> - >>>> >>>> In what situation is registry modification obove necessary? >>> >>> Enables Console Host Virtual Terminal ANSI Escape Sequence Support; see: >>> https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences >>> https://docs.microsoft.com/en-us/windows/console/setconsolemode >>> https://blogs.msdn.microsoft.com/commandline/2017/06/20/understanding-windows-console-host-settings/ >>> https://devblogs.microsoft.com/commandline/new-experimental-console-features/ >>> https://devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/ >>> https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/ >>> https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ >>> https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/ >>> https://devblogs.microsoft.com/commandline/windows-command-line-the-evolution-of-the-windows-command-line/ >>> https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/ >>> https://github.com/MicrosoftDocs/Console-Docs >>> https://github.com/microsoft/terminal >> >> I mean what is the problem which need this in cygwin. > > Windows programs which emit (or use?) console ANSI escape sequences run from > cmd This was from a mintty console(?) session. There shouldn't have been any windows programs involved. Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Takashi Yano wrote: > On Thu, 20 Feb 2020 16:28:26 -0500 > Lee wrote: >> For whatever it's worth, the only problem I've noticed with 3.1.4 was >> ansi control character handling and that was fixed by importing this >> bit into the registry: >> >> - >> Windows Registry Editor Version 5.00 >> >> [HKEY_CURRENT_USER\Console] >> "VirtualTerminalLevel"=dword:0001 >> - > > In what situation is registry modification obove necessary? see http://cygwin.com/ml/cygwin/2020-01/msg00217.html using mintty, started from a desktop shortcut C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico - Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is Cygwin 3.1.X Stable Enough to Use?
On 2/20/20, Andrey Repin wrote: > Greetings, KARL BOTTS! > >> I am worried. I need to instruct an IT department to install Cygwin. I >> am >> afraid that if I just tell them to run the installer, they will get an >> unstable version. I am afraid other new users will be in the same boat. > > Cygwin is a rolling release distribution. Whatever is in main installation > set is considered stable. I suspect that "unstable" in this context means "likely to have noticeable problems". For whatever it's worth, the only problem I've noticed with 3.1.4 was ansi control character handling and that was fixed by importing this bit into the registry: - Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Console] "VirtualTerminalLevel"=dword:0001 - On the plus side, it's HKEY_CURRENT_USER so you don't need admin privs to import it; on the minus side, it's HKEY_CURRENT_USER so you'll have to do it for every user on the machine that'll be using cygwin. Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Calling a Windows program changes terminal character attributes
On 2/16/20, Takashi Yano wrote: > On Sun, 16 Feb 2020 01:31:14 -0800 > Mark Geisert wrote: >> Thanks Takashi for your reply. I just wanted to add that setting >> CYGWIN=disable_pcon in the environment does not fix this issue. >> Please ignore this if that's what's expected. > > CYGWIN=disable_pcon is needed to be set before launching mintty. > That is, the setting should be in user environment in system > property in control panel rather than in .bashrc. Does setting CYGWIN=disable_pcon do the same thing as adding this to the registry? - Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Console] "VirtualTerminalLevel"=dword:0001 - The registry fix was the answer I got for my "terminal control chars broken?" question to the list.. Thanks Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: terminal control chars broken?
On 1/24/20, Eugene Klimov wrote: > Try following registry file > - > Windows Registry Editor Version 5.00 > > [HKEY_CURRENT_USER\Console] > "VirtualTerminalLevel"=dword:0001 > - Thank you! That looks much better :) > also switch to cygwin 3.0 instead of cygwin 3.1.2 could help My old machine is still on 3.0.7, so I guess that explains why I haven't run into this before Regards Lee > > пт, 24 янв. 2020 г. в 12:15, Lee >> >> New Windows 10 PC, new install of 64 bit cygwin, building tidy and the >> make progress indicator is displayed on a new line each time. >> >> Since it is a new machine/setup it's probably something I'm missing/ >> didn't install, but I have no idea what :( >> >> Any idea how to keep the progress indicator on the same line? >> >> mkdir /source >> cd /source >> mkdir tidy >> cd tidy >> git clone https://github.com/htacg/tidy-html5.git >> cd tidy-html5/build/cmake >> cmake ../.. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local >> \ >> -DBUILD_SHARED_LIB:BOOL=YES \ >> -DTIDY_RC_NUMBER=next.2020.01.24 >> make >> >> and everything looks normal until it gets to >> -- Build files have been written to: /source/tidy/tidy-html5/build/cmake >> e >> [ 1%] o >> [ 3%] >> [ 5%] o >> [ 7%] >> [ 8%] o >> [ 10%] o >> [ 12%] o >> [ 14%] o >> [ 16%] o >> [ >> 17%] o >> >> [ 19%] o >> >> [ 21%] o >> >> [ 23%] o >> >> [ 25%] o >> >> [ 26%] >> >> [ 28%] o >> >> [ 30%] >>[ 32%] o >>[ 33%] o >>[ 35%] o >>[ 37%] >>[ 39%] o >>[ 41%] o >>[ 42%] o >>[ 44%] o >>[ 46%] >> o >> >> [ 48%] l >> >> [ 48%] Built target tidy-share >> c >> [ 50%] o >> [ 51%] >> [ 53%] o >> [ 55%] o >> [ 57%] o >> [ 58%] o >> [ 60%] >>[ 62%] o >>[ 64%] >>[ >> 66%] o >> >> [ 67%] o >> >> [ 69%] o >> >> [ 71%] >> >> [ 73%] o >> >> [ 75%] o >> >> [ 76%] o >> >> [ 78%] >>[ 80%] o >>[ 82%] >> [ 83%] o >> [ 85%] o >> [ 87%] o >> [ 89%] o >> [ 91%] o >> [ 92%] >> [ 94%] >> o >> >>[ 96%] a >> >>[ 96%] Built target tidy-static >> y >> [ 98%] o >> [100%] e >> [100%] Built target tidy >> n >> l >> l >>1 >> [100%] Built target man >> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
terminal control chars broken?
New Windows 10 PC, new install of 64 bit cygwin, building tidy and the make progress indicator is displayed on a new line each time. Since it is a new machine/setup it's probably something I'm missing/ didn't install, but I have no idea what :( Any idea how to keep the progress indicator on the same line? mkdir /source cd /source mkdir tidy cd tidy git clone https://github.com/htacg/tidy-html5.git cd tidy-html5/build/cmake cmake ../.. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local \ -DBUILD_SHARED_LIB:BOOL=YES \ -DTIDY_RC_NUMBER=next.2020.01.24 make and everything looks normal until it gets to -- Build files have been written to: /source/tidy/tidy-html5/build/cmake e [ 1%] o [ 3%] [ 5%] o [ 7%] [ 8%] o [ 10%] o [ 12%] o [ 14%] o [ 16%] o [ 17%] o [ 19%] o [ 21%] o [ 23%] o [ 25%] o [ 26%] [ 28%] o [ 30%] [ 32%] o [ 33%] o [ 35%] o [ 37%] [ 39%] o [ 41%] o [ 42%] o [ 44%] o [ 46%] o [ 48%] l [ 48%] Built target tidy-share c [ 50%] o [ 51%] [ 53%] o [ 55%] o [ 57%] o [ 58%] o [ 60%] [ 62%] o [ 64%] [ 66%] o [ 67%] o [ 69%] o [ 71%] [ 73%] o [ 75%] o [ 76%] o [ 78%] [ 80%] o [ 82%] [ 83%] o [ 85%] o [ 87%] o [ 89%] o [ 91%] o [ 92%] [ 94%] o [ 96%] a [ 96%] Built target tidy-static y [ 98%] o [100%] e [100%] Built target tidy n l l 1 [100%] Built target man -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: with LS_COLORS customized, ls's color scheme reverts when cd'ing to directories not under HOME
On 1/18/20, R Steiger wrote:
> The directory color assignments for dracula, flat-ui, and several other
> themes render 'ls -l' listings very hard to read (foreground and background
> are nearby blue-green shades for "d" entries). FWIW, currently theme is
> "dracula", but am getting same results for flat-ui, etc.
>
> I've tried various ways to customize colors, even saving LS_COLORS to a
> ~/.dir_colors" file, tweaking "DIR 01;31" -> DIR 01;35", and adding
> "eval `dircolors ~/.dir_colors`" on the last line of .bashrc.
Your eval quoting is slightly different than mine - maybe that's it?
if [ -f "${HOME}/.dircolors" ] ; then
eval "`dircolors -b ${HOME}/.dircolors`"
alias ls='ls --color=auto -p --append-exe'
# --color=auto colorize ls listing
# -padd "/" to directory names
# --append-exe append .exe if cygwin magic was needed
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
fi
Regards,
Lee
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia
On 12/28/19, Andrey Repin wrote: > Greetings, Peter Binney! > > Bottom posting in this list, please. > >> Hello Andrey - many thanks again. > >> I have added noacl to the default fstab entry, so it reads: >> none /cygdrive cygdrive noacl,binary,posix=0,user 0 0 > >> and that sorts out the permissions problem, thank you. > >> But, bizarrely, it introduced a new one - the WHICH command no longer >> reports non-executable files on the PATH. Try adding the exec option to fstab: $ grep cygdrive /etc/fstab # none /cygdrive cygdrive binary,posix=0,user 0 0 none /cygdrive cygdrive binary,posix=0,user,noacl,exec 0 0 $ which xcopy /cygdrive/c/windows/system32/xcopy $ ls -l /cygdrive/c/windows/system32/xcopy -rwxr-xr-x 2 Lee None 47616 Sep 15 2018 /cygdrive/c/windows/system32/xcopy.exe Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash /cmd disagree about owner and permissions to executable
On 12/26/19, Enrique Perez-Terron wrote: > I prefer to have a single installation of python, rather than having to > remember to install packages for various pythons. > I choose the standard windows 64-bit install of python 3.8 > But today when I tried to run a script ... > >> Heidi@panter ~ >> $ python3 x.py >> -bash: >> /cygdrive/c/Users/Heidi/AppData/Local/Microsoft/WindowsApps/python3: >> Permission denied > > Surprise! > > Investigating... > >> Heidi@panter ~ >> $ ls -ld "$(type -p python3)" >> -rwxr-x--- 1 Unknown+User Unknown+Group 0 des 26 19:25 >> /cygdrive/c/Users/Heidi/AppData/Local/Microsoft/WindowsApps/python3* >> >> Heidi@panter ~ >> $ cmd /C "icacls $(cygpath -w "$(type -p python3)")" >> C:\Users\Heidi\AppData\Local\Microsoft\WindowsApps\python3.exe >> NT-MYNDIGHET\SYSTEM:(I)(F) >> >> BUILTIN\Administratorer:(I)(F) >> >> PANTER\Heidi:(I)(F) >> >> S-1-19-512-4096:(RX,D,WDAC,WO,WA) >> >> Successfully processed 1 files; Failed processing 0 files >> >> Heidi@panter ~ >> $ cmd /C "dir /q $(cygpath -w "$(type -p python3)")" >> Volume in drive C is Acer >> Volume Serial Number is 3A2C-1A76 >> >> Directory of C:\Users\Heidi\AppData\Local\Microsoft\WindowsApps >> >> 26.12.2019 19.25 0 PANTER\Heidi python3.exe >>1 File(s) 0 bytes >>0 Dir(s) 155▒760▒214▒016 bytes free > > > Hey, what is this? Windows reports that the owner of the binary is > PANTER\Heidi, but /bin/ls reports Unknown+User? > > I rebboted, unistalled python and installed the app store version of > python instead, but nothing changed. > > Any suggestions? Take a look at https://cygwin.com/cygwin-ug-net/using.html#mount-table and try changing /etc/fstab # This is the default: # none /cygdrive cygdrive binary,posix=0,user 0 0 none /cygdrive cygdrive binary,posix=0,user,noacl,exec 0 0 altho with cygwin saying 'Unknown+User Unknown+Group' I don't know if that will be enough :( Somebody else will have to help you with > Windows reports that the owner of the binary is > PANTER\Heidi, but /bin/ls reports Unknown+User? Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unexpected behavior from cygpath command
On 11/13/19, Alfred von Campe wrote: > On Nov 13, 2019, at 2:08, Frank Redeker wrote: > >> I think on both systems the handling of 8.3 names is configured >> differently. You can check this with the Window command fsutil. (This >> command requires elevated permissions) >> >> I get the following output on my system. >> >> C:\WINDOWS\system32>fsutil 8dot3name query d: >> The volume state is: 0 (8dot3 name creation is enabled). >> The registry state is: 2 (Per volume setting - the default). > > Thanks, I think this is very interesting, I did not know that such a setting > existed. It was indeed disabled for my E: drive. However, after enabling > it I still can’t get “cygpath -d" to work as expected. Do the 8.3 names exist? dir E:\ /n /x ..wondering if you have to recreate the file names to get “cygpath -d" to work -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: My C arrays are too large
On 9/13/19, Jose Isaias Cabrera wrote:
>
> Achim Gratz, on Friday, September 13, 2019 02:39 PM, wrote...
>>
>> Blair, Charles E III writes:
>> > My apologies for failing to reply on-list. I don't know how :(
>> >
>> > My machine is 64 bit, and I hope I installed the correct version of
>> > cygwin.
>> >
>> > This program:
>> >
>> > #include
>> > int main(){char *a[50][8192];
>> > return 0;}
>> >
>> > compiles with gcc (no special options) but gives "Segmentation fault".
>>
>> You are creating an automatic variable that's larger than the default
>> stack. You need to enlarge the stack, either during link time or later
>> e.g. via
>>
>> peflags -x0x80 a.out
>
> This is great! Thanks.
>
> But, let's talk about this a bit... Shouldn't the compiler provide some
> warning, and also, it should never blow up with a "Segmentation fault". I
> believe there should be some type of Out Of Memory error, or something like
> it. But now just blow up. Anyone thinks like me? Just my 102 Dominican
> cents ($1 = $51 Dominican). :-)
Yes, it would be nice if you got an error message. But once you
notice a .stackdump file has magically appeared, then
$ gcc -o a.exe starray.c
$ ./a
Segmentation fault (core dumped)
$ cat a.exe.stackdump
Exception: STATUS_STACK_OVERFLOW at rip=001004010C6
<.. snip ..>
Search for "cygwin STATUS_STACK_OVERFLOW" and find
https://github.com/OpenFAST/openfast/issues/144
which gives you
$ gcc -o a.exe -Wl,--stack,0x100 starray.c
$ ./a
$ peflags -x a.exe
a.exe: stack reserve size : 16777216 (0x100) bytes
Regards,
Lee
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: More on Win7 update messing up HOME
On 8/16/19, David Karr wrote: > On Fri, Aug 16, 2019 at 10:32 AM Hans-Bernhard Bröker wrote: > >> Am 16.08.2019 um 15:28 schrieb David Karr: >> > On Fri, Aug 16, 2019 at 3:50 AM Andrey Repin wrote: >> >> >> Do you have %HOME% variable set in your user environment? >> >> Do you have %HOMEDRIVE%/%HOMEPATH% variables defined to something >> >> unsettling? >> >> > I checked "Environment Variables" in control panel, and I'm not setting >> > anything beginning with "HOME" in either user or system variables. >> >> That check is not really useful, though. >> >> You need to look at the actual environment constructed for a user >> process, at run-time. About the easiest is to start a Windows command >> shell (Start->Run "cmd") and look at the output of the "set" command. >> >> In cases of looking for names starting with some prefix, like here, you >> can narrow down the search: >> >> set HOME >> > > That just results in: > > HOMEDRIVE=C: > HOMEPATH=\Users\ > > I detailed this in another reply, but this would fit one of those checks, > which should result in "C:\Users\", which is my Windows home > directory, which does exist. I don't want it to use this, but it's not > anyway. It's resulting in "/" as my Cygwin home. Have you checked /etc/nsswitch.conf yet? $ cat /etc/nsswitch.conf # /etc/nsswitch.conf # #This file is read once by the first process in a Cygwin process tree. #To pick up changes, restart all Cygwin processes. For a description #see https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch # # Defaults: # passwd: files db # group:files db # db_enum: cache builtin # db_home: /home/%U # db_shell: /bin/bash # db_gecos: Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why is __unix__ defined, and not __WINDOWS__ ?
On 5/12/19, Hans-Bernhard Bröker wrote: > Am 12.05.2019 um 20:22 schrieb Agner Fog: > >> I have noticed that the gcc and clang compilers have defined the >> preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64 >> when compiling a windows executable. >> >> Why is this? > > Because it's correct that way. Cygwin runs on Windows, but it _is_ not > Windows. Or you can use a cross-compiler to create a 'native' windows executable that doesn't require any of the cygwin dlls. $ echo | gcc -dM -E -xc - | grep '#define _WIN32 ' $ echo | i686-w64-mingw32-gcc -dM -E -xc - | grep '#define _WIN32 ' #define _WIN32 1 Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Report Holloworld Example
Dear Sir , i am using Eclipse mit dem deo0 nano board und have a Problem which i Report to your Company. i aktuelly downloaded Cygwin new Vision 64bit (i am using 64 bit Window 10) and under D:\altera13_0\quartus\bin64\cygwin but i have still Problem.do i Need to download something für bin file? could you help me? Build of configuration Nios II for project hello_world1 make all 0 [main] sh 5744 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com 0 [main] sh 2596 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com 0 [main] echo 1992 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com Info: Building ../hello_world1_bsp/ make --no-print-directory -C ../hello_world1_bsp/ 0 [main] pwd find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com 0 [main] sh 8700 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com 0 [main] sh 852 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com [BSP build complete] 0 [main] echo 10244 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to Info: Compiling hello_world.c to obj/default/hello_world.o the public mailing list cygwin@cygwin.com 0 [main] mkdir 12424 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to nios2-elf-gcc -xc -MP -MMD -c -I../hello_world1_bsp//HAL/inc -I../hello_world1_bsp/ -I../hello_world1_bsp//drivers/inc -DSYSTEM_BUS_WIDTH=32 -pipe -D__hal__ -DALT_NO_INSTRUCTION_EMULATION -DSMALL_C_LIB -DALT_SINGLE_THREADED-O0 -g -Wall -EL -mno-hw-div -mhw-mul -mno-hw-mulx -o obj/default/hello_world.o hello_world.c the public mailing list cygwin@cygwin.com 0 [main] true 17320 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com 0 [main] echo 13580 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to Info: Linking hello_world1.elf the public mailing list cygwin@cygwin.com nios2-elf-g++ -T'../hello_world1_bsp//linker.x' -msys-crt0='../hello_world1_bsp//obj/HAL/src/crt0.o' -msys-lib=hal_bsp -L../hello_world1_bsp/ -msmallc -Wl,-Map=hello_world1.map -O0 -g -Wall -EL -mno-hw-div -mhw-mul -mno-hw-mulx -o hello_world1.elf obj/default/hello_world.o -lm nios2-elf-insert hello_world1.elf --thread_model hal --cpu_name cpu --qsys true --simulation_enabled false --id 0 --sidp 0x11010 --timestamp 1554726572 --stderr_dev jtag_uart --stdin_dev jtag_uart --stdout_dev jtag_uart --sopc_system_name DE0_NANO_QSYS --quartus_project_dir "D:/altera13_0/Projekts/myfirst_niosii" --jdi D:/altera13_0/Projekts/myfirst_niosii/myfirst_niosii.jdi --sopcinfo D:/altera13_0/Projekts/myfirst_niosii/DE0_NANO_QSYS.sopcinfo 0 [main] sh 15564 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com 0 [main] uname 9784 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com 0 [main] sh 16576 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com Info: (hello_world1.elf) 15 KBytes program size (code + initialized data). Info:12 KBytes free for stack + heap. 0 [main] sh 14564 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com [hello_world1 build complete] Build Finished -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSL not required for setup.exe download
On 3/12/19, Andrey Repin wrote: > Greetings, Lee! > >>>>> Which is way worse in my opinion, than any theoretical MITM attack, >>>>> which >>>>> is easily mitigated with proper validation of your downloads. >>> >>>> Serious question - exactly how does one do "proper validation of your >>>> downloads"? >>> >>> Use PGP signature to validate the installer. Use separate channel to >>> obtain >>> trust records for PGP key used in signing. > >> Yes, in the ideal world. But at least in my experience, most windows >> software doesn't come with a pgp signature & using a separate channel >> to get the pgp key isn't so easy. > > In my experience, this is a Cygwin mailing list and we're discussing issues > of obtaining and verifying the authenticity of setup.exe. But you made proper validation sound so easy and so general :) But ok, we'll limit it to just the cygwin setup.exe. What separate channel is available for finding the cygwin signing key? My recollection is that I gave up looking & used the link on the install page to get the public key. > P.S. > In regard to Cygwin mailing list, please teach your mail agent to not quote > raw email addresses. Sorry about that Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSL not required for setup.exe download
On 3/12/19, Andrey Repin wrote: > Greetings, Lee! > >>> It gives you false sense of security. What is worse, everybody is >>> attempting >>> to reassure this false sense on every possible occasion. > >> I don't think it's a false sense of security. https:// isn't "safe" >> but it is _safer_ than http:// > > Yep. Now, let's recall mcafee, norton, kaspersky, avast… and all those > other > "antiviruses" that proxy all TLS traffic through their own root certificate > proxy. But you did that to yourself. Hopefully you evaluated the risk/reward in letting your a/v intercept everything. Or are at least aware that your a/v is intercepting everything. Altho I have a feeling most home users aren't aware of https://www.us-cert.gov/ncas/alerts/TA17-075A I haven't been paying attention - hopefully the situation has improved. Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSL not required for setup.exe download
On 3/12/19, Achim Gratz wrote: > Lee writes: >> I don't think it's a false sense of security. https:// isn't "safe" >> but it is _safer_ than http:// > > Unless you are in an environment where an extra root cert is injected > just to be able to break up the encrypted connection. Which is a lot > more common than people think and is not quite as easy to check for as > some folks make it out. Right - checking the web-site cert on every site gets old fast. Which is why I liked the firefox cert patrol addon reminding me $WORK had their "data loss protection" screening in action. But even with the security office being able to snoop or modify every one of my https:// connections, it's just the security office people, so it still seems safer using tls than clear-text connections. Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSL not required for setup.exe download
On 3/12/19, Andrey Repin wrote: > Greetings, Lee! > >>> Which is way worse in my opinion, than any theoretical MITM attack, >>> which >>> is easily mitigated with proper validation of your downloads. > >> Serious question - exactly how does one do "proper validation of your >> downloads"? > > Use PGP signature to validate the installer. Use separate channel to obtain > trust records for PGP key used in signing. Yes, in the ideal world. But at least in my experience, most windows software doesn't come with a pgp signature & using a separate channel to get the pgp key isn't so easy. Just out of curiosity.. has the cygwin public key been posted in multiple places or sent to the mailing list? Getting the exe, sig & key from https://cygwin.com/install.html seems not the best security. > And not blindly trust "supposedly-secure" connections. I don't. But I trust TLS connections a lot more than I trust clear-text connections. Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSL not required for setup.exe download
On 3/12/19, Archie Cobbs wrote: > On Mon, Mar 11, 2019 at 6:00 PM Lee wrote: >> > I must say I'm surprised so many people think it's a good idea to >> > leave cygwin open to trivial MITM attacks, which is the current state >> > of affairs. >> >> But it's only open to a trivial MITM attack if the user types in >> "http://cygwin.com; - correct? Why isn't the fix "don't do that"? > > Because security that rests on assuming humans will always do the > correct thing has proven to be unreliable (understatement). > >> > This is my opinion only of course, but if cygwin wants to have any >> > security credibility, it should simply disallow non-SSL downloads of >> > setup.exe. Otherwise the chain of authenticity is broken forever. >> >> They sign setup.exe, so "the chain of authenticity" is there regardless. >> https://cygwin.com/setup-x86_64.exe >> https://cygwin.com/setup-x86_64.exe.sig > > I don't see your point. > > Downloading the sig file over HTTP is useless... any attacker going to > the trouble to launch a MITM attack for setup.exe will certainly also > do it for the sig file as well. Have you ever used gpg? It tells you who signed the file: $ gpg --verify cygwinSetup-x86_64.exe.sig cygwinSetup-x86_64.exe gpg: Signature made Sun, Oct 21, 2018 12:02:34 PM EDT gpg:using DSA key 0xA9A262FF676041BA gpg: Good signature from "Cygwin " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 1169 DF9F 2273 4F74 3AA5 9232 A9A2 62FF 6760 41BA So even if someone was able to hijack cygwin.com, the files I downloaded won't verify. and yes.. gpg key usage tends to devolve to 'trust on first use' but even so, it still seems better than most alternatives. Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSL not required for setup.exe download
On 3/11/19, Andrey Repin wrote: > Greetings, Archie Cobbs! > >> I must say I'm surprised so many people think it's a good idea to >> leave cygwin open to trivial MITM attacks, which is the current state >> of affairs. > >> This is my opinion only of course, but if cygwin wants to have any >> security credibility, it should simply disallow non-SSL downloads of >> setup.exe. Otherwise the chain of authenticity is broken forever. > > All the SSL stuff is build on idea of implicit unlimited trust. I agree, the whole certificate authority bit seems to .. over-promise. On the other hand, it does also seems to "raise the bar" making it much more difficult to snoop or alter data in transit. > Which is way worse in my opinion, than any theoretical MITM attack, which > is easily mitigated with proper validation of your downloads. Serious question - exactly how does one do "proper validation of your downloads"? For example, I don't have the current version of 7-zip https://www.7-zip.org/ has a download link, but I don't see anything for a .sig, checksum or anything. https://sourceforge.net/projects/sevenzip/files/7-Zip/19.00/ isn't any better. It seems to me that the best I can do is make sure I do the download via an https:// link > It gives you false sense of security. What is worse, everybody is > attempting > to reassure this false sense on every possible occasion. I don't think it's a false sense of security. https:// isn't "safe" but it is _safer_ than http:// Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SSL not required for setup.exe download
On 3/11/19, Archie Cobbs wrote: > On Mon, Mar 11, 2019 at 2:43 PM Brian Inglis wrote: >> On 2019-03-11 07:43, Archie Cobbs wrote: >> > On Sun, Mar 10, 2019 at 10:51 PM Brian Inglis wrote: >> >>>>> Is there any reason not to force this redirect and close this >> >>>>> security hole? >> >> There are apparently reasons not to force this redirect as it can also >> >> cause a >> >> security hole. >> > That's really interesting. Can you provide more detail? >> >> Search for HTTP HTTPS redirection SSL stripping MitM attack > > I did, but I only get results relating to the "stripping" attack, > which downgrades from HTTPS to HTTP. > > Obviously that would cause a reduction in security... But what I'm > suggesting is the opposite: redirecting from HTTP to HTTPS. > > How could that reduce security? part of "security" is "availability". If whatever doing the download isn't able to do TLS then redirecting to https://cygwin.com makes cygwin.com unavailable. > (sigh) > > I must say I'm surprised so many people think it's a good idea to > leave cygwin open to trivial MITM attacks, which is the current state > of affairs. But it's only open to a trivial MITM attack if the user types in "http://cygwin.com; - correct? Why isn't the fix "don't do that"? > This is my opinion only of course, but if cygwin wants to have any > security credibility, it should simply disallow non-SSL downloads of > setup.exe. Otherwise the chain of authenticity is broken forever. They sign setup.exe, so "the chain of authenticity" is there regardless. https://cygwin.com/setup-x86_64.exe https://cygwin.com/setup-x86_64.exe.sig Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: unable to run httpd with mod_rewrite
On 26/02/2019 10:30, jwang25...@gmail.com wrote: Hi Richard, Would you please shed some light on this (how to set the mutx for the rewrite map) as I am having the same issue? Thanks a lot in advance James My bad. I didn't check the error logs. Setting the mutex for the rewrite map in the conf file fixed it. On Mon, Oct 15, 2018 at 4:24 PM Richard Lee wrote: I can run httpd when mod_rewrite is disbaled in httpd.conf. When I _ Sent from http://cygwin.1069669.n5.nabble.com Mutex posixsem rewrite-map -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash string-operator problem
On 2/21/19, john doe wrote:
> On 2/21/2019 5:18 PM, Lee wrote:
>> On 2/21/19, Rockefeller, Harry wrote:
>>> CYGWIN_NT-6.1 HARRYR-PC 3.0.0(0.336/5/3) 2019-02-16 13:21 x86_64 Cygwin
>>> GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)
>>>
>>> #!/bin/bash
>>> A="A"
>>> B="A"
>>> if [ $A!=$B ]; then <- needs spaces around the !=
>>> echo -e "not identical"
>>> fi
>>> if [ $A==$B ]; then <-- needs spaces around the ==
>>> echo -e "identical"
>>> fi
<.. snip ..>
>
> One equal sign ('=') should be used instead of two equal signs ('==').
The man page for test says you're correct, but just out of curiosity
-- why do two equal signs work?
$ cat /tmp/x
#!/bin/bash
A="A"
B="A"
if [ $A == $B ]; then
echo "identical"
fi
if [ $A = $B ]; then
echo "identical"
fi
$ bash /tmp/x
identical
identical
Thanks,
Lee
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bash string-operator problem
On 2/21/19, Rockefeller, Harry wrote: > CYGWIN_NT-6.1 HARRYR-PC 3.0.0(0.336/5/3) 2019-02-16 13:21 x86_64 Cygwin > GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin) > > #!/bin/bash > A="A" > B="A" > if [ $A!=$B ]; then <- needs spaces around the != > echo -e "not identical" > fi > if [ $A==$B ]; then <-- needs spaces around the == > echo -e "identical" > fi > exit 0 > > Running this script gives > not identical > identical > > Both tests are true. because you're testing "A==B" you need to give 3 parameters "A" "==" "B" $ cat x #!/bin/bash A="A" B="A" if [ $A != $B ]; then echo "not identical" fi if [ $A == $B ]; then echo "identical" fi if [ A!=B ]; then echo "not identical" fi if [ A==B ]; then echo "identical" fi Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/9/19, JonY wrote: > On 1/9/19 7:43 PM, Lee wrote: >>> MSVCR = MicroSoft Visual C Run-time (I think) >> > > Yes, as implemented by msvcrt.dll. cool - makes much more sense now. Thank you! >> Meaning i686-w64-mingw32-gcc uses the Microsoft libraries vs. cygwin >> gcc using posix compliant libraries? Implying LC_MESSAGES not being >> defined is yet another instance of Microsoft not following accepted >> standards? >> > > Cygwin has its own runtime, Windows has its own. Microsoft does whatever > it well pleases, it never did claim POSIX or ISO C compliance. > > See the printf/scanf hacks in mingw. > >> The background for my question is >> https://github.com/htacg/tidy-html5/issues/770 >> Tidy removed the setlocale call from the library init function, so if >> users want a specific locale/language they're going to have to set it >> up themselves. >> I'd like to update the tidylib example code showing how to set the >> language, but >> setlocale(LC_ALL, ""); >> tidySetLanguage( setlocale(LC_MESSAGES, NULL) ); >> probably isn't a good example if LC_MESSAGES is missing on some systems. >> > > Unfortunately, I don't know how that should be implemented on top of a > proprietary runtime layer, or any alternative function calls for that > matter. Me either, which is why I was trying to keep it limited to system calls. But tidySetLanguage( setlocale(LC_ALL, NULL) ); isn't a good idea because setlocale returns a string starting with the value of LC_COLLATE & I suspect there's plenty enough others that prefer ascii sort order to dictionary sort order or whatever it's called. ^shrug^ since it is just example code, if LC_MESSAGES isn't defined maybe just tell them to pick a default & use that... Thanks Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/9/19, Brian Inglis wrote: > > On 2019-01-09 12:43, Lee wrote: >> On 1/9/19, Douglas Coup wrote: >>> >>> On 1/9/2019 1:14 PM, Lee wrote: >>>> On 1/9/19, JonY wrote: >>>>> On 1/8/19 9:26 PM, Lee wrote: >>>>>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html >>>>>> has a note for LC_MESSAGES: >>>>>> The functionality described is an extension to the ISO C standard. >>>>>> Application developers may make use of an extension as it is >>>>>> supported on all POSIX.1-2017-conforming systems. >>>>>> i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined. >>>>>> Is that an oversight, something missing in windows, or .. ?? >>>>> Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be >>>>> referring to opengroups, only against MSDN. >>>> What's a Windows MSVCR? >>>> Since the same program compiled with cygwins' gcc has LC_MESSAGES >>>> defined, I was guessing it was just a library thing and maybe it just >>>> hadn't been implemented in the mingw libraries yet.. but it sounds >>>> like it's not an oversight & Microsoft needs to support LC_MESSAGES >>>> before i686-w64-mingw32-gcc will. Is that about right? >>> MSVCR = MicroSoft Visual C Run-time (I think) >> Meaning i686-w64-mingw32-gcc uses the Microsoft libraries vs. cygwin >> gcc using posix compliant libraries? Implying LC_MESSAGES not being >> defined is yet another instance of Microsoft not following accepted >> standards? >> The background for my question is >> https://github.com/htacg/tidy-html5/issues/770 >> Tidy removed the setlocale call from the library init function, so if >> users want a specific locale/language they're going to have to set it >> up themselves. >> I'd like to update the tidylib example code showing how to set the >> language, but >> setlocale(LC_ALL, ""); >> tidySetLanguage( setlocale(LC_MESSAGES, NULL) ); >> probably isn't a good example if LC_MESSAGES is missing on some systems. > > You have to convert your messages to Windows message resources in your > build, then link and package Windows message resources with non-POSIX > compliant exes, or add a POSIX message implementation to your exes. I'm just trying to come up with example code for how to set the locale & language in the tidylib documentation; thankfully, me building a native windows version of tidy isn't the goal.. I was just trying out code that worked under cygwin & was a bit surprised it wouldn't even compile for windows. But it seems to be a windows limitation, so [snip snarky comment] Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/9/19, Douglas Coup wrote: > > On 1/9/2019 1:14 PM, Lee wrote: >> On 1/9/19, JonY wrote: >>> On 1/8/19 9:26 PM, Lee wrote: >>>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html >>>> has a note for LC_MESSAGES: >>>>The functionality described is an extension to the ISO C standard. >>>>Application developers may make use of an extension as it is >>>>supported on all POSIX.1-2017-conforming systems. >>>> >>>> i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined. >>>> Is that an oversight, something missing in windows, or .. ?? >>>> >>> Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be >>> referring to opengroups, only against MSDN. >> >> What's a Windows MSVCR? >> >> Since the same program compiled with cygwins' gcc has LC_MESSAGES >> defined, I was guessing it was just a library thing and maybe it just >> hadn't been implemented in the mingw libraries yet.. but it sounds >> like it's not an oversight & Microsoft needs to support LC_MESSAGES >> before i686-w64-mingw32-gcc will. Is that about right? >> >> Thanks, >> Lee >> >> > MSVCR = MicroSoft Visual C Run-time (I think) Meaning i686-w64-mingw32-gcc uses the Microsoft libraries vs. cygwin gcc using posix compliant libraries? Implying LC_MESSAGES not being defined is yet another instance of Microsoft not following accepted standards? The background for my question is https://github.com/htacg/tidy-html5/issues/770 Tidy removed the setlocale call from the library init function, so if users want a specific locale/language they're going to have to set it up themselves. I'd like to update the tidylib example code showing how to set the language, but setlocale(LC_ALL, ""); tidySetLanguage( setlocale(LC_MESSAGES, NULL) ); probably isn't a good example if LC_MESSAGES is missing on some systems. Thanks Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: i686-w64-mingw32-gcc: LC_MESSAGES
On 1/9/19, JonY wrote: > On 1/8/19 9:26 PM, Lee wrote: >> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html >> has a note for LC_MESSAGES: >> The functionality described is an extension to the ISO C standard. >> Application developers may make use of an extension as it is >> supported on all POSIX.1-2017-conforming systems. >> >> i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined. >> Is that an oversight, something missing in windows, or .. ?? >> > > Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be > referring to opengroups, only against MSDN. What's a Windows MSVCR? Since the same program compiled with cygwins' gcc has LC_MESSAGES defined, I was guessing it was just a library thing and maybe it just hadn't been implemented in the mingw libraries yet.. but it sounds like it's not an oversight & Microsoft needs to support LC_MESSAGES before i686-w64-mingw32-gcc will. Is that about right? Thanks, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
i686-w64-mingw32-gcc: LC_MESSAGES
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html
has a note for LC_MESSAGES:
The functionality described is an extension to the ISO C standard.
Application developers may make use of an extension as it is
supported on all POSIX.1-2017-conforming systems.
i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined.
Is that an oversight, something missing in windows, or .. ??
$ cat lcmessages.c
#include
#include
#include
#include
int main(int argc, char **argv )
{
char *s, *lang;
lang = getenv("LANG");
printf(" LANG=%s initial locale: %s\n", lang, setlocale(LC_ALL, NULL));
s = setlocale(LC_ALL, "");
printf("after 'setlocale(LC_ALL, \"\");' locale=%s\n", s);
#ifdef LC_MESSAGES
s = setlocale(LC_MESSAGES, "de_DE.utf8");
printf("after 'setlocale(LC_MESSAGES, \"de_DE.utf8\");'
locale=%s\n", setlocale(LC_ALL, NULL));
#else
printf("LC_MESSAGES is not defined\n");
#endif
}
$ gcc lcmessages.c
$ ./a
LANG=en_US.UTF-8 initial locale: C
after 'setlocale(LC_ALL, "");'
locale=C/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8
after 'setlocale(LC_MESSAGES, "de_DE.utf8");'
locale=C/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/de_DE.utf8
$ i686-w64-mingw32-gcc lcmessages.c
$ ./a
LANG=en_US.UTF-8 initial locale: C
after 'setlocale(LC_ALL, "");' locale=English_United States.1252
LC_MESSAGES is not defined
Thanks,
Lee
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Something makes curl hang for 5 minutes after connection refused
On 11/30/18, Basin Ilya wrote: > Hi. > > Recently I noticed that `curl` does not fail immediately after connection > refused, but waits for 5 minutes. > > This only happens on my machine and only with the `Cygwin` version of > `curl`. The mingw version is unaffected. > I tried downgrading curl, but it didn't help. I thought there's a rogue > setting in `/etc` or in home or maybe some environment variable, but I > couldn't find it. > > basin@BASIN /cygdrive/c/Users/basin > $ >/dev/null /usr/bin/curl -v http://127.0.0.1:2/ > * STATE: INIT => CONNECT handle 0x80048658; line 1404 (connection > #-5000) > * Added connection 0. The cache now contains 1 members > * Trying 127.0.0.1... > * TCP_NODELAY set > * STATE: CONNECT => WAITCONNECT handle 0x80048658; line 1456 (connection > #0) <.. snip ..> > curl: (28) Connection timed out after 300145 milliseconds > > basin@BASIN /cygdrive/c/Users/basin > $ /usr/bin/curl --version > curl 7.59.0 (i686-pc-cygwin) libcurl/7.59.0 OpenSSL/1.0.2p zlib/1.2.11 > libidn2/2.0.4 libpsl/0.18.0 (+libidn2/2.0.2) libssh2/1.7.0 nghttp2/1.31.0 > Can someone try to reproduce it? I get the same behavior: $ /usr/bin/curl -v http://127.0.0.1:2/ * STATE: INIT => CONNECT handle 0x600057ad0; line 1404 (connection #-5000) * Added connection 0. The cache now contains 1 members * Trying 127.0.0.1... * TCP_NODELAY set * STATE: CONNECT => WAITCONNECT handle 0x600057ad0; line 1456 (connection #0) * Connection timed out after 300324 milliseconds * multi_done * stopped the pause stream! * Closing connection 0 * The cache now contains 0 members curl: (28) Connection timed out after 300324 milliseconds $ /usr/bin/curl --version curl 7.59.0 (x86_64-unknown-cygwin) libcurl/7.59.0 OpenSSL/1.0.2p zlib/1.2.11 libidn2/2.0.4 libpsl/0.18.0 (+libidn2/2.0.2) libssh2/1.7.0 nghttp2/1.31.0 I also get an almost immediate 'failed to connect' notice on windows: C:\>C:\UTIL\curl\curl.exe -v http://127.0.0.1:2/ * Trying 127.0.0.1... * TCP_NODELAY set * connect to 127.0.0.1 port 2 failed: Connection refused * Failed to connect to 127.0.0.1 port 2: Connection refused * Closing connection 0 curl: (7) Failed to connect to 127.0.0.1 port 2: Connection refused with either version of curl: C:\>where curl C:\UTIL\curl\curl.exe C:\Windows\System32\curl.exe Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 3.7.1
On 10/31/18, Noah Andrew wrote: > Hi All, > Sorry if this has been answered somewhere already - I checked the > FAQ/StackExchange/Quora and didn't find anything, so coming to the mailing > list as a last resort. I was wondering if it's possible to install the > latest version of python for Cygwin - all I can find right now is 3.6.4. I > can't find it in the library, but is it possible to still use the new > version somehow? Maybe routing it to a different python installation or > somehow installing from command line? Get the source code and 'make && make install' https://docs.python.org/3/using/unix.html#building-python I don't know what or if anything else in cygwin depends on python. If the latest version is not quite compatible with the cygwin supplied version it'd probably be best to install to a non-standard location so they don't conflict .. and make it easier to throw away when cygwin comes out with that or a later version. Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: erro
On 10/23/18, Andrey Repin wrote: > Greetings, Lee! > >>> https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings > >> Except that the faq is wrong in this case: >> The solution is simply downloading and running Cygwin Setup ... > >> The solution for programs that come bundled with cygwin1.dll (like jtr >> here) is to replace the old cygwin1.dll > > Which is unlikely to succeed for such an old version. Yup - looks like you're right. I thought I remembered copying the current cygwin1.dll to my jtr directory when moving to win10 about 1.5 yrs ago. But the only john-xxx.zip I can find in my backup that has just cygwin1.dll & no other cygwin dlls doesn't work on win10 Sorry for the noise Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: erro
On 10/22/18, john doe wrote: > On 10/22/2018 4:58 PM, Cartões Bella Arte wrote: >> C:\Users\gian.Bortoli\Desktop\john180j1w\run>zip2john.exE -A >> >> 0 [main] zip2john 10064 find_fast_cwd: WARNING: Couldn't compute >> FAST_CWD pointer. Please report this problem to the public mailing list >> cygwin@cygwin.com >> zip2john: unknown option -- A >> >> >> >> C:\Users\gian.Bortoli\Desktop\john180j1w\run>john.exe --pot=018.pot >> --wordlist=john/run/password.lst 018.hash >> >> 0 [main] john 8972 find_fast_cwd: WARNING: Couldn't compute >> FAST_CWD >> point >> >> er. Please report this problem to the public mailing list >> cygwin@cygwin.com >> >> No password hashes loaded (see FAQ) >> > > This is, if I'm not mistaking, the third e-mails in a little while with > to some extend the same error, verry strange. > But here we go again: > > https://cygwin.com/faq/faq.html#faq.using.fixing-find_fast_cwd-warnings Except that the faq is wrong in this case: The solution is simply downloading and running Cygwin Setup ... The solution for programs that come bundled with cygwin1.dll (like jtr here) is to replace the old cygwin1.dll that came with the program with a current copy. I have no idea if one can get just the current cygwin1.dll - if it is possible it'd be nice to add a how2 to the faq Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: unable to run httpd with mod_rewrite
My bad. I didn't check the error logs. Setting the mutex for the rewrite map in the conf file fixed it. On Mon, Oct 15, 2018 at 4:24 PM Richard Lee wrote: > > I can run httpd when mod_rewrite is disbaled in httpd.conf. When I > enable it, httpd immediately exits. It was working last year. I'm > running x86_64 Cygwin on Windows 10. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
unable to run httpd with mod_rewrite
I can run httpd when mod_rewrite is disbaled in httpd.conf. When I enable it, httpd immediately exits. It was working last year. I'm running x86_64 Cygwin on Windows 10. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: getclip/putclip not present?
On 10/4/18, Greywolf wrote: > Greetings, > > I have two installations of x86_64 cygwin, one at home, one at work. Both > under windows 10. > > The one at work has getclip/putclip. > > The one at home does not, and I cannot locate them anywhere. https://cygwin.com/cgi-bin2/package-grep.cgi?grep=putclip=x86_64 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: speeding up a paste operation
On 8/25/18, Andrey Repin wrote: > Greetings, Lee! > >>> >>> what about 'cp /dev/clipbord /tmp/hosts'? > >> Much better! That takes about the same time as pasting into notepad, >> so I'm guessing that's about as fast as I can expect. > >> but I need to convert line endings: >> $ file hosts.txt >> hosts.txt: ASCII text, with CRLF line terminators > > Do you expect us to answer "d2u < /dev/clipboard | wherever" ? > Or can you stop being lazy and start producing such simple answers > yourself? It's not laziness, it's hoping for the magical incantation that will speed up the right click/paste operation. But nobody has referenced my >> Oh well... I was hoping I'd set up something wrong in cygwin so let's close out the thread; at least on my machine, there's a clear winner for pasting in an absurdly large amount of text: $ time d2u < /dev/clipboard > hosts-3.txt real0m11.372s user0m3.749s sys 0m6.984s $ time cat /dev/clipboard | tr -d '\r' > hosts-2.txt real0m4.405s user0m0.124s sys 0m3.577s $ time getclip -u > hosts.txt real0m0.734s user0m0.031s sys 0m0.031s My thanks to everyone who gave me alternatives to simple pasting. And a special thanks to all the devs that have made things so much better that I completely forgot about pasting text being slow. In an off-list conversation I mentioned that I used to limit pasting to no more than 5-10K lines. But that was back in WinXP days; since then there's been cygwin-64, mintty, and I don't know what all else that are so much better now. Thank you!! Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: speeding up a paste operation
On 8/25/18, wrote: > Am 25.08.2018 um 02:10 schrieb Lee: >> On 8/24/18, James Darnley wrote: >>> On 2018-08-25 01:30, Lee wrote: >>>> In retrospect, I should have created the file some other way, but >>>> still.. >>>> - grab the top 1M hosts from from >>>> http://s3-us-west-1.amazonaws.com/umbrella-static/index.html >>>> - open w/ libreoffice >>>> - select the host name column, right click & select copy (all 1 million >>>> lines) >>>> - (mintty 2.9.0 window already open) vi /tmp/hosts >>>> - i (get into insert mode) >>>> - right click (which I have set to "paste") >>>> >>>> data is still scrolling by & it's not even up to 100K lines yet :( >>>> >>>> Is there some way to make a paste operation faster in mintty (or vim >>>> or whatever the slowpoke is)? >>> There's a utility called getclip which put the clipboard onto stdout. >>> Direct that into a file and you should get the same result, excluding >>> Vim's indentation. Probably doesn't use the tty in anyway. >> >> Is getclip different from >>cat > /tmp/hosts >> > > Of course it is, Are there cygwin man pages or package descriptions somewhere? I did a search on "getclip site:cygwin.com" and didn't see anything that looked like a description. > it goes through the terminal and the pty. Both are > shortcut if you copy from /dev/clipboard, using either cat or cp. ok... searched for 'cygwin getclip' and found https://stackoverflow.com/questions/1322594/cygwin-command-to-copy-to-windows-clipboard The advantage of getclip/putclip over /dev/clipboard is that the former have options to convert between unix and dos line endings. so I do need to take a look at getclip :) Thanks Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: speeding up a paste operation
On 8/25/18, Frank Redeker wrote: > Am 25.08.2018 um 02:10 schrieb Lee: >> On 8/24/18, James Darnley wrote: >>> On 2018-08-25 01:30, Lee wrote: >>>> In retrospect, I should have created the file some other way, but >>>> still.. >>>> - grab the top 1M hosts from from >>>> http://s3-us-west-1.amazonaws.com/umbrella-static/index.html >>>> - open w/ libreoffice >>>> - select the host name column, right click & select copy (all 1 million >>>> lines) >>>> - (mintty 2.9.0 window already open) vi /tmp/hosts >>>> - i (get into insert mode) >>>> - right click (which I have set to "paste") >>>> >>>> data is still scrolling by & it's not even up to 100K lines yet :( >>>> >>>> Is there some way to make a paste operation faster in mintty (or vim >>>> or whatever the slowpoke is)? >>> >>> There's a utility called getclip which put the clipboard onto stdout. >>> Direct that into a file and you should get the same result, excluding >>> Vim's indentation. Probably doesn't use the tty in anyway. >> >> Is getclip different from >> cat > /tmp/hosts >> >> >> at least 'cat > /tmp/hosts' that goes faster than I can read. But >> while that's running I can open notepad, paste the 1M lines in there, >> save to \cygwin\tmp\doshosts, open another mintty window & dos2unix >> /tmp/doshosts -- all that before the finishes :( >> >> Thanks, >> Lee > >Hi Lee, > > what about 'cp /dev/clipbord /tmp/hosts'? Much better! That takes about the same time as pasting into notepad, so I'm guessing that's about as fast as I can expect. but I need to convert line endings: $ file hosts.txt hosts.txt: ASCII text, with CRLF line terminators Thanks Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: speeding up a paste operation
On 8/24/18, Steven Penny wrote:
> On Fri, 24 Aug 2018 19:30:10, Lee wrote:
>> In retrospect, I should have created the file some other way, but still..
>> - grab the top 1M hosts from from
>> http://s3-us-west-1.amazonaws.com/umbrella-static/index.html
>> - open w/ libreoffice
>> - select the host name column, right click & select copy (all 1 million
>> lines)
>> - (mintty 2.9.0 window already open) vi /tmp/hosts
>> - i (get into insert mode)
>> - right click (which I have set to "paste")
>>
>> data is still scrolling by & it's not even up to 100K lines yet :(
>>
>> Is there some way to make a paste operation faster in mintty (or vim
>> or whatever the slowpoke is)?
>
> Use the right tool for the job:
>
> $ time awk -F, '{print $2}' top-1m.csv > hosts.txt
> real0m0.686s
I'd forgotten how slow pasting is in cygwin.. otherwise I'd have just
deleted column 1, saved as text & dos2unix'ed the file
Oh well... I was hoping I'd set up something wrong in cygwin, but at
least I remember why not to paste lots o lines in cygwin.
Thanks
Lee
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: speeding up a paste operation
On 8/24/18, James Darnley wrote: > On 2018-08-25 01:30, Lee wrote: >> In retrospect, I should have created the file some other way, but still.. >> - grab the top 1M hosts from from >> http://s3-us-west-1.amazonaws.com/umbrella-static/index.html >> - open w/ libreoffice >> - select the host name column, right click & select copy (all 1 million >> lines) >> - (mintty 2.9.0 window already open) vi /tmp/hosts >> - i (get into insert mode) >> - right click (which I have set to "paste") >> >> data is still scrolling by & it's not even up to 100K lines yet :( >> >> Is there some way to make a paste operation faster in mintty (or vim >> or whatever the slowpoke is)? > > There's a utility called getclip which put the clipboard onto stdout. > Direct that into a file and you should get the same result, excluding > Vim's indentation. Probably doesn't use the tty in anyway. Is getclip different from cat > /tmp/hosts at least 'cat > /tmp/hosts' that goes faster than I can read. But while that's running I can open notepad, paste the 1M lines in there, save to \cygwin\tmp\doshosts, open another mintty window & dos2unix /tmp/doshosts -- all that before the finishes :( Thanks, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
speeding up a paste operation
In retrospect, I should have created the file some other way, but still.. - grab the top 1M hosts from from http://s3-us-west-1.amazonaws.com/umbrella-static/index.html - open w/ libreoffice - select the host name column, right click & select copy (all 1 million lines) - (mintty 2.9.0 window already open) vi /tmp/hosts - i (get into insert mode) - right click (which I have set to "paste") data is still scrolling by & it's not even up to 100K lines yet :( Is there some way to make a paste operation faster in mintty (or vim or whatever the slowpoke is)? TIA Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: wget does not recognize PKI?
On 8/5/18, Andrey Repin wrote:
> Greetings, All!
Greetings, Andrey Repin!
> $ wget https://ca.rootdir.org/ca.crl
> --2018-08-05 20:05:28-- https://ca.rootdir.org/ca.crl
> Resolving ca.rootdir.org (ca.rootdir.org)... 192.168.1.6
> Connecting to ca.rootdir.org (ca.rootdir.org)|192.168.1.6|:443...
> connected.
> ERROR: The certificate of ‘ca.rootdir.org’ is not trusted.
> ERROR: The certificate of ‘ca.rootdir.org’ hasn't got a known issuer.
>
> $ "$( which wget )" --version
> GNU Wget 1.19.1 built on cygwin.
>
> -cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls +ntlm
> +opie +psl +ssl/gnutls
>
> The root CA certificate is correctly installed and hashed.
Apparently not. Does it work if you tell wget to use your root CA cert?
‘--ca-certificate=FILE’
Use FILE as the file with the bundle of certificate authorities
(“CA”) to verify the peers. The certificates must be in PEM
format.
Without this option Wget looks for CA certificates at the
system-specified locations, chosen at OpenSSL installation time.
& you probably have, but to be sure.. you looked at 'info
update-ca-trust' - right?
This might help verify your trust store:
$ cat listcerts.sh
#!/bin/sh
# ref:
https://serverfault.com/questions/590870/how-to-view-all-ssl-certificates-in-a-bundle
if [ $# -eq 1 ]; then
# bundle specified
FILE="$1"
if [ ! -r $FILE ]; then
echo "p1 unreadable: $FILE"
exit 1
fi
else
FILE="/usr/ssl/certs/ca-bundle.crt"
# FILE="/etc/pki/tls/certs/ca-bundle.crt"
# FILE="/etc/pki/tls/certs/ca-bundle.trust.crt"
fi
cat $FILE |\
awk -v cmd="openssl x509 -noout -subject " '
/^-BEGIN/ { c = $0; next }
{ c = c "\n" $0 }
/^-END/ { print c|cmd; close(cmd); c = "" }
'
# openssl x509 -noout -text
# to see all the certificate info
# oopenssl x509 -noout -subject
# to see just the subject
$
Regards,
Lee
>
> $ ls -l /etc/ssl/certs/
> total 3
> lrwxrwxrwx 1 anrdaemon None 13 мар 31 01:30 a94d09e5.0 -> ca-bundle.crt
> lrwxrwxrwx 1 anrdaemon None 49 мар 12 02:29 ca-bundle.crt ->
> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
> lrwxrwxrwx 1 anrdaemon None 55 мар 12 02:29 ca-bundle.trust.crt ->
> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
> lrwxrwxrwx 1 anrdaemon None 18 мар 31 01:30 dd07c56a.0 ->
> Rootdir.org_CA.crt
> drwxr-xr-x+ 1 anrdaemon None 0 апр 22 16:50 demo
> drwxr-xr-x+ 1 anrdaemon None 0 апр 22 16:50 expired
> -rw-r--r-- 1 anrdaemon None 165 апр 3 14:04 README.RootCerts
> lrwxrwxrwx 1 anrdaemon None 29 фев 14 04:41 Rootdir.org_CA.crt ->
> /etc/ssl/ca-20120530-0121.crt
>
> What's going on?
>
>
> --
> With best regards,
> Andrey Repin
> Sunday, August 5, 2018 20:07:02
>
> Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: UTF-8 character encoding
On 6/26/18, Michael Enright wrote: > On Mon, Jun 25, 2018 at 11:33 AM, Lee wrote: >> I'm still trying to figure utf-8 out, but it seems to me that 0x0 - >> 0xff is part of the utf-8 encoding. > > I don't see how you arrived at this. I screwed up trying to do hex in my head. For whatever reason I didn't want to write 0 - 127 > An initial byte of 0xFF is not > the initial byte of any valid UTF-8 byte sequence. And it doesn't > conform with the statement you have later: right, I screwed up :) > The standards such as IETF RFC-3629 are easy enough to read, so I > recommend using them and citing them to others instead of trying to > summarize. Thanks for the RFC reference - I hadn't come across that one yet. Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: UTF-8 character encoding
On 6/26/18, Thomas Wolff wrote: > This encoding scheme is wrong; where did you get it from? Maybe it's the > obsolete UTF-8... http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt I thought I saw something about utf-8 being able to handle a 31 bit value.. is that also obsolete/wrong? how about this for the current encoding scheme: http://www.unicode.org/versions/Unicode11.0.0/ch03.pdf Table 3-6. UTF-8 Bit Distribution BitsScalar Value First Byte Second Byte Third Byte Fourth Byte 7 0xxx0xxx 11 0yyy yyxx110y10xx 16 yyxx111010yy 10xx 21 000u yyxx 0uuu10uu 10yy10xxxxxx Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: UTF-8 character encoding
On 6/24/18, L A Walsh wrote: > Lee wrote: >> So... keep it simple, set >> LANG=en_US.UTF-8 >> and use vi or something else that comes with cygwin to create the file >> and I'll have a file with UTF-8 character encoding - correct? > --- > The first 127 characters of UTF-8 are identical to the > first 127 characters of ASCII, and latin1 and iso-8859-1. > > If you don't use any characters that need accents or special symbols, > then nothing will be encoded in UTF-8, because its only > the characters OVER the first 127 > (see chart @ http://www.babelstone.co.uk/Unicode/babelmap.html). I'm still trying to figure utf-8 out, but it seems to me that 0x0 - 0xff is part of the utf-8 encoding. This chart makes things clearer ... at least for me :) http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt The proposed UCS transformation format encodes UCS values in the range [0,0x7fff] using multibyte characters of lengths 1, 2, 3, 4, and 5 bytes. For all encodings of more than one byte, the initial byte determines the number of bytes used and the high-order bit in each byte is set. An easy way to remember this transformation format is to note that the number of high-order 1's in the first byte is the same as the number of subsequent bytes in the multibyte character: Bits Hex Min Hex Max Byte Sequence in Binary 17 007f 0zzz 2 13 0080 207f 10zz 1yyy 3 19 2080 0008207f 110z 1yyy 1xxx 4 25 00082080 0208207f 1110 1yyy 1xxx 1www 5 31 02082080 7fff 11110zzz 1yyy 1xxx 1www 1vvv Thanks Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: UTF-8 character encoding
On 6/20/18, Andrey Repin wrote: > Greetings, Lee! > >> I'm looking at >> https://cygwin.com/packaging-hint-files.html#pvr.hint >> and it starts off with >> Use UTF-8 character encoding. > >> How do I do that and how do I check that I actually did use UTF-8 >> character encoding _without_ using file? > > https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/ I think I don't know enough to ask the right question. A quick search yesterday on byte order markers turned up https://msdn.microsoft.com/en-us/library/windows/desktop/dd374101(v=vs.85).aspx with this bit Note Microsoft uses UTF-16, little endian byte order. So... keep it simple, set LANG=en_US.UTF-8 and use vi or something else that comes with cygwin to create the file and I'll have a file with UTF-8 character encoding - correct? Thanks, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
UTF-8 character encoding
I'm looking at https://cygwin.com/packaging-hint-files.html#pvr.hint and it starts off with Use UTF-8 character encoding. How do I do that and how do I check that I actually did use UTF-8 character encoding _without_ using file? for whatever it's worth: $ file unicode.html unicode.html: HTML document, UTF-8 Unicode text $ file test.c test.c: C source, ASCII text I used vi to create both files & I'd like to understand why file says one is ascii & the other is utf-8 Thanks, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Re: Problematic interpretion of paths starting with double slashes
On 6/12/18, Sven Eden wrote:
>> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr Von: "Eric Blake"
>> Then fix your script to provide 3 slashes instead of 2. Only 2 slashes
>> has the magic UNC behavior.
>
> It is not my script. *my* scripts are portable by all means.
>
>> That is, if you have a script that is concatenating:
>>
>> ${prefix}/${dir}
>>
>> where ${prefix} might be empty, you can always rewrite it to be:
>>
>> ${prefix}///${dir}
>
> The script was "fixed" from ${prefix}/${dir} a while ago.
> Before that the outcome was "///".
>
> Which is very bad style.
but it was portable
> Good style is to guarantee, that
> not more than one slash is issued.
Why don't you submit a patch to guarantee that not more than one slash
is issued?
Or submit a bug report that the earlier patch broke portability?
Asking cygwin to change their long standing, posix allowed,
implementation defined behavior seems like the least likely way to get
the problem fixed.
Regards,
Lee
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CYGWIN 2.8
On 5/14/18, cyg Simple wrote: > On 5/8/2018 3:28 PM, Hans-Bernhard Bröker wrote: >> Am 08.05.2018 um 13:22 schrieb David Spencer: >>> Morning, >>> >>> I am trying to get CYGWIN Version 2.8, this is the only version >>> approved for our system at present, > > So your company is stating it wants to use buggy and susceptible > applications. I don't think so. And I don't think you've ever experienced the joys of being a USG contractor :) Go back to the original post & look at their email address. I'm betting they're a contractor. > Go back to the IT security team and > state that 2.10 is the latest version of Cygwin and ask if it is okay. Which is assuming that whatever person on the IT security team you ask has the authority to override policy. Staff _follows_ policy, they don't make it. > If not then ask them to provide you with a suitable version. You seem to be under the impression that contractors are allowed to make waves and stay employed there. >> Providing that is, to a great extent, actually the job of whoever >> approves versions of Cygwin for you. I'd say it's the job of whoever came up with the policy of having an 'approved software' list in the first place to also come up with a policy of keeping the list current but whatever.. It'd be nice to think the situation has changed in the years since I was in the same position but apparently not. What worked for me was opening a support ticket with the group that keeps the approved software list and asking what it takes to get the current version of cygwin approved. There's forms to be filled out, procedures to be followed, and in a few weeks the current version of cygwin is on the approved list. Regards, Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Failure download cygwin
On 5/13/18, david wrote: > > > > At 09:20 AM 5/12/2018, Brian Inglis wrote: >>On 2018-05-12 09:06, david wrote: >> > I tried to install the full collection from cygwin 64-bit. Yes, I >> know "you >> > really don't want to do that", but nevertheless, I do. >> > Using three different download mirrors, I find a large number of >> > packages >> > have failed. A partial list is given below. In the past, the download >> > has >> > succeeded, and yes, it took hours. >> > Please advise. >> > My most recent download attempt was from >> > ftp://linux.rz.ruhr-uni-bochum.de/cygwin >> > Download failures: (partial list) >>... >> >>You may be more successful if you preload your local package cache using >> e.g. >>wget -m, with some retry (and rate) limiting options, from your >>closest, lowest >>latency, fastest transfer rate, http mirror. >> >>-- > > Brian: > I followed your suggestion, but still had problems. After some more > experiments, I figured out that the file names were too long, and > thus the downloads failed. Unfortunately, this was not diagnosed by > "setup", which, in my opinion, should not allow a download to start > if the file names won't fit in the current Windows. I assume > (perhaps incorrectly), that there is a limit to package name length. > > For example, I used as the directory >d:\arch\archiven\cygwin.2.10.0 > and the selection of the download site made it > > d:\arch\archiven\cygwin.2.10.0\ftp%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fcygwin%2f > which is getting pretty long. Which is only 7 characters longer than my download directory: C:\cygwin\packages\http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f and has things like Directory of C:\cygwin\packages\http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f\noarch\release\texlive-collection-fontsrecommended 06/17/2017 06:21 AM92,157,056 texlive-collection-fontsrecommended-20170520-1.tar.xz Have you tried using a http:// mirror? Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: inotify?
On 03/05/2018 10:35, Ulli Horlacher wrote: Is there a similar service "tell me of new files in this directory tree" in Windows which I can use instead? Windows does have its own file and directory watching API. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
