On Mar 7 16:12, Damien Miller wrote:> On Wed, 6 Mar 2024, Corinna Vinschen wrote: > > > > Unfortunately the logs don't show anything of use here. This test seems > > > to be working in our CI > > > > > > https://github.com/openssh/openssh-portable/actions/runs/8166331476/job/22324927234#step:11:803 > > > > This is weird, in particular because you're running this on the same > > Cygwin release. > > > > Could this be triggered by firewall settings or something like that? > > > > > I'll see if I can reproduce the failure. > > I can't replicate this on > > CYGWIN_NT-10.0-19045 win10pro 3.5.0-1.x86_64 2024-02-01 11:02 UTC x86_64 Cygwin > > which is the VM I have at hand (thanks dtucker@).Almost got crazy, because I could reproduce it at will on Windows 10 and Windows 11. After a lot of tinkering I found that the following change in dynamic-forward.sh suddenly made the test succeed. In check_socks(): ${REAL_SSH} -q -F $OBJ/ssh_config \ - -o "ProxyCommand ${proxycmd}${s} $h $PORT 2>/dev/null" \ + -o "ProxyCommand ${proxycmd}${s} $h $PORT" \ somehost cat ${DATA} > ${COPY} It occured to me that my login shell is tcsh, not bash. So I changed my login shell to bash and, lo and behold, dynamic-forward.sh succeeded even with the stderr redirection. Having said that, can this test be changed to be independent of the user's long shell? Thanks, Corinna
On Mar 7 20:57, Corinna Vinschen wrote:> After a lot of tinkering I found that the following change in > dynamic-forward.sh suddenly made the test succeed. > > In check_socks(): > > ${REAL_SSH} -q -F $OBJ/ssh_config \ > - -o "ProxyCommand ${proxycmd}${s} $h $PORT 2>/dev/null" \ > + -o "ProxyCommand ${proxycmd}${s} $h $PORT" \ > somehost cat ${DATA} > ${COPY} > > It occured to me that my login shell is tcsh, not bash. So I changed > my login shell to bash and, lo and behold, dynamic-forward.sh succeeded > even with the stderr redirection. > > Having said that, can this test be changed to be independent of the > user's long shell?^^^^ login Sorry, Corinna
On 3/7/2024 11:57 AM, Corinna Vinschen wrote:> It occured to me that my login shell is tcsh, not bash. So I changed > my login shell to bash and, lo and behold, dynamic-forward.sh succeeded > even with the stderr redirection. > > Having said that, can this test be changed to be independent of the > user's long shell?Making things work with arbitrary non-POSIX shells seems like an unnecessary maintenance burden. configure already attempts to determine a legitimate value for SHELL / TEST_SHELL - perhaps add a stderr redirect to the tests there? -- Carson
On Fri, 8 Mar 2024 at 06:59, Corinna Vinschen <vinschen at redhat.com> wrote: [...]> After a lot of tinkering I found that the following change in > dynamic-forward.sh suddenly made the test succeed. > > In check_socks(): > > ${REAL_SSH} -q -F $OBJ/ssh_config \ > - -o "ProxyCommand ${proxycmd}${s} $h $PORT 2>/dev/null" \ > + -o "ProxyCommand ${proxycmd}${s} $h $PORT" \ > somehost cat ${DATA} > ${COPY} > > It occured to me that my login shell is tcsh, not bash. So I changed > my login shell to bash and, lo and behold, dynamic-forward.sh succeeded > even with the stderr redirection.Nice find! Wow, tsch, I don't think I've used that in this millenium!> Having said that, can this test be changed to be independent of the > user's long shell?Yes we should be able to change to something that invokes ${TEST_SHELL} -c "[whatever]", although it might take a couple of attempts to get the quoting right. Lemme have a try... -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.