Strange errors from grep pipeline
Hi, I am running Windows XP SP2 and am having some strange issues when I use find...|xargs grep For example find|xargs grep string yields: ... (standard input):./butlradv/res/strings.rc (standard input):./butlrcmn/Debug/string.obj (standard input):./butlrcmn/Debug/stringlist.obj (standard input):./butlrcmn/string.cpp (standard input):./butlrcmn/stringlist.cpp (standard input):./include/screens/stringid.h (standard input):./include/string.hpp (standard input):./include/stringlist.hpp (standard input):./STLport-4.5.3/src/string_w.cpp (standard input):./STLport-4.5.3/stlport/BC50/cstring.h (standard input):./STLport-4.5.3/stlport/BC50/string.h (standard input):./STLport-4.5.3/stlport/BC50/using/cstring.h (standard input):./STLport-4.5.3/stlport/cstring (standard input):./STLport-4.5.3/stlport/stl/debug/_string.h (standard input):./STLport-4.5.3/stlport/stl/msl_string.h (standard input):./STLport-4.5.3/stlport/stl/_string.c (standard input):./STLport-4.5.3/stlport/stl/_string.h (standard input):./STLport-4.5.3/stlport/stl/_string_fwd.c (standard input):./STLport-4.5.3/stlport/stl/_string_fwd.h (standard input):./STLport-4.5.3/stlport/stl/_string_hash.h (standard input):./STLport-4.5.3/stlport/stl/_string_io.c (standard input):./STLport-4.5.3/stlport/stl/_string_io.h (standard input):./STLport-4.5.3/stlport/string (standard input):./STLport-4.5.3/stlport/string_stlp.h (standard input):./STLport-4.5.3/stlport/using/cstring (standard input):./STLport-4.5.3/test/eh/test_string.cpp (standard input):./STLport-4.5.3/test/regression/string1.cpp ... grep: ./Butlr3D/DimLine/DimLine_ShiftedDimensionValueAdapter.cpp: No such file or directory grep: ./Butlr3D/DimLine/DimLine_ShiftedDimensionValueAdapter.h: No such file or directory grep: ./Butlr3D/DimLine/DimLine_TextRepositioner.cpp: No such file or directory grep: ./Butlr3D/DimLine/DimLine_TextRepositioner.h: No such file or directory grep: ./Butlr3D/DimLine/DimLine_ValueAdapter.cpp: No such file or directory grep: ./Butlr3D/DimLine/DimLine_ValueAdapter.h: No such file or directory grep: ./Butlr3D/DimLine/DimLine_ValueAdapterForSelectionObjectDimension.cpp: No such file or directory grep: ./Butlr3D/DimLine/DimLine_ValueAdapterForSelectionObjectDimension.h: No such file or directory ... If I use find -print0|xargs -0 grep string I get nothing at all and find -print0|xargs -0 grep -v string produces nothing as well. Any ideas or help at all would be appreciated. -- Ron Parker Butler Manufacturing Company -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Strange symlink and mv interaction
From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] Tilde expansion is usually done by the shell. However, judging from the rest of your message, you meant the above to say mv -- --1.2 ../tla--escapes--1.2 I did. This is the expected behavior. The symlink takes you to the directory, but the .. uses the actual parent directory entry, which points to /c. If you want this to work seamlessly, create an actual ~/src/myprojects directory, and use 'mount' to map /c/MyProjects to /home/rdparker/src/myprojects. Thanks, I don't know why I didn't do that in the first place. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Patch and directions for compiling GNU screen 3.9.15 on cygwi n
From: Christopher Faylor Wow, that was *it*? It seems like a pretty simple patch if this really gets things working. Can I entice you into being the package maintainer for screen? There's a gold star in it for you! I may consider doing it, if I can get a couple of issues resolved and I have a few spare minutes. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Patch and directions for compiling GNU screen 3.9.15 on Cygwin
I created a patch for GNU screen 3.9.15 that will allow it to be compiled
and installed on Cygwin. The patch is attached below, the basic build and
install procedure is:
$ tar xzf {tar-path}/screen-3.9.15.tar.gz
$ cd screen-3.9.15
$ patch -p1 -s {patch-path}/screen-3.9.15-cygwin.diff
$ autoconf
$ ./configure
$ make
$ make install
Manual add the termcap and terminfo settings for screen.
$ cd terminfo
$ cat screencap /etc/termcap
$ tic screeninfo.src
If everything works as planned screen should now be in /usr/local/bin. See
if it is:
$ which screen
The patch is attached.
screen-3.9.15-cygwin.diff
Description: Binary data
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: The increased path length changes
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED] 1) Does Ron Parker have an assignment on file with Red Hat? I can't find one, if so. This will be a requirement if the patches are accepted. The mechanical change that was just checked in is ok but any more substantial changes will need an assignment. My assignment may date back to Geoff Naur. I will gladly resubmit one. I will try to print it out Tonight and send it to Rose Naftaly, as per assign.txt.
RE: thunk createDirectory and createFile calls
-Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED] On Sat, 2003-11-15 at 02:52, Christopher Faylor wrote: It is a given that we're working in cygwin. Adding a cygwin_ to the beginning of a function is just noise. Heh, will fix... was following Ron's convention semi-blindly. Who was following Rob's suggestion for a cygwin_CreateFile semi-blindly. :^)
RE: Additional Cygwin long file path patch
From: Parker, Ron [mailto:[EMAIL PROTECTED] From: Robert Collins [mailto:[EMAIL PROTECTED] 1a) Update CYG_MAX_PATH to (say) 270. Check for issues with the change occuring, and rectify. I actually bumped CYG_MAX_PATH to 520, double its previous value. It seems to be work for me and allows tla to actually create deep paths. rbc02-cyg-max-path-520.diff Description: Binary data
Deep directory support
Please read beyond the next paragraph before hitting delete. Odd file names are not the issue here, so bare with my for a minute. I'll get to the point shortly. Once upon a time I messed with making changes to Cygwin to allow protected file names like aux to work with Cygwin. At the time I was looking into using the UNICODE file functions and prepending '\\?\' to the file's name in order to accomplish this. On NT-based systems this basically goes directly to the device namespace, bypassing a lot of the filtering and limitations of the Win32 subsystem. I never submitted this code, because it was ugly, required touching Cygwin all over the place and I didn't have the time to implement it cleanly. However, of late I have been playing with arch (specifically tla) and have run into an issue with Cygwin. Namely MAX_PATH is 260 and it is common for arch repositories to have tar files that are deeper than this. I have tried working around these issues in tla, but normalize_posix_path and other areas of Cygwin that return ENAMETOOLONG keep causing errors in tar when attempting to extract some of these files. I am working on some Cygwin patches and would like input and some idea of whether my idea has an ice cube's chance in hell of being accepted or not. It basically boils down to doing something like what I originally thought of for files with protected device names. At this point my patches arbitrarily increase MAX_PATH to 4096 and map most of the CreateFile calls to a function provisionally called createfile. If is_winnt, this function prepends '\\?\' to the absolute path name, converts that to UNICODE and calls CreateFileW, otherwise it just passes through to CreateFile(A). The 4096 is just to match Linux, the SDK is not specific on how close to 32Ki you can get before things blow up, so I am being conservative. I realize that CreateFile is not the only thing that I will have to deal with for this to be a complete solution. I will need to do something similar for other functions as well, but I wanted some input before creating an unacceptable solution. Is this a desirable approach to the issue. One nasty side-effect of this is that Explorer will blow up drilling down into a deep directory structure and it gets errors attempting to delete a deep directory structure. Both are Explorer bugs, IMO. The deleting issue can be worked around in Explorer by moving subdirectories in the deep structure to a higher level, say the drive's root directory, and deleting them from there. Any thoughts or input?
Debugging cygwin1.dll startup
I have made some local changes to the source for cygwin1.dll and would like to debug it, as the first Cygwin process, bash, begins. I know about using a gdb-startup.cmd setup for JIT debugging applications, but this does not seem to work for debugging Cygwin prior to reaching a bash prompt. Is the 'dll cygwin1' GDB mechanism the only way to do what I need? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Setup Parse Errors
I am attempting to run setup version 2.340.2.5, which I just downloaded from cygwin.com, and I am receiving a number of different Parse Errors processing setup.bz2. They all read: (null) line X: syntax error, unexpected NL, expecting STRING (null) line X: unrecognized line X+1 (do you have the latest setup?) for x in 429 440 744. It's also interesting that each time I back up and try again with a different site the list gets appended to instead of restarted. I might try debugging this, but I have to get Cygwin reinstalled first, catch-22. This is all because tetex-base-2.0.1.13(version???) was freezing setup, so I decided to uninstall and reinstall. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: setup.ini corrupted on sources.redhat.com
Chris, thank you for correcting this quickly. I am back up and running again. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Mozilla 1.3 built on cygwin?
Noone has explained, however, *why* the copy-on-write implementation was slower. Perhaps we have just been using the wrong tests. Does copy-on-write actually perform slower in real world tests? I don't know, because I only While I never posted anything about it to the list. I tried out a few things with copy-on-write, COW, about the time cgf took over around here. I never posted anything because, as others have noted COW actually loses in terms of performance. This is accessing deep memory for me, so it may be inaccurate. But, IIRC the copy-on-write support in NT-based systems is half-documented and half-implemented at the user level. There are things that can be done at the OS level and in the POSIX subsystem with COW that are not exposed in the Win32 subsystem. (Perhaps with a Shared-Source license, but not with just the SDK.) Also given the file format of executables on Windows, there are some other problems. Many of which are introduced by the prevalence of DLLs in the system. As an example, if you have two programs that link to the same DLL and one of them can load the DLL at its base address, but the other has to move it to a different memory location, you will effectively wind up with two copies of the DLL in memory. Each page of the DLL that needs a fixup can no longer be backed by the DLL file itself. Rather, it has to be hauled in to memory, fixed up and then if it gets paged out, it goes to the swap file. This is why rebase'ing an application or properly setting the base addresses of DLLs can so dramatically improve the startup performance of an application. The DLLs don't have to be read into memory the page-table entries, PTEs, just have to be set up. Even if you have two instances of a program running, but they LoadLibrary the same two overlapping DLLs in a different order, you will wind up with two copies of the DLLs in memory. And if the EXE patches itself up, as the code generated some language compilers has been known to do to avoid the extra IVT call for each DLL function, you wind up with two copies of the EXE in memory too. I also seem to recall that there was no guarantee of the OS allocating memory at the address that you request with some of the memory functions. CGF comments in this thread that, It was almost like Microsoft was purposely twarting[sic] what seems like a reasonable use of memory mapping. That was the same conclusion that I came too. This part may be completely incorrect, but IIRC you don't even have access to be able to setup LDT selectors in an attempt to manage some virtual memory yourself. In the 98/ME DDK there is at least some support for LDT/GDT manipulation. I suppose it might be possible from an NT/2K/XP driver as well, but I never investigated that. I did just a little digging and found that the really funny thing is Knowledge Base Article Q101779 says, Most 386/486-based memory managers expect to manage page tables; Windows NT cannot allow this for security reasons. NOTE: Some 286-based memory managers can work on RISC-based computers because VDMs (virtual DOS machines) act as complete 286 machines and applications can control the local and global descriptor tables. Heh, cannot allow this for security reasons. Okay, I won't go off on that tangent too far. Anyway, feel free to poke holes in this and bash me about the head and shoulders if it is completely inaccurate I just thought I'd offer what the dust-bunnies were sitting on in my attic and see how it matched up with what others came across. By now, that last paragraph tells me that I need sleep. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Aliases no longer defined?
http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! While I'm not really a cat person, I've meant to tell you, that is one of the coolest and most creative sigs I've ever seen. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: accessing drives at block level in win98
-Original Message- From: Rolf Campbell [mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Can win98 access /dev/sda directly? the article here suggests that only NT+ can do this??? http://www.cygwin.com/cygwin-ug-net/using-specialnames.html That article is correct. You can't do that using Win98. I am just speculating here, but it might be possible to implement this functionality in Cygwin via an ASPI interface. I believe that is how much of the CD ripping software for Win9x works. I have neither the time nor the interest in doing this but bring it up in case anyone has the desire and motivation to pursue it. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin Network Programming Problem
-Original Message- From: Elfyn McBratney [mailto:[EMAIL PROTECTED]] snip I tried your source, looks o.k. at first glance, and it works perfectly. I tried to reproduce your problem, about 10 times, and I always got: Hello, world! Connection closed snip I did have the latest DLL, but apparently needed a reboot. The server still issues an accept: No children message after each connect, but now continues working. This is better, but I would like to understand why I see this message. To me, it looks like an error of either my own cygwin's making. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin Network Programming Problem
I have taken what looks to be a common network programming sample from the
Internet and compiled it on Cygwin. Upon reaching 'accept' for the second
time I receive the following output:
accept: No children
I have spent a few days perusing the Net and have found no solution to this
problem. If you compile and run the following source, you can telnet to
port 3490 and get back, Hello, world!. When you telnet a second time, the
error shows up.
#include stdio.h
#include stdlib.h
#include unistd.h
#include errno.h
#include string.h
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include sys/wait.h
#include signal.h
#define MYPORT 3490
#define BACKLOG 10
void sigchld_handler(int s)
{
while(wait(NULL) 0);
}
int main(void)
{
int sockfd, new_fd;
struct sockaddr_in my_addr;
struct sockaddr_in their_addr;
int sin_size;
struct sigaction sa;
int yes=1;
if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
perror(socket);
exit(1);
}
my_addr.sin_family = AF_INET;
my_addr.sin_port = htons(MYPORT);
my_addr.sin_addr.s_addr = INADDR_ANY;
memset((my_addr.sin_zero), '\0', 8);
if (bind(sockfd, (struct sockaddr *)my_addr, sizeof(struct sockaddr))
== -1) {
perror(bind);
exit(1);
}
if (listen(sockfd, BACKLOG) == -1) {
perror(listen);
exit(1);
}
sa.sa_handler = sigchld_handler;
sigemptyset(sa.sa_mask);
sa.sa_flags = SA_RESTART;
if (sigaction(SIGCHLD, sa, NULL) == -1) {
perror(sigaction);
exit(1);
}
while(1) {
sin_size = sizeof(struct sockaddr_in);
if ((new_fd = accept(sockfd, (struct sockaddr *)their_addr,
sin_size)) == -1) {
perror(accept);
continue;
}
printf(server: got connection from
%s\n,inet_ntoa(their_addr.sin_addr));
if (!fork()) {
close(sockfd);
if (send(new_fd, Hello, world!\n, 14, 0) == -1)
perror(send);
close(new_fd);
exit(0);
}
close(new_fd);
}
return 0;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RXVT Font Question
The Windows 2000 console can use two different fonts. The one is Lucida Console. The other is Terminal. Is it possible to use Terminal in say the 8x12 size with rxvt? I think it does the right thing with box characters and while it is not as smooth has a heavier weight and is easier on my eyes with certain color combinations. -- Beauty is in the eye of the beholder and the beholder is blind. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: C++ Link Errors
g++ -Wl,--enable-auto-import -ftemplate-depth-99 -O2 -o uml.exe [...] After a number of auto-import warnings, which I expect, like: Warning: resolving QString::shared_null by linking to __imp___7QString$shared_null (auto-import) I receive a series of messages, which I don't expect, like: umlview.o(.text+0x34f5):umlview.cpp: undefined reference to `cerr' umlview.o(.text+0x34fa):umlview.cpp: undefined reference to `ostream::_ls(char const *)' umlview.o(.text+0x3506):umlview.cpp: undefined reference to `endl(ostream ) ' Any ideas? cerr et al. are in libstdc++.a Add libstdc++.a to the link line. Libtool uses gcc to link not g++, i guess it is a bug in libtool, though if you use g++ like shown above libstdc++ should be linked in automatically. The libtool I have does use g++ and it is being linked with libstdc++.a. I even added a spare -lstdc++ to the end of the g++ command, but the error remains. It may be worth mentioning that the error is seen during the collect2 phase. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
