I missed the quote.
Sorry for my bad.
Kind regards
Am Sun, 04 Dec 2022 16:54:02 +
schrieb help-debb...@gnu.org (GNU bug Tracking System):
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been
On Dez 04 2022, th3_d0ctor wrote:
> $ echo "*" >b; for i in `cat b`; do echo "$i"; done
> ==> list current working directory instead of printing the wildcard '*'
That's how it is supposed to work, since file name expansion is
performed after all other expan
On 07/08/2021 14:07, Michael Debertol wrote:
Hi,
after https://lists.gnu.org/archive/html/coreutils/2021-02/msg3.html
(unreleased), the behavior of cat -E was changed so that it prints "^M$"
for "\r\n" line endings.
Whenever it sees a \r "cat -E" checks if t
Hi,
after https://lists.gnu.org/archive/html/coreutils/2021-02/msg3.html
(unreleased), the behavior of cat -E was changed so that it prints "^M$"
for "\r\n" line endings.
Whenever it sees a \r "cat -E" checks if the byte after is a \n, however
that
On 3/23/21 4:22 AM, Luís via GNU coreutils Bug Reports wrote:
In a reinstallation of Linux Mint 20 ( based on the ubuntu 20 focal fossa
), I found that the cat command, supported by the Coreutils package
(8.30-ubuntu2) is no longer working.
Please send a bug report to the Linux Mint
On 3/23/21 12:22 PM, Luís via GNU coreutils Bug Reports wrote:
> I found that the cat command, supported by the Coreutils package
> (8.30-ubuntu2) is no longer working.
That's quite a vague description, so no one will probably be able to help you
based on that.
What exactly happens wh
In a reinstallation of Linux Mint 20 ( based on the ubuntu 20 focal fossa
), I found that the cat command, supported by the Coreutils package
(8.30-ubuntu2) is no longer working. I tried to reinstall ( just reinstall,
because purge breaks the system, so I couldn't test removing possibly
Assaf Gordon wrote:
If the issue of cat(1) supporting socketpair/ECONNRESET instead of
pipes/EPIPE is still relevant, we can re-open the bug.
'cat' treats EPIPE on pipes the same way it treats ECONNRESET on socket pairs:
$ (trap '' PIPE; cat /usr/bin/emacs) | :
cat: write error: Broken pipe
close 9089
stop
(triaging old bugs)
Hello,
On 2011-07-15 5:30 a.m., Philipp Thomas wrote:
I'm trying to track down a bug in cat of coreutils 6.12. Doing
cat /var/log/Xorg.0.log | head -n70
under ksh consistently fails with 'cat: write error: Connection reset by
peer'. It does not fail when
tags 34115 notabug
close 34115
merge 34115 33823
stop
Hello,
On 2019-01-17 5:53 a.m., Ricky Tigg wrote:
[...]
$ cat > .inputrc
set enable-bracketed-paste on
Press *Return*, then *Ctrl D*.
[...]
Content of *.inputrc*, which is expected to be still present, has been
This sounds v
Hi. On *Fedora Desktop 29*, using *GNU bash*, v. 4.4.23(1), in a *GUI*
terminal emulator – *gnome-terminal* was used – under your home directory,
create if not present file *.inputrc* a follow:
$ cat > .inputrc
set enable-bracketed-paste on
Press *Return*, then *Ctrl D*.
$ cat .inputrc
tags 33824 notabug
close 33824
stop
Hello,
On 2018-12-21 8:32 a.m., Ricky Tigg wrote:
Command executed:
$ cat a* >> b*
bash: b*: ambiguous redirect
Thought the same syntax is used with success when applied only to source
files:
$ cat a* >> b
$
Probably a bug.
This
Component: coreutils.x86_64 8.30. Observation not reported at pixelbeat.org
<https://www.pixelbeat.org/docs/coreutils-gotchas.html>.
Command executed:
$ cat a* >> b*
bash: b*: ambiguous redirect
Thought the same syntax is used with success when applied only to source
files:
$
tags 33774 notabug
close 33774
stop
On 12/16/18 8:58 PM, Valentin Schild wrote:
> somehow, when using cat to display a file's content, I get output to
> the command line
> The file to output contains
> ^[Z
> like attached file "catbug".
>
> In terminal I type
Hi,
somehow, when using cat to display a file's content, I get output to
the command line
The file to output contains
^[Z
like attached file "catbug".
In terminal I type
cat catbug
catbug
Description: Binary data
close 14505
stop
(triaging old bugs)
On 29/05/13 11:19 PM, Kakkar, Mayank (NSN - IN/Bangalore) wrote:
Thanks. That was very informative.
With no further comments, I'm closing this bug.
-assaf
tag 30160 notabug
close 30160
stop
On 01/18/2018 01:31 PM, Rdrpenguin Minecraft and More wrote:
> If 'cat' is run with a big enough file, say /dev/sda, the terminal gets
> corrupted. This corruption may also extend beyond the terminal.
>
> Steps to reproduce:
> 1. Run '/bin/cat
If 'cat' is run with a big enough file, say /dev/sda, the terminal gets
corrupted. This corruption may also extend beyond the terminal.
Steps to reproduce:
1. Run '/bin/cat /dev/sda'.
2. Wait from 2 to 3 minutes.
3. Ctrl-C to exit.
4. Observe corrupted terminal
This was tested on gnome-terminal
tag 24007 notabug
thanks
On 07/16/2016 12:11 AM, NAVEEN KUMAR wrote:
> Hi Team,
>
> Greetings!
>
> I was sitting next my system looking for some basic code brush up and was
> playing with CAT command, and though of some kind of additional features to
> our
Hi Team,
Greetings!
I was sitting next my system looking for some basic code brush up and was
playing with CAT command, and though of some kind of additional features to
our existing CAT command, such as...
*"Write a CAT command program, which will allow appending text or lines of
Hello Paul
On 10/04/16 20:01, Paul Eggert wrote:
Jonny Grant wrote:
Hello
I noticed that cat doesn't have an accurate message in the following
use-case:
$ cat missingfile
cat: missingfile: No such file or directory
$ mkdir testdir
$ cat testdir
cat: testdir: Is a directory
Jonny Grant wrote:
Hello
I noticed that cat doesn't have an accurate message in the following use-case:
$ cat missingfile
cat: missingfile: No such file or directory
$ mkdir testdir
$ cat testdir
cat: testdir: Is a directory
The "No such file or directory" message occu
Hello
I noticed that cat doesn't have an accurate message in the following
use-case:
$ cat missingfile
cat: missingfile: No such file or directory
$ mkdir testdir
$ cat testdir
cat: testdir: Is a directory
I wrote up the details of the ENOENT problem here:
http://technoramauk.blogspot.co.uk
tag 20482 notabug
thanks
On 12/31/1969 05:00 PM, wrote:
I have noticed that when running 'cat' to look at certain files that for
some reason the end of the file is in a different embolden colour, which
then makes all of my Terminal text that colour as well as bold.
An example is when I ran
On Mon, Dec 15, 2014 at 9:11 PM, KO Myung-Hun kom...@gmail.com wrote:
Jim Meyering wrote:
On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun kom...@gmail.com wrote:
Paul Eggert wrote:
KO Myung-Hun wrote:
/* Redirection and wildcarding when done by the utility itself.
Generally a noop, but
/ginstall
-man/vdir.1: src/vdir
-
-man/base64.1:src/base64
-man/basename.1: src/basename
-man/cat.1: src/cat
-man/chcon.1: src/chcon
-man/chgrp.1: src/chgrp
-man/chmod.1: src/chmod
-man/chown.1: src/chown
-man/chroot.1:src/chroot
-man/cksum.1: src/cksum
reopen 19377
stop
On 19/12/14 01:13, KO Myung-Hun wrote:
GNU bug Tracking System wrote:
Your bug report
#19377: [PATCH 1/4] doc: add $(EXEEXT) suffix to the executables
which was filed against the coreutils package, has been closed.
The explanation is attached below, along with your
Pádraig Brady wrote:
reopen 19377
stop
On 19/12/14 01:13, KO Myung-Hun wrote:
GNU bug Tracking System wrote:
Your bug report
#19377: [PATCH 1/4] doc: add $(EXEEXT) suffix to the executables
which was filed against the coreutils package, has been closed.
The explanation is attached
On 15/12/14 01:15, KO Myung-Hun wrote:
Pádraig Brady wrote:
forcemerge 19378 19377
stop
On 14/12/14 03:47, KO Myung-Hun wrote:
And ln,ls,mv,rm,tail.
* src/cat.c (main): Expand wildcards on OS/2.
* src/chcon.c (main): Likewise.
* src/chgrp.c (main): Likewise.
* src/chmod.c (main):
On Mon, Dec 15, 2014 at 12:57 AM, Pádraig Brady p...@draigbrady.com wrote:
On 15/12/14 01:15, KO Myung-Hun wrote:
Pádraig Brady wrote:
forcemerge 19378 19377
stop
On 14/12/14 03:47, KO Myung-Hun wrote:
And ln,ls,mv,rm,tail.
* src/cat.c (main): Expand wildcards on OS/2.
* src/chcon.c
Pádraig Brady wrote:
On 15/12/14 01:15, KO Myung-Hun wrote:
Pádraig Brady wrote:
forcemerge 19378 19377
stop
On 14/12/14 03:47, KO Myung-Hun wrote:
And ln,ls,mv,rm,tail.
* src/cat.c (main): Expand wildcards on OS/2.
* src/chcon.c (main): Likewise.
* src/chgrp.c (main): Likewise.
*
KO Myung-Hun wrote:
/* Redirection and wildcarding when done by the utility itself.
Generally a noop, but used in particular for native VMS. */
#ifndef initialize_main
-# define initialize_main(ac, av)
+# ifndef __OS2__
+# define initialize_main(ac, av)
+# else
What happened to VMS?
Paul Eggert wrote:
KO Myung-Hun wrote:
/* Redirection and wildcarding when done by the utility itself.
Generally a noop, but used in particular for native VMS. */
#ifndef initialize_main
-# define initialize_main(ac, av)
+# ifndef __OS2__
+# define initialize_main(ac, av)
+#
On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun kom...@gmail.com wrote:
Paul Eggert wrote:
KO Myung-Hun wrote:
/* Redirection and wildcarding when done by the utility itself.
Generally a noop, but used in particular for native VMS. */
#ifndef initialize_main
-# define
Jim Meyering wrote:
On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun kom...@gmail.com wrote:
Paul Eggert wrote:
KO Myung-Hun wrote:
/* Redirection and wildcarding when done by the utility itself.
Generally a noop, but used in particular for native VMS. */
#ifndef initialize_main
-#
forcemerge 19378 19377
stop
On 14/12/14 03:47, KO Myung-Hun wrote:
And ln,ls,mv,rm,tail.
* src/cat.c (main): Expand wildcards on OS/2.
* src/chcon.c (main): Likewise.
* src/chgrp.c (main): Likewise.
* src/chmod.c (main): Likewise.
* src/chown.c (main): Likewise.
* src/cp.c (main):
Pádraig Brady wrote:
forcemerge 19378 19377
stop
On 14/12/14 03:47, KO Myung-Hun wrote:
And ln,ls,mv,rm,tail.
* src/cat.c (main): Expand wildcards on OS/2.
* src/chcon.c (main): Likewise.
* src/chgrp.c (main): Likewise.
* src/chmod.c (main): Likewise.
* src/chown.c (main): Likewise.
And ln,ls,mv,rm,tail.
* src/cat.c (main): Expand wildcards on OS/2.
* src/chcon.c (main): Likewise.
* src/chgrp.c (main): Likewise.
* src/chmod.c (main): Likewise.
* src/chown.c (main): Likewise.
* src/cp.c (main): Likewise.
* src/du.c (main): Likewise.
* src/head.c (main): Likewise.
* src/ln.c
With coreutils 8.23 under Debian/unstable:
ypig% : x
ypig% cat x x
cat: x: input file is output file
ypig% POSIXLY_CORRECT=1 cat x x
cat: x: input file is output file
while there's no reason to return an error in this case: the file
should just remain empty. Using the same file for input
On 09/11/2014 02:00 PM, Vincent Lefevre wrote:
With coreutils 8.23 under Debian/unstable:
ypig% : x
ypig% cat x x
cat: x: input file is output file
ypig% POSIXLY_CORRECT=1 cat x x
cat: x: input file is output file
while there's no reason to return an error in this case: the file
On 09/11/2014 07:20 AM, Pádraig Brady wrote:
while there's no reason to return an error in this case: the file
should just remain empty.
Testing for an empty file is enough of an additional special case over
the existing check for same files that I don't think it is worth it.
BTW, when x
On 2014-09-11 14:20:06 +0100, Pádraig Brady wrote:
On 09/11/2014 02:00 PM, Vincent Lefevre wrote:
This may not seem really useful here, but this can potentially break
scripts with things like:
cat $foo $bar
where $foo may be the same file as $bar only if it is empty.
I'm
With my Fedora version, there is an error message (input file is output
file)
cat x x
cat: x: input file is output file
Regards
Leslie
From: Pádraig Brady p...@draigbrady.com
To: Vincent Lefevre vinc...@vinc17.net; 18...@debbugs.gnu.org
Sent
an lseek
with SEEK_CUR so it's all in-memory. Plus, the POSIX 'cat' spec gives
an example of using 'cat' to copy an empty regular file to itself, and
(not unreasonably) says that should work.
As far as POSIX conformance goes, I don't think we need to worry about
POSIXLY_CORRECT here. We'll get
tag 18350 notabug
close 18350
stop
On 08/29/2014 12:40 AM, David King wrote:
I have recently upgraded from Ubuntu 10.?? to 12.?? to 14.04.
Anytime I run /bin/cat, it segfaults:
king@cloud-laptop:~/workspace$ cat foo
Segmentation fault (core dumped)
king@cloud-laptop:~/workspace$ file
David King wrote:
king@cloud-laptop:~/workspace$ cat foo
Segmentation fault (core dumped)
Problems such as these have sometimes occurred when the hardware has
started to fail. Such as for failing memory or other hardware caused
problems. I would run memtest on the system. I would inspect
I have recently upgraded from Ubuntu 10.?? to 12.?? to 14.04.
Anytime I run /bin/cat, it segfaults:
king@cloud-laptop:~/workspace$ cat foo
Segmentation fault (core dumped)
king@cloud-laptop:~/workspace$ file /bin/cat
/bin/cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV
Hello Gnu folks,
I had 3 files matching “isi.*.02p0:
wc -l isi.*.02p0
2 isi.R.0400.02p0
15500 isi.Ra.0400.02p0
15600 isi.Rb.0400.02p0
51100 total
I wanted to combine them into one big file, while knowing *not* to cat into a
file with same name as an original file,
I did
, while knowing *not* to cat into a
file with same name as an original file,
I did this:
cat isi.*.02p0 isi.Rall.0400.02p0
But it never returned!!
By the time I hit Ctrl-C, the file isi.Rall.0400.02p0 was already 3000 times
bigger than the biggest of the original files.
A hidden loop
Hi RHEL Team,
I was working with cat command and testing its functionality. I learnt in one
of the manuals that if multiple files are specified, the contents of the files
are concatenated in the output, but line numbering is restarted at 1 for each
file. However in an experiment I found
tag 14505 needinfo
thanks
On 05/29/2013 05:57 AM, Kakkar, Mayank (NSN - IN/Bangalore) wrote:
Hi RHEL Team,
This is the upstream coreutils list; if you were trying to reach RHEL
support, you should contact Red Hat per your contract with them.
I was working with cat command and testing its
in
the output, but line numbering is restarted at 1 for each file. As an
illustration, the following command,
$ cat -b fruits users
produces the output
1 Fruit Price/lbs Quantity
2 Banana $0.89 100
3 Peach $0.79 65
4 Kiwi $1.50 22
5 Pineapple $1.29 35
6 Apple $0.99 78
1 ranga
2 vathsa
3 amma
So
, the contents of the files are
concatenated in the output, but line numbering is restarted at 1 for
each file. As an illustration, the following command,
$ cat -b fruits users
produces the output
1 Fruit Price/lbs Quantity
2 Banana $0.89 100
3 Peach $0.79 65
4 Kiwi $1.50 22
5 Pineapple $1.29
...@debbugs.gnu.org
Subject: Re: bug#14505: Bug in cat command
Kakkar, Mayank (NSN - IN/Bangalore) wrote:
I am referring to the manual - 'Sams teach yourself shell in 24
hours', which is authored by Sriranga Veeraraghavan.
It isn't unusual for books to have bugs too.
Following is example potrayed
hockseng leow wrote:
Memory can fail. I thought there is a difference between ctrl-c and ctrl-d.
I checked with an old Redhat and it also behaved that way.
No worries! Thanks for confirming this information for the bug log.
Bob
hockseng leow wrote:
Ctrl-c is behaving like Ctrl-d.
In the context you describe, yes, by necessity. It always has.
When redirecting from standard-in to an existing file, Ctrl-c empties
out the old file contents. In the past, Ctrl-c just aborts cat and
leave the existing file unchanged
, yes, by necessity. It always has.
When redirecting from standard-in to an existing file, Ctrl-c empties
out the old file contents. In the past, Ctrl-c just aborts cat and
leave the existing file unchanged.
$ cat abc.txt
abc
$ cat abc.txt
def
^C
$ cat abc.txt
def
That is the test
$ cat abc.txt
abc
$ cat abc.txt
def
^C
$ cat abc.txt
def
On Fri, Apr 12, 2013 at 5:41 PM, Pádraig Brady p...@draigbrady.com wrote:
tag 14190 notabug
close 14190
stop
On 04/12/2013 03:29 AM, hockseng leow wrote:
Hello,
Ctrl-c is behaving like Ctrl-d.
When redirecting from standard
Hello,
Ctrl-c is behaving like Ctrl-d.
When redirecting from standard-in to an existing file, Ctrl-c empties
out the old file contents. In the past, Ctrl-c just aborts cat and
leave the existing file unchanged.
It happens in Fedora 17.
Please fix.
Thanks.
--
Leow Hock Seng
Tel:64463211
tag 13913 + notabug
close 13913
thanks
Naveen wrote:
I am naveen kumar, currently studying B.Tech CSE 3 rd year. I am
developing a application in linux 10.04 by using java. In my application am
showing battery status of system. for that am accessing the file cat
/proc/acpi/battery/BAT0
Thanks for your help.
I've reported this bug against Ubuntu.
Follow-up: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1060767
Kind Regards,
Rafal
Sent from my iPhone
Rafal W. wrote:
Thanks for your help.
I've reported this bug against Ubuntu.
Follow-up: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1060767
Since you are using Ubuntu that is the right place to pursue the key
mapping problem. Your report there included good information.
But...
bronek wrote:
Yes, coreutils was a mistake, because they've stupid autocomplete
textfield, when typing kernel, ubuntu or other keywords which I've tried,
all the time was too general, so how do I know what other options are if I
don't see any results (at last first 10?)? So I was happy to type
Yes, the Alt-SysRq + 1-4,7-9,0 keys do nothing on mine as well, even on the
plain console.
But if I send the numbers to sysrq-trigger, then it works. So probably it's
a separate bug report.
I've 1 in sysrq.
$ cat /proc/sys/kernel/sysrq
1
So in summary the process is killed if the key
Hi Bob,
thanks for the reminder, but I didn't receive any message from Alan,
could you re-post it?
Maybe it went to Spam.
Is there any web version of this bug tracker? At work they're blocking
the access for all the emails.
Kind Regards,
Rafal
Sent from my iPhone
On 30 Sep 2012, at 07:40, Bob
Yes, I've tried and it didn't QUIT (it ignored SysRq signal). I didn't
know about Ctrl-4 shortcut for sending the QUIT signal. After that I
had to kill the process, because Control-D didn't work.
So I'm assuming it's by design.
Thanks for your help.
Kind Regards,
Rafal
Sent from my iPhone
On 30
But if Control-4 is sending QUIT signal, why:
Control-1 does kill the process?
I've checked again and actually it's not even about the number.
When I press only: Control-SysRq it kills the process as well.
Sometimes it happens on press, sometimes on release.
Kind Regards,
Rafal
Sent from my
Rafal W. wrote:
Hi Bob,
thanks for the reminder, but I didn't receive any message from Alan,
could you re-post it?
Maybe it went to Spam.
Is there any web version of this bug tracker?
Yes. Any mail sent to bug-coreutils gets an issue number,
which comes with a URL like this:
Rafal W. writes:
But if Control-4 is sending QUIT signal, why:
Control-1 does kill the process?
I've checked again and actually it's not even about the number.
When I press only: Control-SysRq it kills the process as well.
Sometimes it happens on press, sometimes on release.
Is your SysRq
Hi,
Thanks for this info.
Just to explain why I press it with Control and Alt.
My Linux freezing all the time, so sometimes I'm using kernel SysRq
for the reason.
So in example if I want to check all currently held Locks with SysRq-D
(which doesn't work anyway), so:
When I press SysRq-D, I've
Rafal W. writes:
So in example if I want to check all currently held Locks with SysRq-D
(which doesn't work anyway), so:
When I press SysRq-D, I've KSnapshot popping up. In the text console
it doesn't work at all.
ksnapshot sounds like something that might respond to a PrtSc keypress. This
Thanks. Without Control more things are working.
Alt-SysRq-m and other letters works, doesn't kill the process.
So the only problems are numbers:
Alt-SysRq-1 to 9 (exempt 5 6) is killing the process.
Looks like 5 and 6 have some special privileges.
Kind Regards,
Rafal
Sent from my iPhone
On 1
can do this by using the /proc kernel interface directly.
$ cat /proc/sys/kernel/sysrq
What level number is produced there?
# echo h /proc/sysrq-trigger
# tail /var/log/syslog (or tail /var/log/messages or whatever)
On my system it shows:
$ cat /proc/sys/kernel/sysrq
438
Rafal,
Any news? Please try the steps that Alan has suggested.
I marked the bug ticket as needing more information.
Bob
$ cat /dev/zero
^\Quit (core dumped)
Steps to reproduce:
1. Switch to any text console (it doesn't happen in X).
2. Login
3. Run: cat /dev/zero
4. Press: Ctrl-Alt-SysRq-1 (or any number except letters:)
5. You'll see: ^\Quit (core dumped)
Here is the backtrace:
kenorb@kenorb-HP-Compaq
Rafal W. writes:
$ cat /dev/zero
^\Quit (core dumped)
Steps to reproduce:
1. Switch to any text console (it doesn't happen in X).
2. Login
3. Run: cat /dev/zero
4. Press: Ctrl-Alt-SysRq-1 (or any number except letters:)
What's that supposed to do? Ctrl isn't normally used
Hello:
I am a user of ubuntu 10.04.2.While I am trying to use 'cat' to
display a binary file.Every letter on my display goes wrong
yours GB from China
tags 9344 + notabug
thanks
博高 wrote:
Hello:
I am a user of ubuntu 10.04.2.While I am trying to use 'cat' to
display a binary file.Every letter on my display goes wrong
yours GB from China
The 'cat' program copies each file to standard output concatenating
files. It is working
On 08/22/2011 08:21 PM, 博高 wrote:
Hello:
I am a user of ubuntu 10.04.2.While I am trying to use 'cat' to
display a binary file.Every letter on my display goes wrong
yours GB from China
There was probably a character sequence in the binary file
to put your terminal
Thanks very much
On Tue, Aug 23, 2011 at 4:17 AM, GNU bug Tracking System
help-debb...@gnu.org wrote:
Your bug report
#9344: about the command of 'cat'
which was filed against the coreutils package, has been closed.
The explanation is attached below, along with your original report
I'm trying to track down a bug in cat of coreutils 6.12. Doing
cat /var/log/Xorg.0.log | head -n70
under ksh consistently fails with 'cat: write error: Connection reset by
peer'. It does not fail when run under bash and it does not fail in current
coreutils . It seems that ksh implementing
On 07/15/2011 05:30 AM, Philipp Thomas wrote:
I'm trying to track down a bug in cat of coreutils 6.12. Doing
cat /var/log/Xorg.0.log | head -n70
under ksh consistently fails with 'cat: write error: Connection reset by
peer'. It does not fail when run under bash and it does not fail
On 15/07/11 14:03, Eric Blake wrote:
On 07/15/2011 05:30 AM, Philipp Thomas wrote:
I'm trying to track down a bug in cat of coreutils 6.12. Doing
cat /var/log/Xorg.0.log | head -n70
under ksh consistently fails with 'cat: write error: Connection reset by
peer'. It does not fail when run
* Eric Blake (ebl...@redhat.com) [20110715 15:03]:
And that behavior of ksh is probably a violation of POSIX:
http://austingroupbugs.net/view.php?id=205
that discussion is from 2006 and ksh has had that feature for quite a bit
longer. The reasin is that sockpairs are faster than pipes and and
* Pádraig Brady (p...@draigbrady.com) [20110715 16:20]:
Note the reason ksh does this, is to allow commands
to efficiently inspect the input, rather than reading byte by byte.
This is related to the recent `stdbuf -i0` discussions.
And that noticeable speedup is one of ksh's main advantages,
Hi,
Please keep me in Cc: since I'm not subscribed.
'tac' by default does the same as cat, but in reverse order. I didn't know about
'tac' and it took me a while (about 5 minutes, but anyways :-P) to find it. I
think having a see also tac on cat's manpage could be useful and save people
some
Rodrigo Campos wrote:
'tac' by default does the same as cat, but in reverse order. I didn't know
about
'tac' and it took me a while (about 5 minutes, but anyways :-P) to find it. I
think having a see also tac on cat's manpage could be useful and save people
some time :)
The attached patch
, 2010 at 13:17, Eric Blake ebl...@redhat.com wrote:
* src/cat.c (usage): Clarify that -b overrides -n.
* doc/coreutils.texi (cat invocation): Likewise.
* THANKS: Update.
Suggested by Chas. Owens, in bug 6383.
No other comments, so I went ahead and pushed the patch.
Thanks again for the report
The -n option is documented as number all output lines, but when -b
is present it only numbers non-blank lines. The documentation should
read number output lines.
--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.
* src/cat.c (usage): Clarify that -b overrides -n.
* doc/coreutils.texi (cat invocation): Likewise.
* THANKS: Update.
Suggested by Chas. Owens, in bug 6383.
---
The -n option is documented as number all output lines, but when -b
is present it only numbers non-blank lines. The documentation
overrides -n.
* doc/coreutils.texi (cat invocation): Likewise.
* THANKS: Update.
Suggested by Chas. Owens, in bug 6383.
---
The -n option is documented as number all output lines, but when -b
is present it only numbers non-blank lines. The documentation should
read number output lines.
Thanks
Hello,
Please excuse my bad english :
Bug Report
--
Context:
Debian Lenny
linux 2.6.26-2-686
XFCE4 with Terminal 0.2.8
coreutils 6.10-6
What I did:
---
I tried to display binary files with 'cat':
$ cat ~/an_audio_file.rm
$ cat /bin/cp
What I expected
david johann wrote:
I tried to display binary files with 'cat':
$ cat ~/an_audio_file.rm
$ cat /bin/cp
That isn't expected to behave nicely. You really shouldn't be doing that.
What I expected:
-- displaying unreadable chars from the binary file;
-- and then coming back
Thank you very much!
2010/2/4 Bob Proulx b...@proulx.com
david johann wrote:
I tried to display binary files with 'cat':
$ cat ~/an_audio_file.rm
$ cat /bin/cp
That isn't expected to behave nicely. You really shouldn't be doing that.
What I expected
Hi Pádraig,
On my 6th run of make check, the cat-buf test failed.
It's an inherently racy test.
If the dd process is starved until 2 is printed,
it will end up printing both lines to out.
Here's the code:
# Use a fifo rather than a pipe in the tests below
# so that the producer (cat
While I was looking at this test...
From a4a864da365fe70eb3a69fd4347f8f747a258efd Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 7 Sep 2009 20:23:03 +0200
Subject: [PATCH] tests: misc/cat-buf: clean up syntax
* tests/misc/cat-buf: Don't suppress dd's stderr.
Remove
Jim Meyering wrote:
Hi Pádraig,
On my 6th run of make check, the cat-buf test failed.
It's an inherently racy test.
If the dd process is starved until 2 is printed,
it will end up printing both lines to out.
Hmm. 0.2s was too short between writes so.
I've bumped it up to 0.5s since 0.2
Pádraig Brady wrote:
Hmm. 0.2s was too short between writes so.
I've bumped it up to 0.5s since 0.2 failed so infrequently.
I've also changed to just skip on possible failure.
That should do it. Thanks.
FYI,
From e1e5963a9df8f1e9184f87c64db796fd63586090 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Fri, 3 Apr 2009 21:52:16 +0200
Subject: [PATCH] doc: adjust 7.2 cat,cp,install,mv,split speed-up NEWS item
* NEWS: Reword an entry from 7.2 and change linux to GNU/Linux
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.
1 - 100 of 207 matches
Mail list logo
