Re: Bash shell inside JPSOFT Take Command does not respond to input
On 2017-05-14 19:45, Jim Reisert AD1C wrote:
> I can't seem to get a bash shell to run inside of JP Software's Take
> Command:
>www.jpsoft.com
> Behavior is the same in both TC and TCC - a shell starts, but I
> can't type anything into it. This used to work in the recent past,
> so I don't know what changed, or when. Both versions 20 and 21 of
> the JPSOFT product behave the same way:
> TCC 20.11.46 x64 Windows 10 [Version 6.3.16193]
> TCC Build 46 Windows 10 Build 16193
> Registered to JJR
> f:\>bash
> CYGWIN_NT-10.0 JJR 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> [JJR:/cygdrive/f] $ <<< at this point, nothing is echoed, nothing is
> accepted
Have you changed your {/etc/,~/.}profile, ~/.bash{_profile,rc}
recently?
Your output looks to be from uname -a, so something must be running it.
Try running bash from mintty and/or cmd and see what happens.
You could also try running bash -il --noprofile --norc.
If all else fails, try using dash, and test bash -nvx {/etc/,~/.}profile
and ~/.bash{_profile,rc}, then just -vx to see if something is borked.
Can you check the PATH set within bash?
Also may want to check recent changes in readline, in case they affect
how {/etc/,~/.}inputrc settings are used.
Do you have Ubuntu|Bash for Windows using the same home dir and could
that have replaced something used by tcc or bash?
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
--
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 shell inside JPSOFT Take Command does not respond to input
Greetings, Jim Reisert AD1C! > I can't seem to get a bash shell to run inside of JP Software's Take Command: >www.jpsoft.com They have their own support forum, BTW. > Behavior is the same in both TC and TCC - a shell starts, but I can't > type anything into it. This used to work in the recent past, so I > don't know what changed, or when. Both versions 20 and 21 of the > JPSOFT product behave the same way: > TCC 20.11.46 x64 Windows 10 [Version 6.3.16193] > TCC Build 46 Windows 10 Build 16193 > Registered to JJR > f:\>bash > CYGWIN_NT-10.0 JJR 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin What about explicit bash -i ? > [JJR:/cygdrive/f] $ <<< at this point, nothing is echoed, nothing is accepted Can't confirm with TCC RT 21 and LCC/LE 14. -- With best regards, Andrey Repin Monday, May 15, 2017 05:27:13 Sorry for my terrible english... -- 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
[ANNOUNCEMENT] php 7.0.19-1
The following packages have been uploaded to the Cygwin distribution: * php-7.0.19-1 * php-devel-7.0.19-1 * httpd-mod_php7-7.0.19-1 * php-bcmath-7.0.19-1 * php-bz2-7.0.19-1 * php-calendar-7.0.19-1 * php-ctype-7.0.19-1 * php-curl-7.0.19-1 * php-dba-7.0.19-1 * php-enchant-7.0.19-1 * php-exif-7.0.19-1 * php-fileinfo-7.0.19-1 * php-ftp-7.0.19-1 * php-gd-7.0.19-1 * php-gettext-7.0.19-1 * php-gmp-7.0.19-1 * php-iconv-7.0.19-1 * php-imap-7.0.19-1 * php-json-7.0.19-1 * php-ldap-7.0.19-1 * php-intl-7.0.19-1 * php-mbstring-7.0.19-1 * php-mcrypt-7.0.19-1 * php-mysqli-7.0.19-1 * php-odbc-7.0.19-1 * php-opcache-7.0.19-1 * php-pdo_dblib-7.0.19-1 * php-pdo_mysql-7.0.19-1 * php-pdo_odbc-7.0.19-1 * php-pdo_pgsql-7.0.19-1 * php-pdo_sqlite-7.0.19-1 * php-pgsql-7.0.19-1 * php-phar-7.0.19-1 * php-posix-7.0.19-1 * php-pspell-7.0.19-1 * php-recode-7.0.19-1 * php-shmop-7.0.19-1 * php-simplexml-7.0.19-1 * php-soap-7.0.19-1 * php-sqlite3-7.0.19-1 * php-sockets-7.0.19-1 * php-sysvmsg-7.0.19-1 * php-sysvsem-7.0.19-1 * php-sysvshm-7.0.19-1 * php-tidy-7.0.19-1 * php-tokenizer-7.0.19-1 * php-wddx-7.0.19-1 * php-xmlreader-7.0.19-1 * php-xmlrpc-7.0.19-1 * php-xmlwriter-7.0.19-1 * php-xsl-7.0.19-1 * php-zip-7.0.19-1 * php-zlib-7.0.19-1 PHP (recursive acronym for 'PHP: Hypertext Preprocessor') is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. This is an update to the latest upstream 7.0 bugfix release: http://www.php.net/ChangeLog-7.php#7.0.19 -- Yaakov -- 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
[ANNOUNCEMENT] mesa 17.0.6-1
The following packages have been uploaded to the Cygwin distribution: * dri-drivers-17.0.6-1 * libglapi0-17.0.6-1 * libGL1-17.0.6-1 * libGL-devel-17.0.6-1 * libOSMesa8-17.0.6-1 * libOSMesa-devel-17.0.6-1 * libEGL1-17.0.6-1 * libEGL-devel-17.0.6-1 * libGLESv2_2-17.0.6-1 * libGLESv2-devel-17.0.6-1 * windowsdriproto-17.0.6-1 Mesa is an open-source implementation of the OpenGL, OpenGL ES, and EGL specifications for rendering interactive 3D graphics. Complete documentation on OpenGL usage and configuration can be found here: http://x.cygwin.com/docs/ug/using-glx.html This is an update to the latest upstream bugfix release: https://www.mesa3d.org/relnotes/17.0.6.html -- Yaakov -- 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: setup release candidate - please test
On 08/05/2017 17:19, Ian Lambert via cygwin wrote: On May 8, 2017 7:06:31 AM EDT, Jon Turney wrote: As reported before, _64 still can't make it through my location's apparently unusual proxy, although cygwin's wget given proxy and password still can. Install with local mirror option works ok still. Windows 7 Enterprise SP1. It's unsurprising that 2.878 didn't fix this, as it didn't contain any changes intended to. However, since I had the code open in my editor, I took look at this... This is pretty difficult to investigate without access to a (working) NTLM proxy (getting even ntlm_fake_auth working in squid is beyond me...). Nevertheless, testing with that did suggest something, so I built a snapshot (See [1] for source) which tries something different, and does a bit more logging, so setup.log.full might shed a bit more light on why this doesn't work. Please test. https://cygwin.com/setup/setup-2.878-3-gf41e2e.x86.exe https://cygwin.com/setup/setup-2.878-3-gf41e2e.x86_64.exe [1] https://sourceware.org/git/gitweb.cgi?p=cygwin-setup.git;a=shortlog;h=refs/heads/ntlm-proxy-debugging -- 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: Ctrl-Break killing subprocess even though handled in parent process
Hi Brian, You know, I thought I tried this already, but somehow now its working. Thanks! -Original Message- From: Brian Inglis [mailto:brian.ing...@systematicsw.ab.ca] Sent: Saturday, May 13, 2017 12:29 PM To: cygwin@cygwin.com Subject: Re: Ctrl-Break killing subprocess even though handled in parent process On 2017-05-13 03:42, Brien Oberstein wrote: > I have a dotnet windows console application that runs a bash script > as a subprocess using CreateProcess() under the covers. > My windows app traps Ctrl-Break via SetConsoleCtrlHandler() and > handles it (returning true from the handler). > I execute the script via the command "bash.exe --login script.sh". > Somehow the Ctrl-Break is reaching the subprocess and causing it to > be killed, which is undesireable. > Is there a way to either prevent the Ctrl-Break from reaching the > cygwin subprocess or telling cygwin/bash to ignore it? Add to top of script: trap '' SIGINT SIGTERM does equivalent of SIG_IGN (do nothing) on named signals. $ info bash trap or $ help trap in bash gives you more info. Watch out for subshells, as signals are reset in subshells, so you will need to set up the trap in all subshells. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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
