At 07/11/2017 at 15:12, Shakespearean monkeys
danced on Jürgen Wagner's keyboard and said:
...
Using backquotes instead of the command
substitution with $(...) does not change the
results. I could swear this did work in an
earlier version of Cygwin on my Windows 7 machine.
I tried this to see if the code in the parentheses is executed at all:
$ value="$( date 2> foo | cat )"; echo "$? <$value>"
The file "foo" was not created, i.e., it seems
the commands don't really get executed.
$ value="$( date && pwd )"; echo "$? <$value>"
0 <Tue Jul 11 20:49:09 CEST 2017
/home/juergen>
$ value="$( date || pwd )"; echo "$? <$value>"
0 <Tue Jul 11 20:32:27 CEST 2017>
both work, so some control structures seem to be
permissible... just not a pipe.
What is going on? Some misconfiguration? A
Cygwin bug? Some interaction with something
weird in Windows 10? I am at loss to understand
what could be wrong... and am now most curious
whether anybody has an idea what is causing
this. Does it work/not work in the same way in your Cygwin installation?
I came across this effect because
ssh-host-config did not recognize me as
administrator anymore. It's due to a check for a
certain user group that uses a command
substitution with a pipe. Replacing this with an
equivalent command works. The original line used
"id -G" and then a "grep -Eq" to check whether a certain group is on that list.
I am VERY curious now! I've rarely been puzzled
that much by such a very elementary shell
expression (looking back at 34 years of Unix experience).
Hi Jurgen.
90% chance it's what is called bloda in these
parts. It's in the FAQ on cygwin.com. I'll go
out on a limb and say you might have just
installed/changed your AV/Firewall software.
And if I want to be super-psychic, can I guess
comodo? Because I just changed to comodo a
couple weeks ago and had the same
subshell/command substitution/pipeline errors you're mentioning.
If so, you need to exclude your cygwin folder
from AV scanning. AND... if the software does
whitelisting or host intrusion protection (HIPS)
or "run unknown executables in a
container/sandbox" or something similar, you also
need to trust all the executables, too. Or
switch to something else that doesn't trip cygwin's trigger.
After doing that and a rebaseall, I haven't had a
fork error in a week. I can't wait to run setup
and come up with an update process, though...
Cheers!
--
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
