Re: [Patch]: path.cc
On Sun, Apr 04, 2004 at 09:57:56AM -0400, Pierre A. Humblet wrote: At 11:01 PM 4/3/2004 -0500, Christopher Faylor wrote: On Sat, Apr 03, 2004 at 09:49:40PM -0500, Pierre A. Humblet wrote: Also, there is a problem in execution: snip I believe that this is due to your removal of the normalize stuff from mount_info::conv_to_win32_path. It turns out that the normalized stuff was never called in mount_info::conv_to_win32_path and so that's really old cruft. It was always called with no_normalize. Oh, that's right. I added that after adding the normalize_posix_path in the main loop. At one point something else was calling conv_to_win32 but this was eventually subsumed by a call to path_conv. Also, maybe I'm missing something, but it seems like your change to pathnmatch is not necessarily an optimization. It depends on the path. Right. If one is often comparing paths that differ in the last len1-n characters then doing the isdirsep, etc. checks makes sense. It only seems like it would be an operation if you were routinely compared paths like c:\cygwin and c:\cygwinfoo which is rarely the case, IMO. Absolutely right. It's an optimization if the probability that isdirsep() detects a mismatch is greater than cost of executing isdirsep() / cost of executing the pathnmatch. The latter involves two function calls while isdirsep() is a simple macro, so my gut feeling is that the change is good. With attempts at optimization, I've learned not to trust guts. Except that old symlinks that use EA would be slightly slower, right? I agree that it is not worth keeping this in the inner loop. I have always wanted to cache this data, too, rather than continually looking it up. Done. So, sorry, this patch isn't yet ready for prime time. Here we go again, from a clean sandbox. Can you break it down into smaller pieces, maybe? It's like pulling a thread... Actually... You could send a patch that eliminates the no_normalize argument. You could have sent a patch which eliminates the left over cruft in no_normalize. You could have sent a patch that optimizes pathnmatch. You could have sent a patch which moves the test into the outer loop. Even just breaking down the optimizations to one per function would be useful, IMO. I've already demonstrated that making obvious changes to the code can have subtle side effects. I actually found the problem while on the way to check another corner case, never getting to the actual problem that I thought would manifest in your changes. Given that we are working on the most sensitive area of cygwin, breaking this down into individual patches makes a lot of sense. We can make controlled releases and track changes through CVS. I'm leaving on a jet plane soon but I should have time, hotel internet permitting, to review further changes. If you don't want to break these up, I'll probably check stuff in piecemeal and generate snapshots. cgf AAt this point I would need to undo some changes and retest. The next one will be shorter. Perhaps I should not have added the removal of fs.update(), but given that we have discussed it... Pierre 2004-04-04 Pierre Humblet [EMAIL PROTECTED] * path.cc (path_prefix_p): Optimize test order. (normalize_posix_path): Add tail argument and set it. Always have a final slash for directories. Pass 3rd argument to normalize_win32_path. (path_conv::check): Pass tail to normalize_posix_path. Set need_directory and remove final slash after that call. Remove last argument to mount_table-conv_to_win32_path(). Remove noop dostail check. Remove fs.update() from inner loop. Improve tail finding search. (normalize_win32_path): Add and set tail argument. (mount_item::build_win32): Avoid calling strcpy. (mount_info::conv_to_win32_path): Remove third argument and simplify because the source is normalized. Keep /proc path in Posix form. Call win32_device_name() only once. (mount_info::conv_to_posix_path): Add and use 3rd argument to normalize_win32_path to avoid calling strlen. (cwdstuff::set): Add 3rd argument to normalize_posix_path and remove final slash if any. * shared_info.h (mount_info::conv_to_win32_path): Remove last argument in declaration. Index: path.cc === RCS file: /cvs/src/src/winsup/cygwin/path.cc,v retrieving revision 1.291 diff -u -p -r1.291 path.cc --- path.cc26 Mar 2004 20:02:01 - 1.291 +++ path.cc4 Apr 2004 13:46:18 - @@ -75,7 +75,7 @@ details. */ #include cygtls.h #include assert.h -static int normalize_win32_path (const char *src, char *dst); +static int normalize_win32_path (const char *src, char *dst, char ** tail = 0); static void slashify (const char *src, char *dst, int trailing_slash_p); static void backslashify (const char *src, char *dst, int trailing_slash_p); @@ -161,10 +161,10 @@ path_prefix_p
Again: Support for SNDCTL_DSP_CHANNELS ioctl
Hello,
Below comes my version of the patch and the corresponding test.
I have successfully tested it in my environment.
Gerd
ChangeLog for winsup/cygwin:
2004-04-04 Gerd Spalink [EMAIL PROTECTED]
* fhandler_dsp.cc (fhandler_dev_dsp::ioctl): Add implementation
for ioctl codes SNDCTL_DSP_CHANNELS and SNDCTL_DSP_GETCAPS
ChangeLog for winsup/testsuite:
2004-04-04 Gerd Spalink [EMAIL PROTECTED]
* winsup.api/devdsp.c (ioctltest): Add 2 tests for ioctl codes
SNDCTL_DSP_CHANNELS and SNDCTL_DSP_GETCAPS
Index: fhandler_dsp.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler_dsp.cc,v
retrieving revision 1.32
diff -p -u -r1.32 fhandler_dsp.cc
--- fhandler_dsp.cc 24 Mar 2004 08:57:17 - 1.32
+++ fhandler_dsp.cc 4 Apr 2004 21:51:17 -
@@ -1370,6 +1370,38 @@ fhandler_dev_dsp::ioctl (unsigned int cm
}
break;
+ CASE (SNDCTL_DSP_CHANNELS)
+ {
+ int nChannels = *intptr;
+
+ if (audio_out_)
+ {
+ RETURN_ERROR_WHEN_BUSY (audio_out_);
+ audio_out_-stop ();
+ if (audio_out_-query (audiofreq_, audiobits_, nChannels))
+ audiochannels_ = nChannels;
+ else
+ {
+ *intptr = audiochannels_;
+ return -1;
+ }
+ }
+ if (audio_in_)
+ {
+ RETURN_ERROR_WHEN_BUSY (audio_in_);
+ audio_in_-stop ();
+ if (audio_in_-query (audiofreq_, audiobits_, nChannels))
+ audiochannels_ = nChannels;
+ else
+ {
+ *intptr = audiochannels_;
+ return -1;
+ }
+ }
+ return 0;
+ }
+ break;
+
CASE (SNDCTL_DSP_GETOSPACE)
{
audio_buf_info *p = (audio_buf_info *) ptr;
@@ -1395,6 +1427,13 @@ fhandler_dev_dsp::ioctl (unsigned int cm
CASE (SNDCTL_DSP_GETFMTS)
{
*intptr = AFMT_S16_LE | AFMT_U8; // only native formats returned here
+ return 0;
+ }
+ break;
+
+ CASE (SNDCTL_DSP_GETCAPS)
+ {
+ *intptr = DSP_CAP_BATCH | DSP_CAP_DUPLEX;
return 0;
}
break;
Index: devdsp.c
===
RCS file: /cvs/src/src/winsup/testsuite/winsup.api/devdsp.c,v
retrieving revision 1.1
diff -p -u -r1.1 devdsp.c
--- devdsp.c24 Mar 2004 10:20:14 - 1.1
+++ devdsp.c4 Apr 2004 22:26:24 -
@@ -36,7 +36,7 @@ static const char wavfile_okay[] =
/* Globals required by libltp */
const char *TCID = devdsp; /* set test case identifier */
-int TST_TOTAL = 32;
+int TST_TOTAL = 34;
/* Prototypes */
void sinegen (void *wave, int rate, int bits, int len, int stride);
@@ -92,6 +92,7 @@ ioctltest (void)
{
int audio1;
int ioctl_par;
+ int channels;
audio1 = open (/dev/dsp, O_WRONLY);
if (audio1 0)
@@ -99,6 +100,18 @@ ioctltest (void)
tst_brkm (TFAIL, cleanup, open W: %s, strerror (errno));
}
setpars (audio1, 44100, 1, 16);
+
+ channels = ioctl_par = 1;
+ while (ioctl (audio1, SNDCTL_DSP_CHANNELS, ioctl_par) == 0)
+{
+ channels++;
+ ioctl_par = channels;
+}
+ if (channels == ioctl_par)
+tst_resm (TFAIL, Max channels=%d failed, ioctl_par);
+ else
+tst_resm (TPASS, Max channels=%d failed, OK=%d, channels, ioctl_par);
+
/* Note: block size may depend on parameters */
if (ioctl (audio1, SNDCTL_DSP_GETBLKSIZE, ioctl_par) 0)
{
@@ -110,6 +123,11 @@ ioctltest (void)
tst_brkm (TFAIL, cleanup, ioctl GETFMTS: %s, strerror (errno));
}
tst_resm (TPASS, ioctl get formats=%08x, ioctl_par);
+ if (ioctl (audio1, SNDCTL_DSP_GETCAPS, ioctl_par) 0)
+{
+ tst_brkm (TFAIL, cleanup, ioctl GETCAPS: %s, strerror (errno));
+}
+ tst_resm (TPASS, ioctl get caps=%08x, ioctl_par);
if (close (audio1) 0)
{
tst_brkm (TFAIL, cleanup, Close audio: %s, strerror (errno));
Re: [Patch]: path.cc
At 02:49 PM 4/4/2004 -0400, Christopher Faylor wrote:
I'm leaving on a jet plane soon but I should have time, hotel internet
permitting, to review further changes.
If you don't want to break these up, I'll probably check stuff in piecemeal
and generate snapshots.
OK, that's just fine. For future reference, if I break changes in
small pieces, how to you want the diffs? Each sequentially against the
previous version, or each against the same baseline cvs?
I include another patch, which affects only the part of ::check that
replaces symlinks. Its main purpose is to accelerate the execution
by avoiding useless or duplicative operations.
For your convenience I am providing two diffs: one against cvs and
one against my sandbox, after application of the previous patch.
Have a good trip.
Pierre
2004-04-05 Pierre Humblet [EMAIL PROTECTED]
* path.cc (path_conv::check): Optimize symlink replacements.
--- path.cc.new12004-04-04 18:10:26.0 -0400
+++ path.cc 2004-04-04 18:43:52.0 -0400
@@ -507,7 +507,6 @@ path_conv::check (const char *src, unsig
*--tail = '\0';
}
char *path_end = tail;
- tail[1] = '\0';
/* Scan path_copy from right to left looking either for a symlink
or an actual existing file. If an existing file is found, just
@@ -518,6 +517,7 @@ path_conv::check (const char *src, unsig
int component = 0; // Number of translated components
sym.contents[0] = '\0';
+ int symlen;
for (;;)
{
const suffix_info *suff;
@@ -607,7 +607,7 @@ path_conv::check (const char *src, unsig
goto out;
}
- int len = sym.check (full_path, suff, opt | fs.sym_opt ());
+ symlen = sym.check (full_path, suff, opt | fs.sym_opt ());
if (sym.minor || sym.major)
{
@@ -658,12 +658,12 @@ path_conv::check (const char *src, unsig
done now. */
opt |= PC_SYM_IGNORE;
}
- /* Found a symlink if len 0. If component == 0, then the
+ /* Found a symlink if symlen 0. If component == 0, then the
src path itself was a symlink. If !follow_mode then
we're done. Otherwise we have to insert the path found
into the full path that we are building and perform all of
these operations again on the newly derived path. */
- else if (len 0)
+ else if (symlen 0)
{
saw_symlinks = 1;
if (component == 0 !need_directory !(opt PC_SYM_FOLLOW))
@@ -712,56 +712,50 @@ path_conv::check (const char *src, unsig
MALLOC_CHECK;
- /* The tail is pointing at a null pointer. Increment it and get the length.
-If the tail was empty then this increment will end up pointing to the extra
-\0 added to path_copy above. */
- int taillen = strlen (++tail);
- int buflen = strlen (sym.contents);
- if (buflen + taillen CYG_MAX_PATH)
- {
- error = ENAMETOOLONG;
- strcpy (path, ::ENAMETOOLONG::);
- return;
- }
- /* Strip off current directory component since this is the part that refers
-to the symbolic link. */
- char * p;
- if ((p = strrchr (path_copy, '/')) == NULL)
- p = path_copy;
- else if (p == path_copy)
- p++;
- *p = '\0';
+ /* Place the link content, possibly with head and/or tail, in tmp_buf */
char *headptr;
if (isabspath (sym.contents))
headptr = tmp_buf; /* absolute path */
else
{
- /* Copy the first part of the path and point to the end. */
- strcpy (tmp_buf, path_copy);
- headptr = strchr (tmp_buf, '\0');
+ /* Copy the first part of the path (with ending /) and point to the end. */
+ char *prevtail = tail;
+ while (--prevtail path_copy *prevtail != '/') {}
+ int headlen = prevtail - path_copy + 1;;
+ memcpy (tmp_buf, path_copy, headlen);
+ headptr = tmp_buf[headlen];
}
- /* See if we need to separate first part + symlink contents with a / */
- if (headptr tmp_buf headptr[-1] != '/')
- *headptr++ = '/';
-
- /* Copy the symlink contents to the end of tmp_buf.
-Convert slashes. FIXME? */
- for (p = sym.contents; *p; p++)
+ /* Make sure there is enough space */
+ if (headptr + symlen = tmp_buf + sizeof (tmp_buf))
+{
+ too_long:
+ error = ENAMETOOLONG;
+ strcpy (path, ::ENAMETOOLONG::);
+ return;
+ }
+
+ /* Copy the symlink contents to the end of tmp_buf.
+ Convert slashes. FIXME? I think it's fine / Pierre */
+ for (char *p = sym.contents; *p; p++)
*headptr++ = *p == '\\' ? '/' : *p;
-
- /* Copy any tail component */
- if (tail = path_end)
- *headptr =
Re: /etc/passwd - /proc/mkpasswd
On Apr 3 19:48, Gerald Villemure wrote: I wonder if it would be possible to do something like this: /etc/passwd - /proc/mkpasswd /etc/group - /proc/mkgroup These sym links would make the 2 files dynamic and would simplify setup somewhat. OTOH, it would make the layout of these files rather static. What if the files should contain accounts from multiple domains? What if you want to map a Windows user name with spaces into a Cygwin user name witout spaces? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- 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: /etc/passwd - /proc/mkpasswd
- Original Message - From: Corinna Vinschen [EMAIL PROTECTED] On Apr 3 19:48, Gerald Villemure wrote: I wonder if it would be possible to do something like this: /etc/passwd - /proc/mkpasswd /etc/group - /proc/mkgroup These sym links would make the 2 files dynamic and would simplify setup somewhat. OTOH, it would make the layout of these files rather static. What if the files should contain accounts from multiple domains? What if you want to map a Windows user name with spaces into a Cygwin user name witout spaces? I agree the user should have a choice, thats why its a sym link. If you want custom files then break the sym link and create the files manualy. Gérald -- 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: difference between mingw and cygwin-mingw
At 11:38 PM 4/2/2004, you wrote: Folks, what is the difference between vanilla mingw and the one shipped with cygwin? in particular, what is the difference between the gcc compiler flavors? See http://cygwin.com/ml/cygwin/2004-04/msg00111.html. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.
From: David Fritz Sent: Sunday, April 04, 2004 6:46 AM Charles Wilson wrote: [...] (2) it's an attempt to prevent users from permanently scrogging binary files. See: d2u, on a binary file, is an irreversible operation. So, if you do d2u * you'll probably kill something deep inside some binary file, and you can't fix it -- unless some minimal safeguards are in place. u2d MAY be reversible -- IF there were no pre-exising \r\n combinations in the file to begin with -- so when (OMG-fixit-)d2u is run, obviously the first '\n' is preceeded by a (newly-added) '\r\n', so the prog merrily replaces ALL '\r\n' with '\n'...which MAY fix your oops, but maybe not. So, with the current code, if you snarf the first line -- all chars until the first '\n' -- if it's a binary file the odds are pretty low that the immediately-preceeding character is a '\r' -- so d2u as currently coded will bail out, and no harm is done. It doesn't work so well in the other direction -- by the same logic above, you'll almost never bail out early if you run 'u2d' on a binary file -- but if you immediately do a 'd2u' you MIGHT be able to recover.) [...] If detection of binary files is desirable, why not use an explicit test with a more robust methodology? GNU grep detects binary files by looking for a '\0' byte. Such a test could be used by both d2u and u2d; they could bail out with a message like skipping binary file. Cheers A more foolproof (? does such a thing exist) test would be to disallow using d2u/u2d on anything in directories found in $PATH. But then that one has its disadvantages too, but less so IMO. I find all this safety related stuff be a PITA at times. Any kind of test is prone to fail at some instances; at other instances just a cause for confusion most of the time - a lot of bug-hunting - for so little gain. How about running d2u/u2d, say, on a regedit 5 file (ie; mostly ascii but due to the coding every other character is a NUL)? Would that be considered legal? IMO it should, a fast and easy way to strip the garbage - to create a file that can be used with normal tools. IMO; stay away from all of this safety thingies, at _LEAST_ allow them to be bystepped; e.g. --force. I will be using that switch all the time. There are a lot of these foolhardy traps one can fall into; e.g: $ cd /;rm -rf * are you gonna find a safety hatch for that too? Noo... Please, remove all of these safety checks. There must be some kind of user sanity presupposition. Or else the tools soon will be crippled to a state where they are unusable for normal work. Make Backups, Not War! - MBNW! ;-P /Hannu E K Nevalainen, B.Sc. EE - 59+16.37'N, 17+12.60'E ** on a mailing list; please keep replies on that particular list ** -- printf(LocalTime: UTC+%02d\n,(DST)? 2:1); -- --END OF MESSAGE-- -- 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: UDP socket select/recvfrom problem when no server
From: Christopher J. White I've got a UDP socket application that fails since my most recent upgrade, I believe from 1.5.9 to 1.5.9-1. Basic UDP app that fails as follows: SNIP I suspect that the destination is returning an ICMP error when the server is not running and that is what's giving select() something to look at. However, it's my understanding that unless I do a connect(), ICMP errors are not propogated to the app. In addition, errno should be ECONNREFUSED in this case, and not ECONNRESET. ...cj May I suggest that you download Ethereal (and winpcap if using windows). Then capture and analyze traffic, instead of guessing. ;-) - ethereal.com /Hannu E K Nevalainen, B.Sc. EE - 59+16.37'N, 17+12.60'E ** on a mailing list; please keep replies on that particular list ** -- printf(LocalTime: UTC+%02d\n,(DST)? 2:1); -- --END OF MESSAGE-- -- 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: cygheap problems, 20040326 snapshot
On Sun, Apr 04, 2004 at 12:16:06AM -0500, Mark Blackburn wrote: Christopher Faylor wrote: On Fri, Apr 02, 2004 at 08:27:32PM -0500, Mark Blackburn wrote: Brian Ford wrote: On Mon, 29 Mar 2004, Mark Blackburn wrote: No it isn't. I recently tried my own build of cygwin: Could you possibly build it with the attached patch and report the strace output? Also, if you could scan cygwin/winsup/cygwin/how-to-debug-cygwin.txt, it will tell you how to get a working gdb to debug this. The output of info dll would be interesting. Thanks. Unfortunately the failure doesn't occur when things (gdb cygstart) are run under strace. Here's the output when run normally: Use the error_start option to the CYGWIN environment variable. It will cause gdb to pop up when the error occurs. I tried setting error_start as explained in winsup/cygwin/how-to-debug-cygwin.txt. However, gdb doesn't pop up when this error occurs. All I get is the same error message as before. I'm going to try Pierre's patch next. configure with --enable-debugging. -- 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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.
On Sat, 3 Apr 2004, David Fritz wrote: Charles Wilson wrote: [...] (2) it's an attempt to prevent users from permanently scrogging binary files. See: d2u, on a binary file, is an irreversible operation. So, if you do d2u * you'll probably kill something deep inside some binary file, and you can't fix it -- unless some minimal safeguards are in place. u2d MAY be reversible -- IF there were no pre-exising \r\n combinations in the file to begin with -- so when (OMG-fixit-)d2u is run, obviously the first '\n' is preceeded by a (newly-added) '\r\n', so the prog merrily replaces ALL '\r\n' with '\n'...which MAY fix your oops, but maybe not. So, with the current code, if you snarf the first line -- all chars until the first '\n' -- if it's a binary file the odds are pretty low that the immediately-preceeding character is a '\r' -- so d2u as currently coded will bail out, and no harm is done. It doesn't work so well in the other direction -- by the same logic above, you'll almost never bail out early if you run 'u2d' on a binary file -- but if you immediately do a 'd2u' you MIGHT be able to recover.) [...] If detection of binary files is desirable, why not use an explicit test with a more robust methodology? GNU grep detects binary files by looking for a '\0' byte. Such a test could be used by both d2u and u2d; they could bail out with a message like skipping binary file. Cheers Why not just call file? ...Before using d2u/u2d? And then call d2u/u2d --force. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- 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: zsh and line breaks
Bart Schaefer wrote: On Apr 2, 5:23pm, Peter A. Castro wrote: } } On Thu, 1 Apr 2004, Peter A. Castro wrote: } } So, now I need a ruling on just where to put this fix. I don't know that I can give you a ruling but in my opinion it would be fine to put this in main.c, appropriately #ifdef'd. I agree, there's nothing magic about main.c. The only reason it's short is because usually it's convenient for as much stuff as possible to be in zsh.dll, on systems where that needs to exist. Your case is exactly the opposite, so main.c is fine. -- Peter Stephenson [EMAIL PROTECTED] Work: [EMAIL PROTECTED] Web: http://www.pwstephenson.fsnet.co.uk -- 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: Loading gcc-compiled DLL with Java (JNI) crashes when using newer (1.5.5) cygwin1.dll
The correct switch is -mno-cygwin. -mno-cygwin should be equivalent to building with the mingw compiler unless you try to include cygwin header files or libraries, which is a common mistake. Chris, sorry that was I typo in my posting! I used gcc -mno-cygwin rather than -no-cygwin, and this did NOT produce a working dll mingw-gcc did! thx for responding, H. -- 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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.
Noo... Please, remove all of these safety checks. There must be some kind of user sanity presupposition. Or else the tools soon will be crippled to a state where they are unusable for normal work. FWIW I'm with Hannu. Should rm ask you, Do you *really* want to delete this file?, or make a backup of every file you delete (ala the Recycle Bin)? It should according to the thinking in this thread. -- 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: Running Postgresql 7.4.2 on Windows 2000 with Cygwin !
Jan, On Sun, Apr 04, 2004 at 03:15:03PM +0200, JC Jan Christensen wrote: and downloaded the file : cygipc-2.03-2.tar.bz2 and installed the cygipc-daemon in the file. The above is a bad thing to do. See below for why. I have downloaded the file postgresql-7.4.2.tar.gz and unpacked it and run the following commands: ./configure make make install The above just built a version of PostgreSQL against cygserver not cygipc. I have made a shell-script that contains the following lines: ipc-daemon2 You are running cygipc not cygserver. initdb -D /usr/local/pgsql/data postmaster -i -n -d 2 -D /usr/local/pgsql/data When I run this shell-script I get the following error-message from initdb : FATAL: could not create shared memory segment: Function not implemented DETAIL: Failed system call was shmget(key=1, size=1081344, 03600) initdb: failed What is wrong here ??? You are building against cygserver and running against cygipc. This is guaranteed not to work. How can I solve this problem Build and run against the same IPC implementation. My suggestion is to install both the cygipc and postgresql packages via Cygwin's setup.exe instead of manually installing cygipc and trying to build your own PostgreSQL version. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.
On Sun, 4 Apr 2004, GARY VANSICKLE wrote: Noo... Please, remove all of these safety checks. There must be some kind of user sanity presupposition. Or else the tools soon will be crippled to a state where they are unusable for normal work. FWIW I'm with Hannu. Should rm ask you, Do you *really* want to delete this file?, or make a backup of every file you delete (ala the Recycle Bin)? It should according to the thinking in this thread. That's what the -i flag is for. :-) But guess what? It's not the default! IOW, I agree here. The safety checks don't work (as I showed in http://cygwin.com/ml/cygwin/2004-04/msg00116.html), and they prevent a legitimate use of the program. If you really want to be safe, run file before running d2u/u2d. Or, leave the safety checks in, but only if a --safe (or whatever the appropriate name is) flag is given. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- 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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.
You guys are missing the point. Charles Wilson mentioned a side effect of the code at issue in the original post and suggested that it was valuable. Personally, I don't care if they attempt to detect binary files or not. My point was (and is) that: *If detection of binary files is desirable*, then why not implement it in a more robust manner and inform the user rather than silently skipping binary files. Hannu E K Nevalainen wrote: From: David Fritz Sent: Sunday, April 04, 2004 6:46 AM Charles Wilson wrote: [...] (2) it's an attempt to prevent users from permanently scrogging binary files. See: d2u, on a binary file, is an irreversible operation. So, if you do d2u * you'll probably kill something deep inside some binary file, and you can't fix it -- unless some minimal safeguards are in place. u2d MAY be reversible -- IF there were no pre-exising \r\n combinations in the file to begin with -- so when (OMG-fixit-)d2u is run, obviously the first '\n' is preceeded by a (newly-added) '\r\n', so the prog merrily replaces ALL '\r\n' with '\n'...which MAY fix your oops, but maybe not. So, with the current code, if you snarf the first line -- all chars until the first '\n' -- if it's a binary file the odds are pretty low that the immediately-preceeding character is a '\r' -- so d2u as currently coded will bail out, and no harm is done. It doesn't work so well in the other direction -- by the same logic above, you'll almost never bail out early if you run 'u2d' on a binary file -- but if you immediately do a 'd2u' you MIGHT be able to recover.) [...] If detection of binary files is desirable, why not use an explicit test with a more robust methodology? GNU grep detects binary files by looking for a '\0' byte. Such a test could be used by both d2u and u2d; they could bail out with a message like skipping binary file. Cheers A more foolproof (? does such a thing exist) test would be to disallow using d2u/u2d on anything in directories found in $PATH. But then that one has its disadvantages too, but less so IMO. I find all this safety related stuff be a PITA at times. Any kind of test is prone to fail at some instances; at other instances just a cause for confusion most of the time - a lot of bug-hunting - for so little gain. How about running d2u/u2d, say, on a regedit 5 file (ie; mostly ascii but due to the coding every other character is a NUL)? Would that be considered legal? IMO it should, a fast and easy way to strip the garbage - to create a file that can be used with normal tools. Huh? u2d/d2u will not strip the garbage. For that use iconv; as in, $ iconv -f UTF-16LE -t UTF-8 in out IMO; stay away from all of this safety thingies, at _LEAST_ allow them to be bystepped; e.g. --force. I will be using that switch all the time. There are a lot of these foolhardy traps one can fall into; e.g: $ cd /;rm -rf * are you gonna find a safety hatch for that too? Noo... Please, remove all of these safety checks. There must be some kind of user sanity presupposition. Or else the tools soon will be crippled to a state where they are unusable for normal work. Make Backups, Not War! - MBNW! ;-P OLOCA? [...] Cheers -- 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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.
David Fritz wrote: You guys are missing the point. Charles Wilson mentioned a side effect of the code at issue in the original post and suggested that it was valuable. I think there is some misunderstanding about the cygutils package. I did not write any of it.(*) I do not defend any of the design decisions that were made by the original coders; it's no skin off my nose -- so comments like It should according to the thinking in this thread. fail to move me -- except as a data point that GVanSickle really REALLY dislikes the current behavior.g (*) Well, maybe the hexdump program or the silly ascii chart, but it's been so long I don't remember anymore. The d2u/u2d progs were some code I thought, back in the dawn of time, would be useful on the cygwin platform -- at least *I* had need of a dos2unix converter all the time. So I found the code, adapted it, and put it in my kit, which was called the misc package back then. Now, I remember, when first porting the code for cygwin, wondering WHY it did certain things certain ways -- especially the check the first line and bail out stuff. All I could figure, at the time, were the two reasons I posted in this thread. I never said I agree with those reasons -- personally, I hate 'rm -i' and the like. But *I am not willing* to unilaterally change behavior of tools that may adversely affect users, without a damn good reason. Unfortunately, it offends a single user's sensibilities -- even mine -- doesn't quite rise to that level. And THAT's why I asked for more discussion. I'm getting the feeling that a preponderance of users -- at least, the ones actually responding to this thread -- dislike the current behavior, or at least wouldn't mind a change away from the current Microsoft-Bob-like behavior. I'd like to see what some other users, who haven't yet stated their opinions, have to say... -- Chuck -- 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/
