Re: cat fionread usage bug?
Pádraig Brady wrote: I was just looking at this line in cat.c: http://url.ie/1aq1 if (input_pending) write_pending (outbuf, bpout); Shouldn't that be? if (!input_pending) write_pending (outbuf, bpout); Oh! You're right. That's a bug (mine): disabled optimization. The checkin I think is 790892db: Yes, indeed. Here's the URL: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=790892db Have you tried to demonstrate the unwanted behavior? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat fionread usage bug?
Jim Meyering wrote: Pádraig Brady wrote: I was just looking at this line in cat.c: http://url.ie/1aq1 if (input_pending) write_pending (outbuf, bpout); Shouldn't that be? if (!input_pending) write_pending (outbuf, bpout); Oh! You're right. That's a bug (mine): disabled optimization. The checkin I think is 790892db: Yes, indeed. Here's the URL: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=790892db Have you tried to demonstrate the unwanted behavior? The following should output 1 (printf 1; sleep 2; printf 3) | timeout 1s cat -v | wc -c If I change it as suggested above it does. Nobody has complained in the last 2 years, but I guess it's worth keeping the functionality. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat fionread usage bug?
Pádraig Brady wrote: Jim Meyering wrote: Pádraig Brady wrote: I was just looking at this line in cat.c: http://url.ie/1aq1 if (input_pending) write_pending (outbuf, bpout); Shouldn't that be? if (!input_pending) write_pending (outbuf, bpout); Oh! You're right. That's a bug (mine): disabled optimization. The checkin I think is 790892db: Yes, indeed. Here's the URL: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=790892db Have you tried to demonstrate the unwanted behavior? The following should output 1 (printf 1; sleep 2; printf 3) | timeout 1s cat -v | wc -c Nice. If I change it as suggested above it does. Nobody has complained in the last 2 years, but I guess it's worth keeping the functionality. I agree. Would you like to handle it? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat fionread usage bug?
Jim Meyering wrote: Pádraig Brady wrote: but I guess it's worth keeping the functionality. I agree. Would you like to handle it? will do ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat fionread usage bug?
Would you like to handle it? will do thanks! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat fionread usage bug?
Jim Meyering wrote: Would you like to handle it? will do attached From 5af58e0557198c464f39a2a0939c37941fdfd668 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com Date: Wed, 11 Mar 2009 11:39:33 + Subject: [PATCH] cat: Fix immediate output of processed data * NEWS: Mention the bugfix. * src/cat.c (cat): Fix the typo which stopped the writing of processed data before a blocking read() is done. * tests/misc/cat-buf: Add to ensure processed data is not buffered. --- NEWS |5 + src/cat.c |2 +- tests/misc/cat-buf | 41 + 3 files changed, 47 insertions(+), 1 deletions(-) create mode 100755 tests/misc/cat-buf diff --git a/NEWS b/NEWS index fd101a4..752173d 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,11 @@ GNU coreutils NEWS-*- outline -*- ** Bug fixes + cat once again immediately outputs data it has processed. + Previously it would have been buffered and only output if enough + data was read, or on process exit. + [bug introduced in coreutils-6.0] + comm's new --check-order option would fail to detect disorder on any pair of lines where one was a prefix of the other. For example, this would fail to report the disorder: printf 'Xb\nX\n'k; comm --check-order k k diff --git a/src/cat.c b/src/cat.c index 04eb204..da72c6e 100644 --- a/src/cat.c +++ b/src/cat.c @@ -339,7 +339,7 @@ cat ( input_pending = true; #endif - if (input_pending) + if (!input_pending) write_pending (outbuf, bpout); /* Read more input into INBUF. */ diff --git a/tests/misc/cat-buf b/tests/misc/cat-buf new file mode 100755 index 000..fb9ae88 --- /dev/null +++ b/tests/misc/cat-buf @@ -0,0 +1,41 @@ +#!/bin/sh +# Ensure that cat outputs processed data immediately. + +# Copyright (C) 2009 Free Software Foundation, Inc. + +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +if test $VERBOSE = yes; then + set -x + cat --version +fi + +. $srcdir/test-lib.sh + +# Use a fifo rather than a pipe in the tests below +# so that the producer (cat) will wait until the +# consumer (dd) opens the fifo therefore increasing +# the chance that dd will read the data from each +# write separately. +mkfifo fifo || framework_failure + +echo '1' exp + +dd count=1 if=fifo out 2 err +(echo '1'; sleep .2; echo '2') | cat -v fifo +wait #for dd to complete + +compare out exp || fail=1 + +Exit $fail -- 1.5.3.6 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat fionread usage bug?
Pádraig Brady wrote: Jim Meyering wrote: Would you like to handle it? will do attached oops, previous one didn't update tests/Makefile.am From 11e4014d8c8ffa0e26f8c4518e5e19ef9159869d Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com Date: Wed, 11 Mar 2009 11:39:33 + Subject: [PATCH] cat: Fix immediate output of processed data * NEWS: Mention the bugfix. * src/cat.c (cat): Fix the typo which stopped the writing of processed data before a blocking read() is done. * tests/misc/cat-buf: Add to ensure processed data is not buffered. * tests/Makefile.am: Reference the new test --- NEWS |5 + src/cat.c |2 +- tests/Makefile.am |1 + tests/misc/cat-buf | 41 + 4 files changed, 48 insertions(+), 1 deletions(-) create mode 100755 tests/misc/cat-buf diff --git a/NEWS b/NEWS index fd101a4..752173d 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,11 @@ GNU coreutils NEWS-*- outline -*- ** Bug fixes + cat once again immediately outputs data it has processed. + Previously it would have been buffered and only output if enough + data was read, or on process exit. + [bug introduced in coreutils-6.0] + comm's new --check-order option would fail to detect disorder on any pair of lines where one was a prefix of the other. For example, this would fail to report the disorder: printf 'Xb\nX\n'k; comm --check-order k k diff --git a/src/cat.c b/src/cat.c index 04eb204..da72c6e 100644 --- a/src/cat.c +++ b/src/cat.c @@ -339,7 +339,7 @@ cat ( input_pending = true; #endif - if (input_pending) + if (!input_pending) write_pending (outbuf, bpout); /* Read more input into INBUF. */ diff --git a/tests/Makefile.am b/tests/Makefile.am index 07e9473..10be0c6 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -149,6 +149,7 @@ TESTS = \ misc/wc-files0-from\ misc/wc-files0\ misc/cat-proc \ + misc/cat-buf \ misc/base64 \ misc/basename \ misc/close-stdout\ diff --git a/tests/misc/cat-buf b/tests/misc/cat-buf new file mode 100755 index 000..fb9ae88 --- /dev/null +++ b/tests/misc/cat-buf @@ -0,0 +1,41 @@ +#!/bin/sh +# Ensure that cat outputs processed data immediately. + +# Copyright (C) 2009 Free Software Foundation, Inc. + +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +if test $VERBOSE = yes; then + set -x + cat --version +fi + +. $srcdir/test-lib.sh + +# Use a fifo rather than a pipe in the tests below +# so that the producer (cat) will wait until the +# consumer (dd) opens the fifo therefore increasing +# the chance that dd will read the data from each +# write separately. +mkfifo fifo || framework_failure + +echo '1' exp + +dd count=1 if=fifo out 2 err +(echo '1'; sleep .2; echo '2') | cat -v fifo +wait #for dd to complete + +compare out exp || fail=1 + +Exit $fail -- 1.5.3.6 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat fionread usage bug?
Pádraig Brady wrote: Jim Meyering wrote: Would you like to handle it? will do attached From 5af58e0557198c464f39a2a0939c37941fdfd668 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com Date: Wed, 11 Mar 2009 11:39:33 + Subject: [PATCH] cat: Fix immediate output of processed data * NEWS: Mention the bugfix. * src/cat.c (cat): Fix the typo which stopped the writing of processed data before a blocking read() is done. * tests/misc/cat-buf: Add to ensure processed data is not buffered. Looks fine. Thanks again. Would you please include here, in the log, the SHA1 that introduces the bug? i.e., Introduced by commit 790892db, 2006-06-08 Ensure that cat works --- NEWS |5 + src/cat.c |2 +- tests/misc/cat-buf | 41 + 3 files changed, 47 insertions(+), 1 deletions(-) create mode 100755 tests/misc/cat-buf diff --git a/NEWS b/NEWS index fd101a4..752173d 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,11 @@ GNU coreutils NEWS-*- outline -*- ** Bug fixes + cat once again immediately outputs data it has processed. + Previously it would have been buffered and only output if enough + data was read, or on process exit. + [bug introduced in coreutils-6.0] ... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
On Jan 16, 2008 12:41 AM, [EMAIL PROTECTED] wrote: J But the main problem is to figure out where to put such a document J so that new users will actually read it. What do you think? Somewhere around $ info -o - coreutils|grep -C 2 Intro I'm not sure sure about that at all, because the problem applies to all tools, not just coreutils. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
[EMAIL PROTECTED] wrote: Bet you don't document anywhere that/why $ echo a|cat - - will only give one a. Or maybe even raise an error... Seems obvious to me. Perhaps the following is more obvious :) $ echo mouse | cat - - Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
On Monday 14 January 2008, [EMAIL PROTECTED] wrote: Bet you don't document anywhere that/why $ echo a|cat - - will only give one a. what were you expecting to happen ? it is not possible for cat to re-read stdin once it has consumed it. -mike signature.asc Description: This is a digitally signed message part. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
MF what were you expecting to happen ? it is not possible for cat to MF re-read stdin once it has consumed it. Yes, but you don't document it I bet. At least not in the path that starts with man cat. Just reading the coreutils docs, one wouldn't know why $ date|cat q b - c q - q - b worked except stdin only showed up once... Hmmm maybe also some pipes would also... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
On Tuesday 15 January 2008, [EMAIL PROTECTED] wrote: what were you expecting to happen ? it is not possible for cat to re-read stdin once it has consumed it. Yes, but you don't document it I bet. At least not in the path that starts with man cat. Just reading the coreutils docs, one wouldn't know why $ date|cat q b - c q - q - b worked except stdin only showed up once... Hmmm maybe also some pipes would also... this isnt a cat/coreutils/stdin specific issue. *any* program that consumes a read-destructive source would have the same problem. at the basic level, cat is functioning correctly: you told it to read from stdin as much as it could and that is exactly what cat did. the fact that stdin was empty after the first time means you got no output the second+ time around. you could make the same argument that if you wrote to a fifo and tried to cat it multiple times, cat was misbehaving. -mike signature.asc Description: This is a digitally signed message part. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
Yes yes. I'm just saying supposing a theoretical new user's first encounter with all this stuff was the document trail that started with the cat man page, then he would think - was broken. So still an understanding of Unix is implied as the docs perhaps describe 95% but not yet 100% of what one needs to know. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
On Jan 16, 2008 12:01 AM, [EMAIL PROTECTED] wrote: Yes yes. I'm just saying supposing a theoretical new user's first encounter with all this stuff was the document trail that started with the cat man page, then he would think - was broken. The best place to document this could well be a new-user document. Explaining that once you've read all the data from a pipe, you can't rewind it, and explaining that in one place is probably more helpful than stating it as a caveat on the handling of - in hundreds of utilities. Such a document would also be a good place to explain the handling of wildcards and so forth too. But the main problem is to figure out where to put such a document so that new users will actually read it. What do you think? So still an understanding of Unix is implied as the docs perhaps describe 95% but not yet 100% of what one needs to know. I think exposition of general principles probably belongs somewhere else. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat - -
J But the main problem is to figure out where to put such a document J so that new users will actually read it. What do you think? Somewhere around $ info -o - coreutils|grep -C 2 Intro ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat binary files bug
On 6/6/07, Alexander Meyr [EMAIL PROTECTED] wrote: hi there.. dont know if its a known bug. ill try to describe: using backtrack v2 final kernel 2.6.20 I have no idea what that is. problem using cat when input is a executive file like /bin/ls. cat displays the file and when finished the shell is shown in unreadable characters. Terminals are controlled by sending special characters to them. Binary files contain lots of bytes containing all kinds of values, some of which correspond to control codes that change the state of your terminal. Sending those control codes to your terminal by cating a binary file will change your terminal's state in ways which you obviously didn't expect. If you don't want your terminal to change state in odd ways like this, don't send the contents of a binary file to your terminal. If you just want to see what is in the file, use hexdump -C filename or file filename. Try reading the manual pages for these two utilities. To return your terminal to some kind of normal state after accidentally sending a binary file to it, you can usually use reset (on GNU/Linux systems) or tput rs (on GNU/Linux systems and most other Unix systems). James ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat binary files bug
Alexander Meyr wrote: dont know if its a known bug. ill try to describe: Thanks for the report however what you are describing is not a bug in the 'cat' program but a misuse of it. using backtrack v2 final kernel 2.6.20 This behavior is not related to the kernel. It is related to the terminal being used however. problem using cat when input is a executive file like /bin/ls. cat displays the file and when finished the shell is shown in unreadable characters. The 'cat' program concatenates files on input and writes the contents to the output. It is *not* intended as a binary file viewer. Doing so is a misuse of the program and the cause of your problem. By writing the binary file contents to your terminal you will almost certainly cause it to do strange things. Terminals interpret characters written to them and perform the required terminal control operation. Binary input such as from executables written to the terminal will often randomly hit upon terminal control sequences that place the terminal into particular states and without the corresponding sequence to return it to normal function they will be left in an unusable state. Normal programs accessing those terminal control sequences will perform the intended behavior and issue further byte codes to return the terminal to an expected state. Disabling terminal control sequences is not possible becuase then they would not be available to normal programs. Since the purpose of 'cat' is to concatenate files it must not modify or filter the files in the process. What goes in should come out. The 'cat' program is typically used to assemble parts of files together. To browse files you should use a file browser such as 'more', 'less', 'most', or other programs that act as terminal pagers. For binary files it may be more useful to use 'od -tx1', 'hexdump', 'xxd' or other program that converts binary data into text codes and then piping the output to a pager. It is historically traditional on Unix-like systems to use cat to write short text files to the terminal. However this is done with full knowledge that it only behaves as desired on short text files that do not contain terminal control sequences. If they do then the user running cat to write the file to the terminal must be prepared to accept the consequences and be able to reset the terminal if needed. Hope this helps, Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat bug on cygwin
Eric Blake [EMAIL PROTECTED] wrote:
...
I'm wondering if we could just add something like this to the binary-io
module, which we can then update as needed to compensate for any other
irregularities discovered in swapping stdio to binary mode:
I like it.
I know the code below is just a sketch, but here's some feedback.
fsetbinary (fp) can be defined to just (fp) when O_BINARY is 0 or
undefined. Then, we can clean up related code in coreutils like this:
diff --git a/src/cksum.c b/src/cksum.c
index 7b65c73..4bd05df 100644
--- a/src/cksum.c
+++ b/src/cksum.c
@@ -194,14 +194,12 @@ cksum (const char *file, bool print_name)
if (STREQ (file, -))
{
- fp = stdin;
+ fp = fsetbinary (stdin);
have_read_stdin = true;
- if (O_BINARY ! isatty (STDIN_FILENO))
- freopen (NULL, rb, stdin);
}
else
{
- fp = fopen (file, (O_BINARY ? rb : r));
+ fp = fsetbinary (fopen (file, r));
if (fp == NULL)
{
error (0, errno, %s, file);
Of course, that means your fsetbinary has to return NULL
immediately when the input FP is NULL.
/* Make sure FP is in binary mode. Return FP on success,
NULL on failure. */
FILE *
fsetbinary (FILE *fp)
{
Insert this (after hoisting decls, I presume):
if (fp == NULL)
return NULL;
I'd tend to not set errno, on the presumption that
it was set already by the surrounding code (as in the cksum/fopen
case above), but that isn't necessarily the case.
Something to think about...
#ifdef __CYGWIN__
int mode = fcntl (fileno (fp), F_GETFL);
char *str;
char const *str;
switch (mode (O_ACCMODE | O_APPEND))
{
case O_RDONLY: str = rb; break;
case O_WRONLY: str = wb; break;
case O_RDWR: str = r+b; break;
case O_WRONLY | O_APPEND: str = ab; break;
case O_RDWR | O_APPEND: str = a+b; break;
default: str = NULL;
}
if (!str)
{
fclose (fp);
errno = EBADF;
return NULL;
}
# ifdef simple
return freopen (NULL, str, fp);
# else
fp = freopen (NULL, str, fp);
if (fp)
{
fcntl (fileno (fp), F_SETFL, mode);
I assume this is a can't fail situation for Cygwin, too.
}
return result;
s/result/fp/
# endif
#else
/* I'm not sure how mingw behaves with freopen(NULL,...). */
SET_BINARY (fileno (fp));
return fp;
#endif
}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat bug on cygwin
Eric Blake [EMAIL PROTECTED] wrote: ... I'm wondering if we could just add something like this to the binary-io module, which we can then update as needed to compensate for any other irregularities discovered in swapping stdio to binary mode: /* Make sure FP is in binary mode. Return FP on success, NULL on failure. */ FILE * fsetbinary (FILE *fp) In coreutils, we'd also need a function to operate on a file descriptor, like SET_BINARY does. Maybe SET_BINARY itself, after all. I know Paul eradicated all uses of SET_BINARY in coreutils a couple years ago, but since there's an actual problem now, and all of this code will be compiled out for unix-based systems, I have no qualms about going back to the use of SET_BINARY. Eric, do you feel like doing this? It'd be great if you would also add a test or two that demonstrate how the current implementations fail on Cygwin. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat bug on cygwin
Eric Blake [EMAIL PROTECTED] writes: I'm wondering how many of the other coreutils that use this freopen trick are affected, Five more: head, tac, tail, tee, and tr. and whether we should use a wrapper function rather than duplicating all the logic. My kneejerk reaction is to duplicate the logic. Most likely we'll run into further problems like this, no? E.g., suppose stdout is open for both read and write, and we use wb on it? Won't we screw it up? (What a hassle.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat bug on cygwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 5/30/2007 4:46 PM:
Eric Blake [EMAIL PROTECTED] writes:
I'm wondering how many of the other coreutils that use this freopen trick
are
affected,
Five more: head, tac, tail, tee, and tr.
The full list:
cat, cksum, head, md5sum (and thus sha*sum), tac, tail, tee, tr
and whether we should use a wrapper function rather than duplicating
all the logic.
My kneejerk reaction is to duplicate the logic.
Most likely we'll run into further problems like this, no? E.g.,
suppose stdout is open for both read and write, and we use wb on it?
Won't we screw it up?
Nope. Cygwin's freopen is smart enough to allow any subset of permissions
in the mode argument which are compatible with the underlying permissions
of the fd. POSIX states that stdout is only open for writing on program
startup, even if the fd is open O_RDWR, so coreutils' existing use of wb
is correct modulo append flag. But even if you do
freopen(file,w+,stdout), a later freopen(NULL,wb,stdout) is not a
problem. However, it is a bummer that POSIX states that freopen(NULL) is
implementation defined, so I can only guarantee cygwin's behavior.
I'm wondering if we could just add something like this to the binary-io
module, which we can then update as needed to compensate for any other
irregularities discovered in swapping stdio to binary mode:
/* Make sure FP is in binary mode. Return FP on success,
NULL on failure. */
FILE *
fsetbinary (FILE *fp)
{
#ifdef __CYGWIN__
int mode = fcntl (fileno (fp), F_GETFL);
char *str;
switch (mode (O_ACCMODE | O_APPEND))
{
case O_RDONLY: str = rb; break;
case O_WRONLY: str = wb; break;
case O_RDWR: str = r+b; break;
case O_WRONLY | O_APPEND: str = ab; break;
case O_RDWR | O_APPEND: str = a+b; break;
default: str = NULL;
}
if (!str)
{
fclose (fp);
errno = EBADF;
return NULL;
}
# ifdef simple
return freopen (NULL, str, fp);
# else
fp = freopen (NULL, str, fp);
if (fp)
{
fcntl (fileno (fp), F_SETFL, mode);
}
return result;
# endif
#else
/* I'm not sure how mingw behaves with freopen(NULL,...). */
SET_BINARY (fileno (fp));
return fp;
#endif
}
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGXhZn84KuGfSFAYARAuh8AJ9t5fgfL3wSIivp+4SIHzxna59a8gCgxO1D
acSJCXRmeDRJCaxoFyTly1Q=
=z78R
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Cat not showing last lines in file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dombrowski, Al on 3/15/2007 10:15 AM: Hello, Cat is not showing the last lines in a file consistently. Sometimes it does and most of the times it doesn't. This has always been the case for me for months now. I thought this issue would be fixed by now. Perhaps it is some configuration issue. You are better off reporting issues with the cygwin version of cat to the cygwin mailing list, cygwin AT cygwin DOT com, since more likely than not, your problem is not with upstream cat, but with how cat interacts with Windows. Many of the details in your message make no sense to most people on this list, but are readily interpreted by the cygwin folks. However, I use cat on cygwin, and do not suffer from your problem. So I would be glad to further explore this issue with you on the cygwin list. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+p3z84KuGfSFAYARApyJAJ9oKJwh5SbXlI4mLDOEH5nj1jQkGgCeK8YJ dlVhgOEtitYeVg/TqoxzNjs= =59Qd -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: 'cat' doesn't check close(STDOUT_FILENO)'s return value
Paul Eggert [EMAIL PROTECTED] wrote: On some operating systems, notices of output errors are sometimes delayed until you close the file. However, in the normal case coreutils 'cat' doesn't check the return value from 'close(STDOUT_FILENO)'. I installed this patch. 2005-12-13 Paul Eggert [EMAIL PROTECTED] * src/cat.c (main): Check for close (STDOUT_FILENO) failure. Thanks, but why is that needed? I was convinced that the existing `atexit (close_stdout)' covered all the bases, since close_stdout calls `fclose (stdout)' unconditionally, and that does the equivalent of `close (STDOUT_FILENO)'. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat in locale ru_RU.utf8 or this is the bash issue?
Peter Volkov Alexandrovich [EMAIL PROTECTED] writes: The last question I have, where can I download coreutils-5.3.0? Or this is the future release? See http://lists.gnu.org/archive/html/coreutils-announce/2004-03/msg1.html. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat in locale ru_RU.utf8 or this is the bash issue?
Peter Volkov Alexandrovich [EMAIL PROTECTED] writes: I should get the same string again. But if I misstyped and then edited my words in russian language with backspace then next line differs from the previous. So if I type: backspace the first line will be: but the second Try stty iutf8 to tell the terminal that input is encoded in UTF-8. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstrae 5, 90409 Nrnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat in locale ru_RU.utf8 or this is the bash issue?
Hi, On Tue, Jan 11, 2005 at 11:29:40PM +0300, Peter Volkov Alexandrovich wrote: I've changed my locale to ru_RU.utf8 and now I have some problem is with cat utilty. When I do: $ cat words in russianenter I should get the same string again. But if I misstyped and then edited my words in russian language with backspace then next line differs from the previous. So if I type: backspace the first line will be: but the second ??? As you can see 3-d character changed. It is not ``. This is terminal issue, not related to coreutils at all. Have a look at this transcript: $ cat |od -a 000 P 0 P 1 P 2 nl 007 $ cat |od -a backspace 000 P 0 P 1 P P 2 nl 010 $ cat |od -a backspacebackspace 000 P 0 P 1 P 2 nl 007 When you hit backspace, your terminal driver erases only last byte of the two-byte symbol ''. -- ldv pgpq4evmRpXYj.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat in locale ru_RU.utf8 or this is the bash issue?
On Tue, Jan 11, 2005 at 11:00:15PM +0100, Andreas Schwab wrote: Peter Volkov Alexandrovich [EMAIL PROTECTED] writes: I should get the same string again. But if I misstyped and then edited my words in russian language with backspace then next line differs from the previous. So if I type: backspace the first line will be: but the second ??? Try stty iutf8 to tell the terminal that input is encoded in UTF-8. Andreas, your patch for stty which adds IUTF8 flag support appeared after coreutils-5.2.1 release, so Peter probably has to update coreutils first. -- ldv pgpG0GZ3h16ro.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cat file dabbles in locales?
Dan Jacobson [EMAIL PROTECTED] wrote: Jim That set-up is performed (via setlocale) for internationalized diagnostics. Maybe only do the set-up once we intend to actually give a diagnostic (but I didn't look at the source, so probably never mind.) But what if the error is that we're out of an important resource like file descriptors? Then we'd be unable to perform the initialization, so there'd be no way to give a proper diagnostic. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: cat /usr/X11R6/bin/xmodmap
Alexander Orlov wrote: If I type cat /usr/X11R6/bin/xmodmap I get into cryptical mode which can't be canceled in the normal way (Ctrl+C). Thank you for your report. But you are not seeing a bug. The terminal emulator you are using apparently is a smart terminal and reacts to escape sequences. One example would be xterm. The binary sequences of characters in the xmodmop binary are probably putting your terminal to graphics mode or something. Don't cat binaries to the terminal. It will only annoy you. Paul Jarc previously wrote (thanks Paul!): Binary files typically contain certain character sequences, purely by chance, that tell the terminal to do strange things. The terminal has this capability because occasionally it is genuinely useful, but the terminal cannot distinguish between cases where the special characters were intended to change the terminal's behavior and cases where they were only meant to be printed. You may be able to fix the terminal with the reset command. To keep it from happening, simply don't print random binary data to your terminal. You can safely view it using a pager like less, though, with the appropriate options In an 'xterm' you can use control-middle-button dragging down to Do Full Reset to tell the terminal emulator to reset back to a known state. That usually works well when the terminal has gotten into a bad state. The screen will be clear. A keyboard 'enter' will usually find yourself back at the command prompt. Bob ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Cat and -u, unbuffered output support
Paul Jarc wrote: Bob Proulx wrote: % stty raw % cat -u fi This may not work; the interactive shell may reset the tty modes after each command, so the first stty would bhave no effect. For shells that do that command line editing such as bash, zsh, etc. which reset the mode they also save the current stty settings before going into raw mode for the line edit. Therefore changing the mode with stty should be fine. The shell will read the new mode after the stty command, or indeed any command, and restore that mode when executing the next command. Because of the save and restore the mode is always ping-ponging back and forth between raw mode and cooked mode with every command. It needs to do that otherwise you would never be able to change the mode with stty. [Of course older shells such as the V7 Bourne shell do not do any command line editing and do not reset the modes.] Bob P.S. If you want to play with a shell in the old V7 Bourne command line editing mode you can use bash but turn off the edit modes. set +o vi set +o emacs stty -a Then note the 'werase' setting (usually ^W), the 'kill' setting (usually either ^U or ^X), and the 'rprnt' setting (usually ^R). Now at this try some line editing. echo one two three^W^R^U If nothing else this will convince you that having a full editor available is a really useful thing. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Cat and -u, unbuffered output support
Thanks for the reply, Bob! Maybe I'm misunderstanging the meaning of unbuffered. First, the vital statistics: [EMAIL PROTECTED]:~$ cat --version cat (coreutils) 5.0 ... [EMAIL PROTECTED]:~$ uname -a Linux vesper 2.4.20 #9 Sun Mar 30 11:29:43 PST 2003 i686 GNU/Linux Now, I want cat to send its data immediately, rather than waiting for a newline. Here's an illustration that can be run in a single shell: % mkfifo fi % cat -u fi % cat -u fi Now, if cat wrote each byte from the input to the output without delay, then typing abc\n into the fifo would produce aabbcc\n\n on the screen. Each character would be sent through the pipe and echoed immediately. However, the result of typing abc\n is abc\nabc\n. This implies that SOMEBODY (perhaps I was too hasty in implicating cat) is buffering the bytes up to the newline, then sending them in one big burst. Is this the expected behavior? - Scott On Mon, 2003-06-23 at 21:29, Bob Proulx wrote: Scott Bronson wrote: Hello. It is driving me nuts that GNU cat doesn't support the -u option. It it makes it difficult to port software from other Unix systems to GNU. But '-u' *is* accepted as a valid option to cat. It is ignored since Write bytes from the input file to the standard output without delay as each is read. as required by the standards is always the default with GNU cat. I don't see how this could be causing a portability problem for you. Scripts calling for 'cat -u' should work fine. Is there any reason that you chose to remove the -u feature? Would you accept a patch to add it back? Would you be so kind as to double check the version of 'cat' that you are using? And also perhaps what OS you are running on if that is important? This feature of 'cat' does not appear to have changed for a very long time. I suspect that you are not actually using GNU cat at all! cat --version uname -a Bob P.S. Note that the latest version is available here: http://ftp.gnu.org/pub/gnu/coreutils/ -- Scott Bronson [EMAIL PROTECTED] ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Cat and -u, unbuffered output support
Scott Bronson wrote: Thanks for the reply, Bob! Maybe I'm misunderstanging the meaning of unbuffered. First, the vital statistics: [EMAIL PROTECTED]:~$ cat --version cat (coreutils) 5.0 Very good. Thanks. Here's an illustration that can be run in a single shell: % mkfifo fi % cat -u fi % cat -u fi Ah, now I understand. Now, if cat wrote each byte from the input to the output without delay, then typing abc\n into the fifo would produce aabbcc\n\n on the screen. Each character would be sent through the pipe and echoed immediately. But there _is_ someplace where the input is being buffered. It is the tty line driver. It is what implements your ability to back up and delete characters implementing what is known as canonical imput mode. However, the result of typing abc\n is abc\nabc\n. This implies that SOMEBODY (perhaps I was too hasty in implicating cat) is buffering the bytes up to the newline, then sending them in one big burst. Is this the expected behavior? Modify your experiment this way: % mkfifo fi % cat -u fi % stty raw % cat -u fi It will be difficult to use a raw terminal. And you will probably need to kill the cat from another terminal since in raw mode there will be no eof processing. But in this mode you should see the aabbcc mode you were thinking you should be getting. Either Stevens with Advanced Programming in the UNIX Environment or Rochkind with Advanced UNIX Programming would be my references for detailed information about the tty driver. But I am sure it is documented elsewhere too. Bob ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Cat and -u, unbuffered output support
[EMAIL PROTECTED] (Bob Proulx) wrote: % stty raw % cat -u fi This may not work; the interactive shell may reset the tty modes after each command, so the first stty would bhave no effect. This might work: % sh -c 'stty raw; cat -u fi; stty sane' Either Stevens with Advanced Programming in the UNIX Environment or Rochkind with Advanced UNIX Programming would be my references for detailed information about the tty driver. But I am sure it is documented elsewhere too. The glibc manual has some good bits. paul ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: Cat and -u, unbuffered output support
Scott Bronson wrote: Hello. It is driving me nuts that GNU cat doesn't support the -u option. It it makes it difficult to port software from other Unix systems to GNU. But '-u' *is* accepted as a valid option to cat. It is ignored since Write bytes from the input file to the standard output without delay as each is read. as required by the standards is always the default with GNU cat. I don't see how this could be causing a portability problem for you. Scripts calling for 'cat -u' should work fine. Is there any reason that you chose to remove the -u feature? Would you accept a patch to add it back? Would you be so kind as to double check the version of 'cat' that you are using? And also perhaps what OS you are running on if that is important? This feature of 'cat' does not appear to have changed for a very long time. I suspect that you are not actually using GNU cat at all! cat --version uname -a Bob P.S. Note that the latest version is available here: http://ftp.gnu.org/pub/gnu/coreutils/ ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
