Re: Odd command line recall problem
On 12/18/2013 04:42 PM, buggsy2 wrote: > Good idea, right now it's: > > xyz:/cygdrive/d/>printenv HISTIGNORE > &:[ \t]*:#* This says: ignore duplicate commands, ignore any command starting with space, backslash, or t, ignore any comment and tac starts with 't'. Oh, you wanted to ignore tab? Well, in bash regular expressions, [\t] stands for two characters; if you want to ignore tab, you have to type a literal TAB character instead. > > I'm not sure what all that does. But I don't think it would ignore the tac > command. Like it or not, it IS ignoring the tac command. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Need a 64-bit version of unrtf
On 2013-12-19, at 12:31, David Stacey wrote: > On 18/12/13 22:35, Tom Robinson wrote: >> [2411 CBGSAS04://cbgnas01/source/unrtf-0.21.5]$ unrtf --version >> -bash: unrtf: command not found > > It looks like you missed out a 'make install'. > > Dave. Lol! Thanks for your time Corinna and Dave, all working now. 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
Re: Odd command line recall problem
On 12/18/2013 6:42 PM, buggsy2 wrote: Good idea, right now it's: xyz:/cygdrive/d/>printenv HISTIGNORE &:[ \t]*:#* I'm not sure what all that does. But I don't think it would ignore the tac command. Well, you can always unset HISTIGNORE and see if it makes a difference. I can say that I don't have this set in my environment and I don't see the issue you report, as I mentioned in my last response. I'd still recommend reading the problem reporting guidelines in the link below if you intend to follow-up on this issue with the list. Since it's quite likely that this is problem is environment-related, seeing things like the cygcheck output that the link recommends might allow someone here to spot a relevant problem. Problem reports: http://cygwin.com/problems.html -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: Odd command line recall problem
Good idea, right now it's: xyz:/cygdrive/d/>printenv HISTIGNORE &:[ \t]*:#* I'm not sure what all that does. But I don't think it would ignore the tac command. Andrey Repin wrote > Check your HISTIGNORE ? -- View this message in context: http://cygwin.1069669.n5.nabble.com/Odd-command-line-recall-problem-tp105022p105043.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Need a 64-bit version of unrtf
On 18/12/13 22:35, Tom Robinson wrote: [2411 CBGSAS04://cbgnas01/source/unrtf-0.21.5]$ unrtf --version -bash: unrtf: command not found It looks like you missed out a 'make install'. Dave. -- 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: Need a 64-bit version of unrtf
That got me further on thanks Corinna, but getting a different error now:
[2407 CBGSAS04:/cygdrive/e/Programs]$ ls -l /usr/include/ic*
-rw-r--r-- 1 cbg.tom Domain Users 13 Dec 9 23:54 /usr/include/icmp.h
-rw-r--r-- 1 cbg.tom Domain Users 9365 Mar 7 2013 /usr/include/iconv.h
[2408 CBGSAS04:/cygdrive/e/Programs]$ cd //cbgnas01/source/unrtf-0.21.5/
[2409 CBGSAS04://cbgnas01/source/unrtf-0.21.5]$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking for string.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for memset... yes
checking for strchr... yes
checking for strstr... yes
checking build system type... x86_64-unknown-cygwin
checking host system type... x86_64-unknown-cygwin
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating outputs/Makefile
config.status: creating patches/Makefile
config.status: creating src/Makefile
config.status: creating tests/Makefile
config.status: creating config.h
config.status: executing depfiles commands
[2410 CBGSAS04://cbgnas01/source/unrtf-0.21.5]$ make
make all-recursive
make[1]: Entering directory '//cbgnas01/source/unrtf-0.21.5'
Making all in src
make[2]: Entering directory '//cbgnas01/source/unrtf-0.21.5/src'
gcc -DHAVE_CONFIG_H -I. -I.. -DPKGDATADIR=\"/usr/local/share/unrtf\" -g -O2
-MT attr.o -MD -MP -MF .deps/attr.Tpo -c -o attr.o at tr.c
mv -f .deps/attr.Tpo .deps/attr.Po
gcc -DHAVE_CONFIG_H -I. -I.. -DPKGDATADIR=\"/usr/local/share/unrtf\" -g -O2
-MT convert.o -MD -MP -MF .deps/convert.Tpo -c -o con vert.o convert.c
mv -f .deps/convert.Tpo .deps/convert.Po
gcc -DHAVE_CONFIG_H -I. -I.. -DPKGDATADIR=\"/usr/local/share/unrtf\" -g -O2
-MT error.o -MD -MP -MF .deps/error.Tpo -c -o error.oerror.c
mv -f .deps/error.Tpo .deps/error.Po
gcc -DHAVE_CONFIG_H -I. -I.. -DPKGDATADIR=\"/usr/local/share/unrtf\" -g -O2
-MT hash.o -MD -MP -MF .deps/hash.Tpo -c -o hash.o ha sh.c
mv -f .deps/hash.Tpo .deps/hash.Po
gcc -DHAVE_CONFIG_H -I. -I.. -DPKGDATADIR=\"/usr/local/share/unrtf\" -g -O2
-MT my_iconv.o -MD -MP -MF .deps/my_iconv.Tpo -c -o m y_iconv.o my_iconv.c
my_iconv.c: In function ‘get_code_str’:
my_iconv.c:56:2: warning: passing argument 2 of ‘libiconv’ from incompatible
pointer type [enabled by default]
if (iconv(desc, &icp, &ibytes, &ocp, &obytes) == -1) {
^
In file included from my_iconv.h:39:0,
from my_iconv.c:20:
/usr/include/iconv.h:83:15: note: expected ‘char **’ but argument is of type
‘unsigned char **’
extern size_t iconv (iconv_t cd, char* * inbuf, size_t *inbytesleft, char* *
outbuf, size_t *outbytesleft);
^
my_iconv.c:56:2: warning: passing argument 4 of ‘libiconv’ from incompatible
pointer type [enabled by default]
if (iconv(desc, &icp, &ibytes, &ocp, &obytes) == -1) {
^
In file included from my_iconv.h:39:0,
from my_iconv.c:20:
/usr/include/iconv.h:83:15: note: expected ‘char **’ but argument is of type
‘unsigned char **’
extern size_t iconv (iconv_t cd, char* * inbuf, size_t *inbytesleft, char* *
outbuf, size_t *outbytesleft);
^
my_iconv.c: In function ‘my_iconv_open’:
my_iconv.c:76:6: warning: passing argument 1 of ‘search_in_path’ discards
‘const’ qualifier from pointer target type [enabled by def au
Re: locale "de_DE.UTF-8", fscanf problem?
On Dec 17 17:49, Corinna Vinschen wrote: > On Dec 17 11:04, Corinna Vinschen wrote: > > On Dec 17 10:09, Tilman Kuepper wrote: > > > Hello, > > > > > > There seems to be an "unbalance" with fprintf and fscanf when using > > > the "de_DE.UTF-8" locale. > > > > > > The following program correctly writes "2,5" (decimal comma) to a > > > file. But reading with fscanf fails - the decimal comma is treated > > > as "end of number". > > > > > > Regards, > > > Tilman > > > > > > -- > > > [...testcase...] > > > > Weird. I was pretty sure that scanf is doing the right thing, but > > apparently it doesn't. Thanks a lot for the testcase, I'll have a look > > into this issue. > > A generic solution for this problem is much more complex than I > anticipated. I'll be looking into getting this into the next Cygwin > release, but it will take at least a couple of days to get this right, > so don't hold your breath for testing a fix within... uhm... the year > 2013, I guess. I applied a newlib patch today. Please give the next developer snapshot from http://cygwin.com/snapshots/ a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpD4XQdHQ2hk.pgp Description: PGP signature
Re: Need a 64-bit version of unrtf
On Dec 19 09:34, Tom Robinson wrote: > my_iconv.h:39:19: fatal error: iconv.h: No such file or directory > #include >^ > compilation terminated. > Makefile:376: recipe for target 'attr.o' failed > make[2]: *** [attr.o] Error 1 > make[2]: Leaving directory '//cbgnas01/source/unrtf-0.21.5/src' > Makefile:365: recipe for target 'all-recursive' failed > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory '//cbgnas01/source/unrtf-0.21.5' > Makefile:305: recipe for target 'all' failed > make: *** [all] Error 2 > > > Ran cygwin setup and installed libiconv (including source), which is meant to > include iconv.h (?), but still receiving the same error (and still no iconv.h > in /usr/include). Install libiconv-devel. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpS_4qyliY5F.pgp Description: PGP signature
Need a 64-bit version of unrtf
Hi guys, I need to run unrtf under a 64-bit install of CYGWIN_NT-6.3 Apparently it's MIA: http://cygwin.com/ml/cygwin-apps/2013-08/msg00256.html (maintained by Jari Aalto). Is a 64-bit version in the repository close, or can somebody help me compile it? I tried downloading directly and compiling, per http://www.gnu.org/software/unrtf/unrtf.html, but am getting an error in make: [2397 CBGSAS04://cbgnas01/source/unrtf-0.21.5]$ make make all-recursive make[1]: Entering directory '//cbgnas01/source/unrtf-0.21.5' Making all in src make[2]: Entering directory '//cbgnas01/source/unrtf-0.21.5/src' gcc -DHAVE_CONFIG_H -I. -I.. -DPKGDATADIR=\"/usr/local/share/unrtf\" -g -O2 -MT attr.o -MD -MP -MF .deps/attr.Tpo -c -o attr.o attr.c In file included from output.h:41:0, from main.h:48, from attr.c:68: my_iconv.h:39:19: fatal error: iconv.h: No such file or directory #include ^ compilation terminated. Makefile:376: recipe for target 'attr.o' failed make[2]: *** [attr.o] Error 1 make[2]: Leaving directory '//cbgnas01/source/unrtf-0.21.5/src' Makefile:365: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '//cbgnas01/source/unrtf-0.21.5' Makefile:305: recipe for target 'all' failed make: *** [all] Error 2 Ran cygwin setup and installed libiconv (including source), which is meant to include iconv.h (?), but still receiving the same error (and still no iconv.h in /usr/include). Thanks. -- 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: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)
On Wed, Dec 18, 2013 at 01:10:40PM +0100, Markus Hoenicka wrote: >Am 2013-12-10 21:40, schrieb Jon TURNEY: >> On 04/12/2013 22:14, Markus Hoenicka wrote: >>> Around 2013-12-04 16:59 Jon TURNEY was heard to say: On 04/12/2013 08:09, Markus Hoenicka wrote: > Am 2013-12-03 22:10, schrieb Christopher Faylor: >> I added an ugly hack to work around this symptom in the latest >> cygwin. >> It shouldn't have any big impact on anything but this particular >> scenario but I would appreciate it if people downloaded today's >> snapshot >> and verified that things are still working ok. >> >> I plan on addressing the actual problem for Cygwin 1.7.28. > > the nightly snapshot does not seem to do me any good with regard to > the > clipboard problem. I performed the following test, and I hope this > is what you > had in mind: There is also a bug in xwinclip which needs fixing for this test to work reliably, but it was difficult to see what that was without this fix in the cygwin DLL. >>> >>> I see. Let me know whenever it makes sense to do any further testing. >> >> I just uploaded X server 1.14.4-2, which should have this fixed. >> >> (With cygwin DLL prior to the nightly snapshot of 2013-12-04, you may >> see >> "Spurious wake" recorded in XWin's log, but pasting should still work >> correctly) >> > >Hi, > >this is just to confirm that the problem appears to be fixed after I >updated my installation today, using cygwin 1.7.27-2 and xorg-server >1.14.4-2. Thanks to you and Christopher for making things work again. Good to hear. Thanks for letting us know. cgf -- 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: Change in behavior of bash / if [
On 12/18/2013 07:18 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote: >>> if [ "x$1" = xclip ] >> >> Yes, this is the correct fix for the improper quotation of the earlier >> example. > > But why would it need quoting unless the first argument unless the > command line is quoted and might have a space"? It wasn't. It was > called from a script that was being sourced by a bash interactive shell > as follows. > > lddir clip I'd need to see your entire script to know for sure. Perhaps you are using calls to 'set' or using shell functions, either of which modifies $1 from the value that you passed on the command line. But the point remains - your improper quoting of $1 is not a cygwin-specific issue. > Speculation: Since cygwin1.dll was updated last week, perhaps > something happened there. Less likely. But without seeing your entire script, it's hard to say. You haven't given anyone else enough to go on. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RE: Change in behavior of bash / if [
Eric Blake sent the following at Tuesday, December 17, 2013 11:08 PM >On 12/17/2013 08:02 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote: >> Today, a script that I use every day stated giving me the following >> error message. (I grant that it might have started earlier and I >> didn't notice.) Note that although it gave the error message, the >> script seems to still have worked. In my original post, I should have reported that it is a bash script. >> ./lddir: line 77: [: too many arguments >> >> Line 77 was as follows. I'm testing whether $1 is "clip". >> >> if [ x$1 = xclip ] > >What was $1 at the time? clip >> I fixed it with this. >> >> if [ "x$1" = xclip ] > >Yes, this is the correct fix for the improper quotation of the earlier >example. But why would it need quoting unless the first argument unless the command line is quoted and might have a space"? It wasn't. It was called from a script that was being sourced by a bash interactive shell as follows. lddir clip "clip is telling lddir to get its input from the clipboard instead of the command line. "clip" is never used with another argument. The calling script is being sourced because it is change the working directory of the interactive shell. And the path of that directory is known to not have spaces. >> 32-bit, everything was up to date. >> >> I've solved my problem, but the change was unexpected and, for me, >> inexplicable, so I thought that I'd report it. > >Your quoting error would produce the same message on Linux; it is not >cygwin-specific. >> >> Let me know if you want/need more information. > >Without knowing how $1 was set, I can only guess that it contained >something with characters in $IFS and therefore the word-splitting of >the unquoted use caused too many arguments to [. For that, it would have to be called with $1 on the command line in quotes, which it wasn't. Something like the following. lddir "111 one" 222 "three 333" 444 And then there's the fact that I've been using lddir with no changes for the past year and it just started misbehaving now. Speculation: Since cygwin1.dll was updated last week, perhaps something happened there. But if no one else reports a similar problem, it might be something peculiar to my installation and use and not worth debugging. Thanks for your response. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: Please try newest snapshot (was Re: emacs-x11: new clipboard size limitation?)
Am 2013-12-10 21:40, schrieb Jon TURNEY: On 04/12/2013 22:14, Markus Hoenicka wrote: Around 2013-12-04 16:59 Jon TURNEY was heard to say: On 04/12/2013 08:09, Markus Hoenicka wrote: Am 2013-12-03 22:10, schrieb Christopher Faylor: I added an ugly hack to work around this symptom in the latest cygwin. It shouldn't have any big impact on anything but this particular scenario but I would appreciate it if people downloaded today's snapshot and verified that things are still working ok. I plan on addressing the actual problem for Cygwin 1.7.28. the nightly snapshot does not seem to do me any good with regard to the clipboard problem. I performed the following test, and I hope this is what you had in mind: There is also a bug in xwinclip which needs fixing for this test to work reliably, but it was difficult to see what that was without this fix in the cygwin DLL. I see. Let me know whenever it makes sense to do any further testing. I just uploaded X server 1.14.4-2, which should have this fixed. (With cygwin DLL prior to the nightly snapshot of 2013-12-04, you may see "Spurious wake" recorded in XWin's log, but pasting should still work correctly) Hi, this is just to confirm that the problem appears to be fixed after I updated my installation today, using cygwin 1.7.27-2 and xorg-server 1.14.4-2. Thanks to you and Christopher for making things work again. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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
Cygrunsrv starts sshd twice after disconnect (1.7.25 i686 WinXP)
I have sshd running as a Windows service, installed via cygrunsrv. It basically works fine, but once a day (maybe after DSL reconnect) when I try to re-open my connection to the PC, I notice that some reverse tunnels cannot be established. Upon further investigation I have found that two sshd.exe processes are running, one of which can be stopped via the Windows Services dialog, but the other one is still running, blocking the ports which my reverse tunnels should use as listening ports on the Windows machine. The registry says that sshd is started with -D option as is to be expected. So everything seems fine. Can somebody tell me why to sshd processes are running? If I kill the zombie one, the Windows service works as sxpected and I can establish my reverse tunnels again. -- Alexander Kriegisch -- 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
