Re: Bash 5 bug in Cygwin only: empty pattern inside a regular expression

On Feb 24 17:01, LLoyd via Cygwin wrote: > Hello. > > I'll try to keep this short: > In Cygwin only, using bash 5.2.21-1 or 5.2.15-3 (the only 5.* versions > available), "empty" in a regular expression is not properly matched > and breaks the regular expression. > It's not a quoting issue, I also

Re: Bash 5 bug in Cygwin only: empty pattern inside a regular expression

On Mon, 24 Feb 2025 at 17:01, LLoyd wrote: > > [...] > reg='foo|'; [[ foo =~ $regex ]] > > [...] Sorry, typo on that line, I meant to write that I also tested: regex='foo|'; [[ foo =~ $regex ]] It's probably a libc bug. Please let me know if I can do anything. LLoyd -- Problem reports: h

Re: bash hangs on cygwin-3.5.5-1

On Wed, 25 Dec 2024, Jeremy Drake via Cygwin wrote: > We ran into hang issues with libtool linking imagemagick in msys2, using > version based on 3.5.5, 3 times in a row on our ARM64 runner. We applied > your v2 patch to our 3.5.5 branch (with the change of current_sig to sig), > and the issue no

Re: bash hangs on cygwin-3.5.5-1

On Wed, 25 Dec 2024 15:33:13 -0800 (PST) Jeremy Drake wrote: > On Wed, 25 Dec 2024, Takashi Yano via Cygwin wrote: > > > On Tue, 24 Dec 2024 22:34:44 +0100 > > Bruno Haible wrote: > > > This is not reproducible, but here's the report anyway: > > > > > > I upgraded a Windows 10 system from Cygwin 3

Re: bash hangs on cygwin-3.5.5-1

On Wed, 25 Dec 2024, Takashi Yano via Cygwin wrote: > On Tue, 24 Dec 2024 22:34:44 +0100 > Bruno Haible wrote: > > This is not reproducible, but here's the report anyway: > > > > I upgraded a Windows 10 system from Cygwin 3.5.3 to 3.5.5 today. > > Then ran the configure script of a tarball (*), an

Re: bash hangs on cygwin-3.5.5-1

On Tue, 24 Dec 2024 22:34:44 +0100 Bruno Haible wrote: > This is not reproducible, but here's the report anyway: > > I upgraded a Windows 10 system from Cygwin 3.5.3 to 3.5.5 today. > Then ran the configure script of a tarball (*), and it hung: > > $ mkdir build-cygwin64 > $ cd build-cygwin64 > $

Re: bash builtin printf date format problem

On Mon, 1 Apr 2024 at 16:29, Chris Elvidge via Cygwin wrote: > > Using bash builtin printf '%(fmt)T', when fmt contains %-d (or %_d), > there is no output - should print daynumber with no preceding 0 (or with > preceding space). Similarly %-e. date +"%B %-d" works OK. > > $ uname -a > CYGWIN_NT-10.

Re: bash shell script: recently running, now failing

Greetings, Brian Inglis via Cygwin! > On 2023-04-06 06:21, Andrey Repin via Cygwin wrote: >>> I have a "hash bang" bash shell script i.e. first line >>> #! /bin/sh >>> or equivalently >>> #! /bin/bash >> By default, sh is bash in base Cygwin installation. >>> Q3 - at 1/8 the size of bash and sh,

Re: bash shell script: recently running, now failing

On 2023-04-06 06:21, Andrey Repin via Cygwin wrote: I have a "hash bang" bash shell script i.e. first line #! /bin/sh or equivalently #! /bin/bash By default, sh is bash in base Cygwin installation. Q3 - at 1/8 the size of bash and sh, I am not at all sure of the role and reach of dash. Sh

Re: bash shell script: recently running, now failing

Coming from an enterprise and supercomputing background, we were able to control what shell was available, so bashisms weren't a problem any more than dashisms, fishisms, kornisms, perl or python versionisms, etc, might be. But, when I was in a commercial environment, everything - shell, perl, C,

Re: bash shell script: recently running, now failing

On Thu, Apr 06, 2023 at 04:43:51AM +, Fergus Daly via Cygwin wrote: > I have a "hash bang" bash shell script i.e. first line > #! /bin/sh > or equivalently > #! /bin/bash > For various reasons I want this file to be identified as binary so its second > line > is the single character null \x00

Re: bash shell script: recently running, now failing

Greetings, Fergus Daly! > I have a "hash bang" bash shell script i.e. first line > #! /bin/sh > or equivalently > #! /bin/bash By default, sh is bash in base Cygwin installation. > Q3 - at 1/8 the size of bash and sh, I am not at all sure of the role and > reach of dash. > Should the edit (dash

Re: bash shell script: recently running, now failing

Place the nul on the third line. For example: #!/bin/bash # # ^@ identify as a binary file ... On Thu, Apr 6, 2023 at 4:03 AM Corinna Vinschen via Cygwin < cygwin@cygwin.com> wrote: > On Apr 6 04:43, Fergus Daly via Cygwin wrote: > > I have a "hash bang" bash shell script i.e. first line > >

Re: bash shell script: recently running, now failing

On Apr 6 04:43, Fergus Daly via Cygwin wrote: > I have a "hash bang" bash shell script i.e. first line > #! /bin/sh > or equivalently > #! /bin/bash > For various reasons I want this file to be identified as binary so its second > line > is the single character null \x00 showing up in some editor

Re: Bash 1876 error occured

On 2023-01-15 14:24, Nouman Shahid via Cygwin wrote: Bash 1876 error occured That's neither a command line or an actual error message that tells anyone anything about what your problem was, what command caused it, and what versions of bash, Cygwin, and Windows you are running. Ideally, plea

Re: bash from local mounted drive with subst command

We're running into this same issue on my project. We're trying to shorten path names to get around Visual Studio limitations in path lengths, which are unfortunately very long for us since we're generating filenames based on package names and the like. If subst won't work to let us shorten path n

Re: bash: cd: /cygdrive/w: Too many levels of symbolic links

On Fri, 29 Apr 2022 18:27:45 -0500 Wes Barris wrote: > On 4/29/2022 6:09 PM, Takashi Yano wrote: > > On Fri, 29 Apr 2022 14:21:01 -0500 > > Wes Barris wrote: > >> For the past couple of months the latest versions of cygwin produce this > >> error > >> when attempting to reference a network drive.

Re: bash: cd: /cygdrive/w: Too many levels of symbolic links

On 4/29/2022 6:09 PM, Takashi Yano wrote: On Fri, 29 Apr 2022 14:21:01 -0500 Wes Barris wrote: For the past couple of months the latest versions of cygwin produce this error when attempting to reference a network drive. There have been a couple of other threads reporting this and talk about pat

Re: bash: cd: /cygdrive/w: Too many levels of symbolic links

On Fri, 29 Apr 2022 14:21:01 -0500 Wes Barris wrote: > For the past couple of months the latest versions of cygwin produce this > error > when attempting to reference a network drive. There have been a couple of > other > threads reporting this and talk about patches. Is there a fix coming fo

Re: Bash runs my vim slower than Cygwin's vim

On 2022-03-11, Gary Johnson wrote: > On 2022-03-11, Gary Johnson wrote: > > On 2022-03-11, Adam Dinwoodie wrote: > > > On Thu, Mar 10, 2022 at 04:55:40PM -0800, Gary Johnson wrote: > > > > > So, does anyone know why is takes so much longer for bash to run the > > > > vim I built than the official

Re: Bash runs my vim slower than Cygwin's vim

On 2022-03-11, Gary Johnson wrote: > On 2022-03-11, Adam Dinwoodie wrote: > > On Thu, Mar 10, 2022 at 04:55:40PM -0800, Gary Johnson wrote: > > > So, does anyone know why is takes so much longer for bash to run the > > > vim I built than the official Cygwin vim? More importantly, how do > > > I f

Re: Bash runs my vim slower than Cygwin's vim

On 2022-03-11, Adam Dinwoodie wrote: > On Thu, Mar 10, 2022 at 04:55:40PM -0800, Gary Johnson wrote: > > I build my own copy of Vim for the Cygwin terminal from the source > > at https://github.com/vim/vim.git. Lately, I've noticed the startup > > time getting slower, so I investigated. One of th

Re: Bash runs my vim slower than Cygwin's vim

On Thu, Mar 10, 2022 at 04:55:40PM -0800, Gary Johnson wrote: > I build my own copy of Vim for the Cygwin terminal from the source > at https://github.com/vim/vim.git. Lately, I've noticed the startup > time getting slower, so I investigated. One of the things > I discovered was this difference b

Re: bash from local mounted drive with subst command

Greetings, Claude TETE! > Hi all, > A bash in a local mounted drive, use realpath instead of mounted one > for all child processes. > Example, mount a local folder on Z: drive, go in there and run any > external command: > $ subst Z: C:\\Users > $ cd /cygdrive/z/ > $ /bin/pwd > /cygdrive/c/Users

Re: bash from local mounted drive with subst command

On Feb 21 09:40, Takashi Yano wrote: > On Mon, 21 Feb 2022 01:05:32 +0100 > Thomas Wolff wrote: > > pwd -P will also work like /bin/pwd - but: subst is more comparable to > > mount than to ln -s > > Ah, indeed, mount --bind a/b/c c in Linux does not behave > like this. > > Corinna, what do you t

Re: bash from local mounted drive with subst command

On Mon, 21 Feb 2022 01:05:32 +0100 Thomas Wolff wrote: > Am 21.02.2022 um 00:56 schrieb Takashi Yano: > > On Mon, 21 Feb 2022 08:41:52 +0900 > > Takashi Yano wrote: > >> On Sun, 20 Feb 2022 22:38:53 +0100 > >> Claude TETE wrote: > >>> A bash in a local mounted drive, use realpath instead of mounted

Re: bash from local mounted drive with subst command

Am 21.02.2022 um 00:56 schrieb Takashi Yano: On Mon, 21 Feb 2022 08:41:52 +0900 Takashi Yano wrote: On Sun, 20 Feb 2022 22:38:53 +0100 Claude TETE wrote: A bash in a local mounted drive, use realpath instead of mounted one for all child processes. Example, mount a local folder on Z: drive,

Re: bash from local mounted drive with subst command

On Mon, 21 Feb 2022 08:41:52 +0900 Takashi Yano wrote: > On Sun, 20 Feb 2022 22:38:53 +0100 > Claude TETE wrote: > > A bash in a local mounted drive, use realpath instead of mounted one > > for all child processes. > > > > Example, mount a local folder on Z: drive, go in there and run any > > exte

Re: bash from local mounted drive with subst command

On Sun, 20 Feb 2022 22:38:53 +0100 Claude TETE wrote: > A bash in a local mounted drive, use realpath instead of mounted one > for all child processes. > > Example, mount a local folder on Z: drive, go in there and run any > external command: > $ subst Z: C:\\Users > $ cd /cygdrive/z/ > $ /bin/pwd

Re: Re: bash-4.4.12-3: Building package with gcc-10.2 fails due to duplicate symbols

On Wed, 16 Dec 2020 at 18:48, Mattl Mario wrote: > > You’re right > > e.g. setting environment CFLAGS=-fcommon before executing "configure" > > then it works What are you talking about? Is this a new kind of "me too" message? Are you responding to somebody? If yes, what did they say? You really s

Re: Re: bash-4.4.12-3: Building package with gcc-10.2 fails due to duplicate symbols

You’re right e.g. setting environment CFLAGS=-fcommon before executing "configure" then it works SSI Schäfer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300 Commercial Court: Landesgericht für Zi

Re: Re: bash-4.4.12-3: Building package with gcc-10.2 fails due to duplicate symbols

Many thanks for your quick response! ... I will test it and give feedback afterwards. SSI Sch?fer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300 Commercial Court: Landesgericht f?r Zivilrechtssachen

Re: bash-4.4.12-3: Building package with gcc-10.2 fails due to duplicate symbols

From: Mattl Mario Subject: bash-4.4.12-3: Building package with gcc-10.2 fails due to duplicate symbols Date: Wed, 16 Dec 2020 16:58:25 + > With the GCC-10.2 Compiler package it's not possible to build the bash-src > package anymore. > > I firstly recognized the same issue with a bash-4.3

Re: Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities

On 2020-09-09 08:25, Eliot Moss wrote: > On 9/9/2020 12:57 AM, johnb...@email.com wrote: >> I appreciate your reply outside the scope of the cygwin alias. Sorry I am >> having issues with the alias.   I'll change to a gmail address soon because >> I'll bet that the *mail.com* server is bogusificall

Re: Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities

What are you complaining about? What erroneous behavior? We can't read your mind, but it isn't clear what you think is going wrong -- so how are we supposed to figure out what the erroneous behavior is? Please give an example of what you think is wrong and what you expected instead. Please be cl

Re: Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities

On 2020-09-08 10:22, Brian Inglis wrote: > On 2020-09-08 00:24, johnb...@email.com wrote: > You are demonstrating erroneous behaviour. What erroneous behaviour, what other utilities? You need to include your console or terminal log, or a copy and paste of (*relevant* selections of) the input and

Re: Bash 4.4.12-3 erroneous behavior using [[ -f name ]] and other utilities

On 2020-09-08 00:24, johnb...@email.com wrote: > You are demonstrating erroneous behaviour. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and pr

Re: -bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory

On 3/2/20 3:53 PM, Marco Atzeri wrote: Am 02.03.2020 um 21:17 schrieb Robert McBroom via cygwin: Details in attached file better in line next time. Are you sure that the disk J is mounted in a Administrator account ? Regards Marco USB drive Windows mounted on login. emacs shows the owner as

Re: -bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory

On Mon, Mar 2, 2020 at 11:08 PM Robert McBroom wrote: Details in attached file Hint: When asking for help in a mailing list, the less effort respondents have to go through, the better. It is better to put your information directly in the message rather than attaching a file. (Why attach a file

Re: -bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory

On 2020-03-02 23:08, Robert McBroom via cygwin wrote: > Details in attached file You most likely have Windows permissions problems, if all your tools are Cygwin. Run which on each tool to see what you are actually running, and run cygcheck to ensure they use cygwin1.dll. You need to run against

Re: -bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory

On 2020-03-02 13:17, Robert McBroom via cygwin wrote: > #!/bin/bash >cd /cygdrive/j/tri60/221-1344c_1.642 >/home/xxx/grd.sh: line 2: cd: > /cygdrive/j/tri60/221- > 1344c_1.642: No such file or directory >

Re: -bash: cd: /cygdrive/j/tri60/220-1116c_1.993: No such file or directory

Am 02.03.2020 um 21:17 schrieb Robert McBroom via cygwin: Details in attached file better in line next time. Are you sure that the disk J is mounted in a Administrator account ? Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com

Re: bash 127 errors after upgrade and other install errors

Greetings, Henry Goss! > Thanks. Thought I was going nuts. > In the case of 1) I’ll see if I can narrow down the process to reproduce. > Worst case I can do a reinstall and solve it. For empty output and sudden death of the apps, the possible cause is an injected third party library. AKA "BLOD

Re: bash 127 errors after upgrade and other install errors

PM To: cygwin@cygwin.com Cc: Henry Goss Subject: Re: bash 127 errors after upgrade and other install errors On Mon, 13 Jan 2020 04:21:58 + Henry Goss wrote: > Sure, here are the steps to reproduce either. Run on windows 10. > > RE: working installation: > 1) open setup progr

Re: bash 127 errors after upgrade and other install errors

On Mon, 13 Jan 2020 04:21:58 + Henry Goss wrote: > Sure, here are the steps to reproduce either. Run on windows 10. > > RE: working installation: > 1) open setup program. tick python3.6, python3.6 dev tools. Install. > The new installer doesn't recognize the old version of python. I don't reca

Re: bash 127 errors after upgrade and other install errors

On Mon, 13 Jan 2020 00:27:37 + Henry Goss wrote: > I seem to be getting numerous bash error code 127 errors after updating > > It seems to be happening on things like python and MySQL. The processes just > return blank > > Ex: > > Myql > #returns blank > > > > "echo $?" > > 127 > > Additi

Re: bash /cmd disagree about owner and permissions to executable

To recap, after removing excessive terminal output documentation in earlier mails: > I installed python3.8 from the "Microsoft Store". > Then I could run "python3 myscript.py" in a 'cmd' terminal but not in a > mintty/bash terminal. > The bash terminal gave "permission denied". > > Investigatin

Re: bash /cmd disagree about owner and permissions to executable

On 2019-12-29 10:24, Enrique Perez-Terron wrote: > Den 2019-12-26 22:00, skrev Andrey Repin: >> Greetings, Enrique Perez-Terron! > Thanks. > [snip] >> Problem reports:   http://cygwin.com/problems.html > See attached cygcheck.out, unaltered. > >> In particular, show "mount" output and check th

Re: bash /cmd disagree about owner and permissions to executable

Den 2019-12-26 22:00, skrev Andrey Repin: Greetings, Enrique Perez-Terron! Thanks. [snip] Problem reports: http://cygwin.com/problems.html See attached cygcheck.out, unaltered. In particular, show "mount" output and check that you don't have /etc/{passwd,group} files Heidi@panter ~ $

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 ~ >> $

Re: bash /cmd disagree about owner and permissions to executable

Greetings, Enrique Perez-Terron! > 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

Re: bash 17052

>Hi, any idea about this error: > 0 [main] bash 17052 find_fast_cwd: WARNING: Couldn't compute FAST_CWD= > pointer. Please report this problem to >the public mailing list cygwin@cygwin.com >I'm getting this all the time with different number >Regards >-Mahmoud ht

Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

On 2019-10-19 06:44, Ilʹja Šipicin wrote: > sb, 19 okt. 2019 g. v 17:32, Biswapriyo Nath: >> It seems to be issue in Travis CI. See this forum post: >> https://travis-ci.community/t/cygwin-issue-cygheap-base-mismatch-detected/5359 >> If you are in hurry you can use Appveyor CI. I'm using it without

Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

thank for another hint. I added 'get-childitem C:\cygwin64\bin' https://travis-ci.com/chipitsine/travis-cygwin/builds/132645696 gci : Cannot find path 'C:\cygwin64\bin' because it does not exist. seems, it does not exist. no point to add it to PATH there's no hurry. I want to resolve it. My i

Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

It seems to be issue in Travis CI. See this forum post: https://travis-ci.community/t/cygwin-issue-cygheap-base-mismatch-detected/5359 If you are in hurry you can use Appveyor CI. I'm using it without any issue. One has to just add `C:\cygwin64\bin` in PATH variable in YAML file. -- Problem repo

Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

btw, is there recommended way of unattended installation ? so, for example, I need certain cygwin packages installed during CI process. I decided to use chocolatey for that. Maybe there are better ways ? сб, 19 окт. 2019 г. в 14:52, Илья Шипицин : > thank for the hint > > here's output of > > po

Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

thank for the hint here's output of powershell -c '$env:PATH.Split(";") | gci' (seems there no duplicates of cygwin1.dll, no even a single dll) https://travis-ci.com/chipitsine/travis-cygwin/builds/132640664 сб, 19 окт. 2019 г. в 10:23, Brian Inglis : > On 2019-10-18 23:00, Илья Шипицин wrote

Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

On 2019-10-18 23:00, Илья Шипицин wrote: > something has changed in travis-ci (it uses windows 1803 images). > script below used to work earlier. any idea why it could happen ? > very simple script: > https://github.com/chipitsine/travis-cygwin/blob/master/.travis.yml > result: > https://travis-ci.

Re: Bash command not found in windows 8 -64 bit processor.

>*1 [main] ba FAST_CWD sh 10204 find_fast_cwd: WARNING: Couldn't compute >FAST_CWD pointer. Please report this problem to the mail.* https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.

Re: bash bug, setup, or permissions?

Hi, did you fix the issue? If do, please give me some suggestions since I encounter the same error recently. Thanks very much. -- Sent from: http://cygwin.1069669.n5.nabble.com/Cygwin-list-f3.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com

Re: bash does not recognize valid windows path: `bash: 'c:\windows\system32\cmd.exe' /c echo 123: command not found`

Greetings, Andry! > If try to replace it by: > 'c:/windows\system32\cmd.exe' /c echo 123 > Then all works fine. > I've checked it in the old 1.5.x version and seems this bug is there for ages. Strictly speaking, Cygwin programs don't have to recognize Windows paths. Although SOME of them do. B

Re: bash window start recurses

On Mon, 25 Feb 2019 at 16:31, slibbits via cygwin <> wrote: > > Win 7-64 > > I just installed cygwin on a laptop.When i start a bash shell cygwin > seems to do a recursive start of bash shells. I've gotten as many as 400 > shells started with a single start. > > I don't know how to debug this or fi

Re: bash string-operator problem

On 2/21/2019 3:17 PM, Lee wrote: 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 $ cat /tmp/x #!/bin/bash A="A" B="A" if [ $A == $B ]; then echo "identical" fi i

Re: bash string-operator problem

On 2/21/19 2:17 PM, Lee wrote: >> >> 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? Use of [ ... == ... ] is a bash extension. It works in bash, but is not portable

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!=$

Re: bash string-operator problem

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

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 identica

Re: bash string-operator problem

On 2/21/19 10:00 AM, 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 > echo -e "not identical" > fi > if [ $A==$B ]; then >

Re: Bash heredoc on FD 3

On Jan 8 16:17, Steven Penny wrote: > On Tue, 8 Jan 2019 22:05:34, Corinna Vinschen wrote: > > I added some changes to make this work in older systems as well. > > I uploaded new snapshots to //cygwin.com/snapshots/ > > > > Please try. > > Confirmed fixed. > > Note I only retested with Windows

Re: Bash heredoc on FD 3

On Tue, 8 Jan 2019 22:05:34, Corinna Vinschen wrote: I added some changes to make this work in older systems as well. I uploaded new snapshots to //cygwin.com/snapshots/ Please try. Confirmed fixed. Note I only retested with Windows 7 this time, but I think we’re good. Thank you! -- Proble

Re: Bash heredoc on FD 3

On Jan 8 12:27, Corinna Vinschen wrote: > On Jan 7 16:19, Steven Penny wrote: > > On Mon, 7 Jan 2019 20:03:13, Corinna Vinschen wrote: > > > I can't reproduce this with my latest code. It works fine for me > > > every time, independently of POSIXLY_CORRECT. > > > > > > I uploaded new snapshots

Re: Bash heredoc on FD 3

On Jan 7 16:19, Steven Penny wrote: > On Mon, 7 Jan 2019 20:03:13, Corinna Vinschen wrote: > > I can't reproduce this with my latest code. It works fine for me > > every time, independently of POSIXLY_CORRECT. > > > > I uploaded new snapshots to https://cygwin.com/snapshots/ with all > > the lat

Re: Bash heredoc on FD 3

On Mon, 7 Jan 2019 20:03:13, Corinna Vinschen wrote: I can't reproduce this with my latest code. It works fine for me every time, independently of POSIXLY_CORRECT. I uploaded new snapshots to https://cygwin.com/snapshots/ with all the latest changes. Please try again. I retested with cygwin1

Re: Bash heredoc on FD 3

On Jan 7 10:28, Steven Penny wrote: > On Sun, 6 Jan 2019 21:18:52, Corinna Vinschen wrote: > > This should work in the latest developer snapshot uploaded to > > https://cygwin.com/snapshots/ Please give it a try. > > Hm interesting: > >$ uname -a >CYGWIN_NT-6.1 Steven-PC 2.12.0s(0.330/5

Re: Bash heredoc on FD 3

On Sun, 6 Jan 2019 21:18:52, Corinna Vinschen wrote: This should work in the latest developer snapshot uploaded to https://cygwin.com/snapshots/ Please give it a try. Hm interesting: $ uname -a CYGWIN_NT-6.1 Steven-PC 2.12.0s(0.330/5/3) 2019-01-06 19:42 x86_64 Cygwin $ dash hello.sh

Re: Bash heredoc on FD 3

On Dec 2 10:43, Steven Penny wrote: > Using this file: > >$ cat hello.sh >awk -f /dev/fd/3 3 print "hello world" >} >eof > > it runs as expected with Dash: > >$ dash hello.sh >hello world > > However it fails with Bash: > >$ bash hello.sh >aw

Re: Bash heredoc on FD 3

On Tue, 4 Dec 2018 09:21:55, cyg Simple wrote: > Dash is faster in processing the data but can be made to fail if you > add -d to the ls commands you're using. ? Oh, I believe you refer to: https://cygwin.com/ml/cygwin/2018-12/msg00035.html ( Re: Bash heredoc on FD 3 ) &

Re: Bash heredoc on FD 3

On 12/4/2018 7:13 AM, Houder wrote: On Sun, 02 Dec 2018 10:43:17, Steven Penny wrote: Using this file: $ cat hello.sh awk -f /dev/fd/3 3< File to which symlnk /dev/fd/3 refers has "gone"; different from Linux, where the file is "deleted", but still "available". (note: dash uses a di

Re: Bash heredoc on FD 3

On Sun, 02 Dec 2018 10:43:17, Steven Penny wrote: > Using this file: > > $ cat hello.sh > awk -f /dev/fd/3 3< BEGIN { > print "hello world" > } > eof > > it runs as expected with Dash: > > $ dash hello.sh > hello world > > However it fails with Bash: > >

Re: Bash heredoc on FD 3

On 12/3/2018 10:43 AM, cyg Simple wrote: Same for me and interestingly: $ ls -ld /dev/fd/* ls: cannot access '/dev/fd/3': No such file or directory ls: cannot access '/dev/fd/31': No such file or directory lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:39 /dev/fd/0 -> /dev/pty2 lrwxrwxrwx 1 eboyd53 e

Re: Bash heredoc on FD 3

On 12/3/2018 10:43 AM, cyg Simple wrote: On 12/2/2018 1:43 PM, Steven Penny wrote: Using this file:     $ cat hello.sh     awk -f /dev/fd/3 3<    awk: fatal: can't open source file `/dev/fd/3' for reading (No such file or     directory) I tried also with Debian and both Dash and Bash work a

Re: Bash heredoc on FD 3

On 12/2/2018 1:43 PM, Steven Penny wrote: Using this file:    $ cat hello.sh    awk -f /dev/fd/3 3<    awk: fatal: can't open source file `/dev/fd/3' for reading (No such file or    directory) I tried also with Debian and both Dash and Bash work as expected. What is causing Cygwin Bash t

Re: BASH 4.4 mapfile/readarray/read builtins mis-behaving with pipe [edit] documentation bug

On 2018-07-21 18:37, Steven Penny wrote: > On Sat, 21 Jul 2018 19:36:38, BloomingAzaleas wrote: >> At this time, I do not have a Linux image available to me. > its not that hard to get: > 1. http://virtualbox.org > 2. http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid Even easier to

Re: BASH 4.4 mapfile/readarray/read builtins mis-behaving with pipe [edit] documentation bug

On Sat, 21 Jul 2018 19:36:38, BloomingAzaleas wrote: At this time, I do not have a Linux image available to me. its not that hard to get: 1. http://virtualbox.org 2. http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid you saw the same behavior on Fedora, then I suggest the beha

Re: BASH 4.4 mapfile/readarray/read builtins mis-behaving with pipe [edit] documentation bug

Reply to Eric Blake, At this time, I do not have a Linux image available to me.   If you saw the same behavior on Fedora, then I suggest the behavior originates upstream at or close the the GNU source-code level. Mr. Penny's response asserted the observed behavior "is intended behavior", in

Re: BASH 4.4 mapfile/readarray/read builtins mis-behaving with pipe [edit] documentation bug

On 07/17/2018 08:52 PM, BloomingAzaleas wrote: Reply to Steven Penny :    no mis-behaving: this is intended behavior - you yourself have given    workarounds: either redirect output to a file that can be later read, or pipe to    command grouping ala {} or () and read stdin from inside the

Re: BASH 4.4 mapfile/readarray/read builtins mis-behaving with pipe [edit] documentation bug

Reply to Steven Penny : no mis-behaving: this is intended behavior - you yourself have given workarounds: either redirect output to a file that can be later read, or pipe to command grouping ala {} or () and read stdin from inside the subshell im not sure what you are asking here -

Re: BASH 4.4 mapfile/readarray/read builtins mis-behaving with pipe

On Sun, 15 Jul 2018 19:01:21, BloomingAzaleas wrote: CASE: echo multi-line_arg | read foo cat multi-line_unix_fmt_file | read foo =C2=A0RESULT: Fail with variable foo null or unset CASES: left chev re-directions mapfile < some_unix_fmt_file mapfile < no mis-behaving: this is intended behavior

Re: Bash tab completion for batch files

Yeah, all the permissions are 644 on the batch files. In my particular case, the folder in question is a VMware shared folder from my host with a symbolic link under Windows to a project folder under the C: drive. I tried changing the permissions to 755 on my Mac host but they persist as 644 und

Re: Bash tab completion for batch files

On 1/21/2018 4:35 AM, Grant Lewis wrote: I’m running latest Cygwin under a Windows 10 VM. Tab completion for batch files is not functioning. I have the bash-completion package installed. Batch file completion does work under the zsh. Is there anything I can do to get it working under the bash

Re: bash pipe race condition

On 10/3/2017 11:39 PM, Kaz Kylheku wrote: > On 03.10.2017 05:56, cyg Simple wrote: >> On 10/2/2017 9:06 PM, Matthew McGIllis wrote: >>> If I use the same code from bash I get: >>> >>> $ ./input.exe | ./simple.exe >>> line1 >>> <—— Hangs indefinitely until you kill it or ctrl-c >>> >>> Some how if i

Re: bash pipe race condition

On 03.10.2017 05:56, cyg Simple wrote: On 10/2/2017 9:06 PM, Matthew McGIllis wrote: If I use the same code from bash I get: $ ./input.exe | ./simple.exe line1 <—— Hangs indefinitely until you kill it or ctrl-c Some how if input has a delay between its line output then things will get hung, i

Re: bash pipe race condition

On 10/2/2017 9:06 PM, Matthew McGIllis wrote: > > If I use the same code from bash I get: > > $ ./input.exe | ./simple.exe > line1 > <—— Hangs indefinitely until you kill it or ctrl-c > > Some how if input has a delay between its line output then things will get > hung, if you remove the sleep

Re: bash command substitution

Hello, it was compiled with mingw, and the \r was the issue, thanks! --- Köszönettel: Vukovics Mihály On 2017-10-01 19:54, Brian Inglis wrote: On 2017-10-01 00:40, Vukovics Mihaly wrote: I just wanted to use my bash script written in Debian 8 in cygwin(latest, win10 64bit), but does not work

Re: bash command substitution

On 2017-10-01 00:40, Vukovics Mihaly wrote: > I just wanted to use my bash script written in Debian 8 in cygwin(latest, > win10 > 64bit), but does not work. > At a specific line there is a command substitution trying to get result from > ffprobe: > VHEIGHT=$(ffprobe -v error -show_entries stream=w

Re: bash command substitution

Try the following: echo $(echo hello | cat) If that remains empty, (it should of course result in 'hello') you're suffering from the same problem I have. And no, I did not get it resolved. In which case I'd be elated if you could get anyone interested in finding a solution! If this happens to yo

Re: bash command substitution

On Sun, 1 Oct 2017 08:40:51, Vukovics Mihaly wrote: VHEIGHT=$(ffprobe -v error -show_entries stream=width,height -of default=noprint_wrappers=1 ${OLDFILE} | grep "height" | cut -f2 -d'=') For debugging purpose the same command is executed without putting the result into a variable, and works!

Re: bash command substitution

On 01/10/2017 08:40, Vukovics Mihaly wrote: Hello All, I just wanted to use my bash script written in Debian 8 in cygwin(latest, win10 64bit), but does not work. At a specific line there is a command substitution trying to get result from ffprobe: VHEIGHT=$(ffprobe -v error -show_entries st

Re: Bash monitor mode remains enabled if disabled in .bashrc

o .bashrc to be doubly sure - it displays as expected > >> -Original Message- >> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On >> Behalf Of cyg Simple >> Sent: August-31-17 8:31 AM >> To: cygwin@cygwin.com >> Subject: Re: Bash monito

Re: Bash monitor mode remains enabled if disabled in .bashrc

On 8/30/2017 7:26 PM, Michel LaBarre wrote: > Playing with set -m/+m and shopt -s lastpipe, in an interactive bash shell, > I came across a situation > which is minor unless it has broader implications for others that I do not > know about. > > Specifically if "set +m" is present in .bashrc, it

  1   2   3   4   5   6   7   8   9   10   >