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 recei
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
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 \n might
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 happe
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 pos
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: writ
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 doe
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 is not a
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
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 test
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 existing
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
co
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
The &qu
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 occ
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.
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.
>
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.
>>>
>>>
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, alon
e name
> # of the .c file upon which they depend: ls.c.
> -man/arch.1: src/uname
> -man/dir.1: src/dir
> -man/install.1: src/ginstall
> -man/vdir.1: src/vdir
> -
> -man/base64.1:src/base64
> -man/basename.1: src/basename
> -man/cat.1: src/cat
&g
On Mon, Dec 15, 2014 at 9:11 PM, KO Myung-Hun wrote:
> Jim Meyering wrote:
>> On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun wrote:
>>> Paul Eggert wrote:
KO Myung-Hun wrote:
> /* Redirection and wildcarding when done by the utility itself.
> Generally a noop, but used in parti
Jim Meyering wrote:
> On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun 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
>>>
On Mon, Dec 15, 2014 at 8:35 PM, KO Myung-Hun 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 initialize_main(ac
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
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?
Jim Meyering wrote:
> On Mon, Dec 15, 2014 at 12:57 AM, 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
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.
>>
On Mon, Dec 15, 2014 at 12:57 AM, 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.
*
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.
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 (
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):
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 (m
's only 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
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
>To: Vincent Lefevre ; 18...@debbugs.gnu.org
>Sent: Thursday, Septembe
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"
> >
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
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
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
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 i
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 du
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, versi
tags 17384 notabug
close 17384
stop
On 05/01/2014 10:52 PM, Bernhard Voelker wrote:
If the output file had previously existed (so that the file name
globbing would let it match the pattern), then cat(1) would have
complained:
$ src/cat isi.*.02p0 >isi.Rall.0400.02p0
src/cat: isi.R
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 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 a
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
...@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
; 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. As an illustration, the following command,
>
> $ cat -b fruits users
>
> produces the output
>
> 1 Fruit Price/lbs Quantity
nated 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
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 te
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 this
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
ext 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.
>>
>&
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
$ 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 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.
>>
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-in to an existing file, Ctrl-c empties
> out the old file contents. In the past, Ctrl-c just aborts cat and
> le
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/
Sir,
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/state frequently. but in some of the systems after
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 t
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...
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:
> So in summary the process is killed if the key is not handled by anything
> else.
I don't agree with that conclusion. It has not been determined what
action is happening for you with Alt-SysRq-{1,2,3,4,7,8,9,0} and
without that knowledge I don't believe a conclusion can be made.
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
ntended to restore usability to a console that is getting bombarded
with log events and Alt-SysRq-5 is useful for that purpose.
I think you should determine what actions are enabled on your system.
You can do this by using the /proc kernel interface directly.
$ cat /proc/sys/kernel/sysrq
What l
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
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. T
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 KSnap
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 S
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: http://bugs
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 iPhon
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
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 Pr
Rafal,
Any news? Please try the steps that Alan has suggested.
I marked the bug ticket as needing more information.
Bob
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
> $ 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
Thanks very much
On Tue, Aug 23, 2011 at 4:17 AM, GNU bug Tracking System
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 or
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
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 ou
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
On 07/15/2011 09:14 AM, Philipp Thomas wrote:
> * 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.
* 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
* 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
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:
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 ru
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 k
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 co
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
explicitly.
>
> On Wed, Jun 9, 2010 at 13:17, Eric Blake 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 ah
s -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 documentatio
* 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. T
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.
Thank you very much!
2010/2/4 Bob Proulx
> 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 shou
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 c
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
1 - 100 of 230 matches
Mail list logo