Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

Am 23.03.2020 um 19:34 schrieb Jay Libove via Cygwin: Hi Andrey, (I have no idea what you mean about "top posting".) https://lmgtfy.com/?q=top+posting+vs+bottom+posting -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:

Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

Greetings, Jay Libove! > Hi Andrey, > (I have no idea what you mean about "top posting".) https://cygwin.com/acronyms/#TOFU > `locale` gives the same in CMD as in bash, on this machine as on another > machine on my network where I also checked, which also exhibits the s

RE: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

Hi Andrey, (I have no idea what you mean about "top posting".) `locale` gives the same in CMD as in bash, on this machine as on another machine on my network where I also checked, which also exhibits the same globbing problem under Windows CMD: LANG= LC_CTYPE="C.UTF-8"

Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

Greetings, Jay Libove! Please no top posting in this mailing list. > Good suggestion, deleting files one by one. It's not just one file, but it > does seem to have something to do with some file name patterns. > I think I've got it. It's accented characters. > I live in Spain. Spanish has

Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

e.g. "ls: cannot access '*.pdf': No > such file or directory" in Windows CMD shell, but works okay in bash > > Have you tried deleting files one by one, to see if the issue is related to a > single file (sorry if this is an obvious suggestion that you've already > tried).

RE: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

ubject: Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash Have you tried deleting files one by one, to see if the issue is related to a single file (sorry if this is an obvious suggestion that you've alread

Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

Have you tried deleting files one by one, to see if the issue is related to a single file (sorry if this is an obvious suggestion that you've already tried). In Cygwin bash, it's the shell that glob-expands wildcards before calling your program (e.g. ls), and in find, it's the find code that does

RE: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

r Windows CMD vs. when fully within the Cygwin environment (under bash where of course bash is doing the shell expansion, and ls or other Cygwin commands don't have to). Does any of this help pinpoint the problem further? thanks again, -Jay -Original Message- From: Paul Moore Sent:

Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

On Sun, 22 Mar 2020 at 19:11, Marco Atzeri via Cygwin wrote: > any reason for NOT using a cygwin shell ? Many reasons. But that's not relevant to this thread, is it? (Note: I'm not the OP, just an interested contributor to the thread). I'm happy to elaborate if you want, but I suggest we do it

Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

:XX {Any many other .pdf files} Yet: C:> ls *.pdf ls: cannot access '*.pdf': No such file or directory And: C:> bash user@hostname /cygdrive/C/Temp/test $ ls *.pdf A.pdf B.pdf {etc} And, not ALL of the *.pdf files in the particular directory where I've encountered this trigger the prob

Re: shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

{Any many other .pdf files} > > Yet: > > C:> ls *.pdf > ls: cannot access '*.pdf': No such file or directory > > And: > C:> bash > user@hostname /cygdrive/C/Temp/test > $ ls *.pdf > A.pdf > B.pdf > {etc} > > And, not ALL of the *.pdf files in th

shell expansion produces e.g. "ls: cannot access '*.pdf': No such file or directory" in Windows CMD shell, but works okay in bash

pdf ls: cannot access '*.pdf': No such file or directory And: C:> bash user@hostname /cygdrive/C/Temp/test $ ls *.pdf A.pdf B.pdf {etc} And, not ALL of the *.pdf files in the particular directory where I've encountered this trigger the problem... C:> ls N*.pdf N.pdf C:> ls A*.pdf ls: cannot

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

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

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

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

Details in attached file Strange problem cropping up. I chain scripts with command sequences for long running numerical calculations executed from the initial mintty terminal. Running from a non administrative session. The form is --- #!/bin/bash cd /cygdrive/j/tri60/221-1344c_1.933 mcnp62

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 fi

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:

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

Details in attached file Strange problem cropping up. I chain scripts with command sequences for long running numerical calculations executed from the initial mintty terminal. Running from a non administrative session. The form is --- #!/bin/bash cd /cygdrive/j/tri60/221-1344c_1.933 mcnp62

Re: 1 [main] bash 3048 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to

>1 [main] bash 3048 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointe= >r. Please report this problem to the public mailing list cygwin@cygwin.com= ><mailto:cygwin@cygwin.com> >Cygwin wurde neu installiert. https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-wa

1 [main] bash 3048 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to

1 [main] bash 3048 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com<mailto:cygwin@cygwin.com> Cygwin wurde neu installiert. -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: [BUG]: 3.1.4: cmd -> bash -> mintty yields Windows exception

On 2/21/2020 10:33 AM, Hans-Bernhard Bröker wrote: > Am 21.02.2020 um 18:22 schrieb David Rothenberger: >> With cygwin 3.1.4, I get an "exception c005" when I perform the >> following actions: >> >> 1. Use the Windows run box to start a cmd shell &g

Re: [BUG]: 3.1.4: cmd -> bash -> mintty yields Windows exception

On Fri, 21 Feb 2020 09:22:15 -0800 David Rothenberger wrote: > With cygwin 3.1.4, I get an "exception c005" when I perform the > following actions: > > 1. Use the Windows run box to start a cmd shell > 2. From there, run "bash". (I'm sure it is the Cygwin

Re: [BUG]: 3.1.4: cmd -> bash -> mintty yields Windows exception

Am 21.02.2020 um 18:22 schrieb David Rothenberger: With cygwin 3.1.4, I get an "exception c005" when I perform the following actions: 1. Use the Windows run box to start a cmd shell 2. From there, run "bash". (I'm sure it is the Cygwin bash.) How did you make sure

Re: [BUG]: 3.1.4: cmd -> bash -> mintty yields Windows exception

Am 21.02.2020 um 18:22 schrieb David Rothenberger: With cygwin 3.1.4, I get an "exception c005" when I perform the following actions: 1. Use the Windows run box to start a cmd shell 2. From there, run "bash". (I'm sure it is the Cygwin bash.) 3. From there, run "

Re: CPU hogging by dysfunctional bash or zsh when started via mintty Cygwin terminal link

Am 14.02.20 um 03:39 schrieb Ken Brown: > > Your strace output shows that sysfer.dll is loaded.  This is apparently > a component of Symantec Endpoint Protection.  Could the latter be > interfering with Cygwin?  See > >   https://cygwin.com/faq/faq.html#faq.using.bloda Just booted the Windows

Re: CPU hogging by dysfunctional bash or zsh when started via mintty Cygwin terminal link

h now fails. It results in an empty window with a blinking cursor and a bash process with 100% CPU load. The box is a Windows 10 VM and also runs an cygwin openssh server, which I normally use for development. SSH still works fine. I also installed gdb and tried to attach to the CPU hogging bash,

CPU hogging by dysfunctional bash or zsh when started via mintty Cygwin terminal link

indow with a blinking cursor and a bash process with 100% CPU load. The box is a Windows 10 VM and also runs an cygwin openssh server, which I normally use for development. SSH still works fine. I also installed gdb and tried to attach to the CPU hogging bash, but I never see a gdb prompt just some gdb startup o

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

Re: bash 127 errors after upgrade and other install errors

:21 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

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

bash 127 errors after upgrade and other install errors

Hello, 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 Additionally, old software I've been using for a whil

Re: another question about cygwin bash trying to make connections

On 2020-01-07 16:02, LMH wrote: > Marco Atzeri wrote: >> Am 07.01.2020 um 21:58 schrieb LMH: >>> This is the version of bash, >>> >>> GNU bash, version 4.3.42(4)-release (i686-pc-cygwin) >>> >>> it would be very helpful as a first

Re: another question about cygwin bash trying to make connections

Marco Atzeri wrote: > Am 07.01.2020 um 21:58 schrieb LMH: >> Hello, >> >> >> This is the version of bash, >> >> GNU bash, version 4.3.42(4)-release (i686-pc-cygwin) >> >> it would be very helpful as a first step if I could find a verifie

Re: another question about cygwin bash trying to make connections

Am 07.01.2020 um 21:58 schrieb LMH: Hello, This is the version of bash, GNU bash, version 4.3.42(4)-release (i686-pc-cygwin) it would be very helpful as a first step if I could find a verified digital signature for this version of bash. The index here, https://ftp.gnu.org/gnu/bash/ gives

another question about cygwin bash trying to make connections

Hello, Every single time run bash in a terminal, I get the following firewall alerts, C:\cygwin\bin\bash.exe An attempt to communicate a foreign process has been detected. Target PID: 1616 Image Name: svchost.exe C:\cygwin\bin\bash.exe A potential threat to network traffic interception

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

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

pps/python3.8.exe > -rwxr-x---  1 Unknown+User Unknown+Group  0 des 26 19:25  > /cygdrive/c/Users/Heidi/AppData/Local/Microsoft/WindowsApps/PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0/python3.8.exe > > > So here is finally a file with a positive byte count. > &g

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

SYSTEM] drwxrwx---+ 1 SYSTEM SYSTEM 0 des 26 19:25 PythonSoftwareFoundation.Python.3.8_3.8.496.0_x64__qbz5n2kfra8p0/ [snip] Yet it does not work to run python in the elevated bash. This python was installed using Microsoft Store. I will probably have to rever

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

>> 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)" >> -

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

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

bash /cmd disagree about owner and permissions to executable

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

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<mailto:cygwin@cygwin.com> I'm getting this all the time with different number Regards -Mahmoud -- P

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<mailto:cygwin@cygwin.com> >I'm getting this all the time with different numbe

BUG: bashdb-3.1_0.09-1 is obsolete; pkg bashdb w/bash?

cygcheck -p bashdb Found 2 matches for bashdb bashdb-3.1_0.09-1-src - bashdb-src: Debugger for bash scripts (source) bashdb-3.1_0.09-1 - bashdb: debugger for bash scripts (installed binaries and support files) Current version of bash on Cygwin download site is bash-4.4.12-3 So for bashdb

Problem in Cygwin program offering: Bashdb is for Bash 3.1.9; Bash is at 4.4.12 (or 5.x).

Bashdb doesn't work very well (many things don't work) on Cygwin, -- figured out that Bashdb is from 2012, while bash is from 2017. If bashdb was upgraded to a compatible version it might run a bit better. Table from page @ https://sourceforge.net/projects/bashdb/files/bashdb/5.0-1.1.1

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

add it to PATH > there's no hurry. I want to resolve it. My issue is the same as > described on forum - builds used to work and accidentally stopped > working (with the same error) If you read the problem report, the issue is that the Travis provided Git-for-Windows AKA Git-Bash AKA MSYS2/

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

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

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

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, Илья Шипицин

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: >

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

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.com/chipitsine/travis-cygwin/builds/132624829

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:

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.* -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe

Re: Can't debug bash with gdb 8.2.1-1

On 24/07/2019 15:42, Ken Brown wrote: On 7/24/2019 10:32 AM, Ken Brown wrote: On 7/24/2019 8:33 AM, Ken Brown wrote: $ cat getpgrp_test.c #include #include #include int main () { pid_t pid = getpid (); pid_t pgid = getpgid (0); printf ("getpid () = %d, getpgid (0) = %d,

Re: Can't debug bash with gdb 8.2.1-1

On 7/24/2019 10:32 AM, Ken Brown wrote: > On 7/24/2019 8:33 AM, Ken Brown wrote: >> $ cat getpgrp_test.c >> #include >> #include >> #include >> >> int >> main () >> { >> pid_t pid = getpid (); >> pid_t pgid = getpgid (0); >> printf ("getpid () = %d, getpgid (0) = %d, errno =

Re: Can't debug bash with gdb 8.2.1-1

On 7/24/2019 8:33 AM, Ken Brown wrote: > $ cat getpgrp_test.c > #include > #include > #include > > int > main () > { > pid_t pid = getpid (); > pid_t pgid = getpgid (0); > printf ("getpid () = %d, getpgid (0) = %d, errno = %d\n", pid, pgid, > errno); > } > > $ gcc -o getpgrp_test

Re: Can't debug bash with gdb 8.2.1-1

On 7/23/2019 2:02 PM, Jon Turney wrote: > Hmm let me clarify what I mean: > > $ cat getpgrp_test.c > #include > #include > > int main() { >   printf("getpgrp() = %d\n", getpgrp()); > } > > $ gcc getpgrp_test.c -o getpgrp_test.exe > > $ ./getpgrp_test > getpgrp() = 1241 > > > $ gdb

Re: Can't debug bash with gdb 8.2.1-1

On 23/07/2019 16:42, Ken Brown wrote: On 7/23/2019 9:51 AM, Jon Turney wrote: On 22/07/2019 15:59, Ken Brown wrote: With the test version of gdb, attempting to debug bash fails as follows: $ gdb bash GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1 [...] Reading symbols from bash...Reading symbols from

Re: Can't debug bash with gdb 8.2.1-1

On 7/23/2019 9:51 AM, Jon Turney wrote: > On 22/07/2019 15:59, Ken Brown wrote: >> With the test version of gdb, attempting to debug bash fails as follows: >> >> $ gdb bash >> GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1 >> [...] >> Reading symbols from bash...Read

Re: Can't debug bash with gdb 8.2.1-1

On 22/07/2019 15:59, Ken Brown wrote: With the test version of gdb, attempting to debug bash fails as follows: $ gdb bash GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1 [...] Reading symbols from bash...Reading symbols from /usr/lib/debug//usr/bin/bash.exe.dbg...done. done. (gdb) r -c ls Starting program

Can't debug bash with gdb 8.2.1-1

With the test version of gdb, attempting to debug bash fails as follows: $ gdb bash GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1 [...] Reading symbols from bash...Reading symbols from /usr/lib/debug//usr/bin/bash.exe.dbg...done. done. (gdb) r -c ls Starting program: /usr/bin/bash -c ls [...] /usr/bin

Re: main bash 10064 find_fast_cwd: is not running fast

Am 05.07.2019 um 12:10 schrieb Muzhgan Athaee: please correct it and tell me what is the problem. Kind regards Muzhgan Athaee May be you need to be a bit more descriptive of how to replicate your problem and which is your platform. please follow the guideline:

main bash 10064 find_fast_cwd: is not running fast

please correct it and tell me what is the problem. Kind regards Muzhgan Athaee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info:

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:

Re: Cygwin bash script removing equal sign

Am 25.04.2019 um 18:11 schrieb Peter Palaparthy: > Cygwin bash script is removing equals sign from command call. On what basis did you conclude it was bash doing that, and not, say, make? > *Here is the relevant command in my makefile.* > *$(elabcmd) = $(XELAB_DEFAULT) \-generic VERSI

Re: Cygwin bash script removing equal sign

On 4/25/2019 12:11 PM, Peter Palaparthy wrote: Cygwin bash script is removing equals sign from command call. How do I escape it so that = is sent to command? I tried different things like escaping = with \ and enclosing it with "" and '' but none of them worked. *Here is the releva

Cygwin bash script removing equal sign

Cygwin bash script is removing equals sign from command call. How do I escape it so that = is sent to command? I tried different things like escaping = with \ and enclosing it with "" and '' but none of them worked. *Here is the relevant command in my makefile.* *$(elabcmd) = $(XEL

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.

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

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. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:

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. >

bash window start recurses

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 find out what I did wrong. I currently have cygwin installed on two

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

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

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) >>

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

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

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 >

bash string-operator problem

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 echo -e "identical&qu

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

Re: Bash heredoc on FD 3

> > > > I uploaded new snapshots to https://cygwin.com/snapshots/ with all > > > the latest changes. Please try again. > > > > I retested with cygwin1-20190107.dll.xz. My results below. Note that > > "success" > > means that with Bash,

Re: Bash heredoc on FD 3

win.com/snapshots/ with all > > the latest changes. Please try again. > > I retested with cygwin1-20190107.dll.xz. My results below. Note that "success" > means that with Bash, the script runs without error, regardless of > "POSIXLY_CORRECT" variable as you said. &qu

Re: Bash heredoc on FD 3

with cygwin1-20190107.dll.xz. My results below. Note that "success" means that with Bash, the script runs without error, regardless of "POSIXLY_CORRECT" variable as you said. "failure" is to mean that with Bash, running with "POSIXLY_CORRECT" produces this error: awk

Re: Bash heredoc on FD 3

NT-6.1 Steven-PC 2.12.0s(0.330/5/3) 2019-01-06 19:42 x86_64 Cygwin > >$ dash hello.sh >hello world > >$ bash hello.sh >awk: error: can't open source file `/dev/fd/3' for reading (Permission >denied) > >$ unset POSIXLY_CORRECT >$ bash hell

Re: Bash heredoc on FD 3

hello.sh hello world $ bash hello.sh awk: error: can't open source file `/dev/fd/3' for reading (Permission denied) $ unset POSIXLY_CORRECT $ bash hello.sh hello world -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq

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<BEGIN { > print "hello world" >} >eof > > it runs as expected with Dash: > >$ dash hello.sh >hello world > &

RE: 2 [main] bash 13792 find_fast_cwd: WARNING

Thank you, an unbelievably quick response excellent English Regards Dave -Original Message- From: Andrey Repin [mailto:anrdae...@yandex.ru] Sent: 23 December 2018 22:51 To: Dave Barker; cygwin@cygwin.com Subject: Re: 2 [main] bash 13792 find_fast_cwd: WARNING Greetings, Dave Barker

Re: 2 [main] bash 13792 find_fast_cwd: WARNING

Greetings, Dave Barker! > Hi, I'm trying to unbrick a Samsung Galaxy Ace S5830I and received > this message > > 2 [main] bash 13792 find_fast_cwd: WARNING: Couldn't compute FAST_CWD > pointer. Please report this problem to > the public mailing list cygwin@cygwin.co

2 [main] bash 13792 find_fast_cwd: WARNING

Hi, I'm trying to unbrick a Samsung Galaxy Ace S5830I and received this message 2 [main] bash 13792 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com Any help would be appreciated Dave

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 ) > S

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

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 >

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

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 w

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 B

Bash heredoc on FD 3

Using this file: $ cat hello.sh awk -f /dev/fd/3 3

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

<    1   2   3   4   5   6   7   8   9   10   >