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 ) > So in Bash the process is no longer available. Adding -d to the above: > > $ dash -c '/bin/ls -ld /dev/fd/*' > /bin/ls: cannot access '/dev/fd/3': No such file or directory > lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:50 /dev/fd/0 -> /dev/pty2 > lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:50 /dev/fd/1 -> /dev/pty2 > lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec 3 10:50 /dev/fd/2 -> /dev/pty2 uhm, the facts are slightly different ... /dev/fd is, well, a "moving target", it is symlnk to /proc/self/fd. self refers to the "current process" ... it changes each time. /proc/self/fd shows the open fd's of the current process ... Currently, I am on Linux (Fedora) ... @@ # currently I am executing the shell (bash) @@ # self points to the procid of my bash ... @@ printf "%s\n" /dev/fd/* /dev/fd/0 /dev/fd/1 /dev/fd/10 /dev/fd/11 /dev/fd/2 /dev/fd/255 /dev/fd/3 @@ # however ls has NO open fd 3 if I invoke it like this: @@ # (self points to the procid of my ls command) @@ ls -ld /dev/fd/* # /dev/fd/* expands to the list above (bash) ls: cannot access '/dev/fd/255': No such file or directory ls: cannot access '/dev/fd/3': No such file or directory lrwx-- 1 henri henri 64 Dec 5 07:26 /dev/fd/0 -> /dev/pts/0 lrwx-- 1 henri henri 64 Dec 5 07:26 /dev/fd/1 -> /dev/pts/0 lrwx-- 1 henri henri 64 Dec 5 07:26 /dev/fd/10 -> /dev/dri/card0 lrwx-- 1 henri henri 64 Dec 5 07:26 /dev/fd/11 -> /dev/dri/card0 lrwx-- 1 henri henri 64 Dec 5 07:26 /dev/fd/2 -> /dev/pts/0 @@ # ls HAS an open fd 3 if I invoke it like this: @@ (# use strace to see it happen -- ls opens the directory) @@ ls -lL /dev/fd # /dev/fd refers to /proc/self/fd total 0 crw--- 1 henri tty 136, 0 Dec 5 07:38 0 crw--- 1 henri tty 136, 0 Dec 5 07:38 1 crw-rw+ 1 root video 226, 0 Dec 5 07:01 10 crw-rw+ 1 root video 226, 0 Dec 5 07:01 11 crw--- 1 henri tty 136, 0 Dec 5 07:38 2 dr-x-- 2 henri henri 0 Dec 5 07:38 3 @@ ls -l /proc/self/fd total 0 lrwx-- 1 henri henri 64 Dec 5 07:38 0 -> /dev/pts/0 lrwx-- 1 henri henri 64 Dec 5 07:38 1 -> /dev/pts/0 lrwx-- 1 henri henri 64 Dec 5 07:38 10 -> /dev/dri/card0 lrwx-- 1 henri henri 64 Dec 5 07:38 11 -> /dev/dri/card0 lrwx-- 1 henri henri 64 Dec 5 07:38 2 -> /dev/pts/0 lr-x-- 1 henri henri 64 Dec 5 07:38 3 -> /proc/2605/fd Same w/ dash: @@ dash $ printf "%s\n" /dev/fd/* /dev/fd/0 /dev/fd/1 /dev/fd/10 /dev/fd/11 /dev/fd/12 /dev/fd/17 /dev/fd/18 /dev/fd/2 /dev/fd/3 /dev/fd/55 $ ls -ld /dev/fd/* ls: cannot access '/dev/fd/12': No such file or directory ls: cannot access '/dev/fd/3': No such file or directory lrwx-- 1 henri henri 64 Dec 5 07:25 /dev/fd/0 -> /dev/pts/3 lrwx-- 1 henri henri 64 Dec 5 07:25 /dev/fd/1 -> /dev/pts/3 lrwx-- 1 henri henri 64 Dec 5 07:25 /dev/fd/10 -> /dev/dri/card0 lrwx-- 1 henri henri 64 Dec 5 07:25 /dev/fd/11 -> /dev/dri/card0 lrwx-- 1 henri henri 64 Dec 5 07:25 /dev/fd/17 -> /dev/dri/card0 lrwx-- 1 henri henri 64 Dec 5 07:25 /dev/fd/18 -> /dev/dri/card0 lrwx-- 1 henri henri 64 Dec 5 07:25 /dev/fd/2 -> /dev/pts/3 lr-x-- 1 henri henri 64 Dec 5 07:25 /dev/fd/55 -> /home/b/henri/.local/share/baloo/index = -- 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
Upgrade postgresql-10.5-1 to 10.6?
Hello, Is there any plan to provide an update for postgresql version 10.5-1 to version 10.6? Going to the next major version (11.1-1) is not an option for our environment. Thanks, Bob Robert C. Stevenson Northrop Grumman Mission Systems Senior Staff Software Engineer 610-260-4269 -- 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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux
On 12/4/2018 3:52 PM, Marco Atzeri wrote: Am 04.12.2018 um 21:41 schrieb David Karr: "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)" I installed a version of "kubectl" for windows, and I use it extensively in Cygwin bash for scripting command-line automation. In general, this works perfectly fine. I even use the same scripting in a Linux VM. I'm seeing an issue with one script that works fine in the Linux VM, but not in Cygwin. The command line is approximately this: kubectl exec pod -c container -i -t -- grep "string" stuff.properties 2>&1 | sed -e 's/^propname=//' In Linux, this works perfectly fine. In Cygwin, it says "stdout is not a tty". I haven't updated my local Cygwin installation for quite a while. I'd prefer not to, unless there is a strong chance this kind of thing would be fixed. as kubectl is not a Cygwin program, it is not aware of cygwin pty. You can try to use winpty to overcome the problem. https://github.com/rprichard/winpty Or grab the source and try to build a Cygwin version. Looks like there are a number of dependencies though but primarily golang. -- cyg 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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux
Am 04.12.2018 um 21:41 schrieb David Karr: "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)" I installed a version of "kubectl" for windows, and I use it extensively in Cygwin bash for scripting command-line automation. In general, this works perfectly fine. I even use the same scripting in a Linux VM. I'm seeing an issue with one script that works fine in the Linux VM, but not in Cygwin. The command line is approximately this: kubectl exec pod -c container -i -t -- grep "string" stuff.properties 2>&1 | sed -e 's/^propname=//' In Linux, this works perfectly fine. In Cygwin, it says "stdout is not a tty". I haven't updated my local Cygwin installation for quite a while. I'd prefer not to, unless there is a strong chance this kind of thing would be fixed. as kubectl is not a Cygwin program, it is not aware of cygwin pty. You can try to use winpty to overcome the problem. https://github.com/rprichard/winpty --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- 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
Redirecting stderr to stdout through pipe doesn't work the way it does in Linux
"CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)" I installed a version of "kubectl" for windows, and I use it extensively in Cygwin bash for scripting command-line automation. In general, this works perfectly fine. I even use the same scripting in a Linux VM. I'm seeing an issue with one script that works fine in the Linux VM, but not in Cygwin. The command line is approximately this: kubectl exec pod -c container -i -t -- grep "string" stuff.properties 2>&1 | sed -e 's/^propname=//' In Linux, this works perfectly fine. In Cygwin, it says "stdout is not a tty". I haven't updated my local Cygwin installation for quite a while. I'd prefer not to, unless there is a strong chance this kind of thing would be fixed. -- 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: [ITP] libmspack 0.9
Am 04.12.2018 um 12:07 schrieb Stuart Caie: libmspack is a portable library for some loosely related Microsoft compression formats. It is the library that powers cabextract. I'm the author of both and the current Cygwin maintainer of cabextract, but not libmspack. With the most recent cabextract/libmspack releases, I prepared and uploaded new versions of both cabextract and libmspack, but only my cabextract release was accepted. I wrote to the current maintaner, Yaakov Selkowitz, and he let me know I need to formally ITA libmspack. He gives his permission, pending review. Yaakov has been using https://github.com/cygwinports/libmspack I will be using https://github.com/kyz/libmspack/blob/master/libmspack/libmspack.cygport - no patch needed, it's now in the main source - no custom src_test() needed, libmspack now has a standard "make check" testsuite Regards Stuart Hi Stuart, it builds fine and passes the test, however you should change from libmspack0_CONTENTS="usr/bin/cygmspack-0.dll usr/share/doc/" libmspack_devel_CONTENTS="usr/include/ usr/lib/" to libmspack0_CONTENTS="usr/bin/cygmspack-0.dll" libmspack_devel_CONTENTS="usr/include/ usr/lib/ usr/share/doc/" as the shared library package should contain only the library. except that GTG from me. Yaakov, can you confirm the change of maintainer ? Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
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 different implementation) Dash is faster in processing the data but can be made to fail if you add -d to the ls commands you're using. -- cyg 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: 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:
>
> $ bash hello.sh
> 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 to fail here?
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 different implementation)
I used fd 7 in testing. Below the output on Cygwin ... Observe the difference
when executed on Linux.
Henri
hello.sh:
#cat 7<<\EOF 0<&7 # works on both Linux and Cygwin
#cat 7<<\EOF 0<&7 /dev/fd/7 # fails on Cygwin
#ls 7<<\EOF 0<&7 -l /proc/self/fd /tmp /dev/fd/7
ls 7<<\EOF 0<&7 -lL /proc/self/fd /tmp /dev/fd/7
Hello world!
EOF
exit
# Using: ls 7<<\EOF 0<&7 -l /proc/self/fd /tmp /dev/fd/7
64-@@ bash hello.sh
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 /dev/fd/7 -> /tmp/sh-thd.3PSuc2
/proc/self/fd:
total 0
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 0 -> /tmp/sh-thd.3PSuc2
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 1 -> /dev/pty1
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 2 -> /dev/pty1
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 3 -> /proc/4972/fd
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 7 -> /tmp/sh-thd.3PSuc2
/tmp:
..
64-@@ dash hello.sh
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 /dev/fd/7 -> pipe:[4294969740]
/proc/self/fd:
total 0
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 0 -> pipe:[4294969740]
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 1 -> /dev/pty1
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 2 -> /dev/pty1
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 3 -> /proc/3740/fd
lrwxrwxrwx 1 Henri None 0 Dec 4 12:37 7 -> pipe:[4294969740]
/tmp:
..
# Using: ls 7<<\EOF 0<&7 -lL /proc/self/fd /tmp /dev/fd/7
64-@@ bash hello.sh
ls: cannot access '/dev/fd/7': No such file or directory
/proc/self/fd:
ls: cannot access '/proc/self/fd/0': No such file or directory
ls: cannot access '/proc/self/fd/7': No such file or directory
total 0
l? ? ? ? ?? 0
crw--w 1 Henri None 136, 1 Dec 4 12:39 1
crw--w 1 Henri None 136, 1 Dec 4 12:39 2
dr-xr-xr-x 2 Henri None 0 Dec 4 12:39 3
l? ? ? ? ?? 7
/tmp:
..
64-@@ dash hello.sh
prw--- 1 Henri None 0 Dec 4 12:40 /dev/fd/7
/proc/self/fd:
total 0
prw--- 1 Henri None 0 Dec 4 12:40 0
crw--w 1 Henri None 136, 1 Dec 4 12:40 1
crw--w 1 Henri None 136, 1 Dec 4 12:40 2
dr-xr-xr-x 2 Henri None 0 Dec 4 12:40 3
prw--- 1 Henri None 0 Dec 4 12:40 7
/tmp:
..
=
--
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
[ITP] libmspack 0.9
libmspack is a portable library for some loosely related Microsoft compression formats. It is the library that powers cabextract. I'm the author of both and the current Cygwin maintainer of cabextract, but not libmspack. With the most recent cabextract/libmspack releases, I prepared and uploaded new versions of both cabextract and libmspack, but only my cabextract release was accepted. I wrote to the current maintaner, Yaakov Selkowitz, and he let me know I need to formally ITA libmspack. He gives his permission, pending review. Yaakov has been using https://github.com/cygwinports/libmspack I will be using https://github.com/kyz/libmspack/blob/master/libmspack/libmspack.cygport - no patch needed, it's now in the main source - no custom src_test() needed, libmspack now has a standard "make check" testsuite Regards Stuart
Digital Signage | mediaCLOUD 6.2
We are happy to announce the mediaCLOUD 6.2 release. -- 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: Couldnt compute FAST CWD pointer and wget random kennocha.com already disabled.
Am 04.12.2018 um 08:17 schrieb rubic k: Hi, Please help. In KFU v9.9 1. Created a folder name apps and place apps.zip in it. It doesnt work too. Im bit late to this forum. Hope u can help. Thanks dear Rubic, the warning is unrelated to your problem, as it is due to KFU ( what ever is, we don't know) using an old version of cygwin1.dll https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings For both you need to contact who is distributing KFU, that is not us. Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- 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
