Ian Dall wrote:
Padraig Brady writes:
Ian Dall wrote:
I needed to sort by version number so that 1.2.12 1.2.3
[...]
2005-11-02 Ian Dall [EMAIL PROTECTED]
* coreutils.texi (sort invocation): Document new option
--version-sort (-v).
Thanks.
I agree that this
Eric Blake wrote:
According to James Youngman on 11/18/2005 1:28 AM:
Many systems now include the 'buffer' program (I have it here on an
Ubuntu box). If you have it, try piping the data through 'buffer -z
4096' (or whatever PIPE_BUF is on your machine if it's not 4096).
Is it worth
I don't think that fits.
As I see it, ls is an end user tool, i.e. output
generally goes direct to the end user.
If you would like a more progamatic way of
selecting files then `find` is more appropriate.
(find has a -type option for example).
The shell can also be used to expand just
Linda Walsh wrote:
Sometimes I would like dd to copy the contents of
Random-Block-Object-A
to Random-Block-Object-B, starting from the middle of of the file.
I can specify the seek=BLOCKS param, but it appears that dd doesn't
translate this to a seek command but instead uses read to to
Andre Gompel wrote:
Dear colleague:
it looks like a bug... or at least a short comming.
If I use the -n or -g option I cannot sort according to the output format of
the du or ls commands.
Example:
du -chs * |sort -n |more
I am not sure what would be the best approach, but I would
Pádraig Brady wrote:
Andre Gompel wrote:
Dear colleague:
it looks like a bug... or at least a short comming.
If I use the -n or -g option I cannot sort according to the output format of
the du or ls commands.
Example:
du -chs * |sort -n |more
I am not sure what would be the best
David Laurence Emerson wrote:
# rln by David Laurence Emerson [EMAIL PROTECTED]
# version 0.01
# 2006-02-21
#
# This bash script is insanely slow and would be well replaced by a c
# implementation.
#
# rln stands for relative (sym)link. It helps create symlinks by
# intelligently finding an
I was trying today to filter my access.log apache log with some coreutils
and was annoyed by the default buffering applied by glibc.
I was trying to do `tail -f ~/access.log | cut ... | uniq` but I was
only getting output when cut had more than 4K written to stdout.
So how to control this? Well
Andreas Schwab wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
p. p.s. Note glibc changes the buffering automatically for stdout only like:
if (isatty(fileno(stdout)) setlinebuf(stdout)
Also it always leaves stdin buffered and stdout unbuffered
Paul Eggert wrote:
If this is merely for debugging, can't you write a wrapper that forces
line buffering for a program? The wrapper could substitute your own C
library functions via LD_PRELOAD, or could run the program inside a
pseudotty a la 'expect'.
No I was thinking of a more simple
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
Paul Eggert wrote:
If this is merely for debugging, can't you write a wrapper that forces
line buffering for a program? The wrapper could substitute your own C
library functions via LD_PRELOAD, or could run the program inside
Bob Proulx wrote:
Scott Griffith wrote:
I was just looking at the man page for grep, and wouldn't you know
it.. --line-buffer is not very well documented. Infact, all it
says about that is:
(excerpt from man page)
--line-buffering
Use line buffering, it can be a performance
Jim Meyering wrote:
Simon Josefsson [EMAIL PROTECTED] wrote:
...
Still, maybe not all programs have similar rate-limiting features, so
that this nice-extension may be useful anyway...
I agree. Maybe even as a separate program, for when you start something
important and somehow
Egmont Koblinger wrote:
Hi,
Plenty of text utilities are able to work with lines terminated by zero
bytes instead of newlines. sort is one example, which has an internal uniq
support, so sort -z -u sorts the input and removes adjacent identical
zero-terminated strings.
However, standalone uniq
mark manning wrote:
stty -F /dev/tts/12 returns speed 9600 baud and some other stuff.
yet when i connect that port to a cable going to a windows box running
hyperterm i get NO data at all at that baud rate. set windows box to
2400 and i get the transmitted data just right. this means that
Matt Keenan wrote:
Greetings all,
uniq(1) used to have an option for checking only a certain number of
fields. I have since noticed that some scripts I wrote some time ago
have stopped working because the -W / --check-fields=N option has
disappeared. Can it please be put back in? I am happy
Matt Keenan wrote:
Paul Eggert wrote:
Matt Keenan [EMAIL PROTECTED] writes:
Paul Eggert has mentioned that upstream uniq has never had a -W
flag. Would you be receptive to a patch?
I'm not sure. Does any distribution other than Debian-derived
distributions have it? More
Dan Jacobson wrote:
$ dmesg|sort|uniq -D -c
uniq: printing all duplicated lines and repeat counts is meaningless
Try `uniq --help' for more information.
Meaningless for you, but just what I want:
$ dmesg|sort|uniq -D|uniq -c
5 EXT3-fs: mounted filesystem with ordered data mode.
The reason for this I think is so that one gets accurate totals,
as the following will only give subtotals for each invocation of wc,
if there are enough files to make the cmd line go above the max len.
find -print0 | xargs --null wc
Might be worth adding text to that affect,
as I needed to
Jim Meyering wrote:
Hi Matt,
I'm glad you're willing to work on this.
It's an often-requested feature.
Unfortunately, the Debian -W patch was not acceptable.
It did not allow the same flexibility that sort does in
selecting keys. To provide that, GNU uniq will eventually
accept at
Jim Meyering wrote:
[EMAIL PROTECTED] (Bob Proulx) wrote:
Jim Meyering wrote:
The description of wc's --files0-from is nearly identical
to that of du. I've added an example:
...
[EMAIL PROTECTED]
+find . -name '*.[ch]' -print0 | ./wc -L --files=- | tail -n1
[EMAIL PROTECTED] example
Here you
Jim Meyering wrote:
Pádraig Brady [EMAIL PROTECTED] wrote:
Jim Meyering wrote:
-g, --general-numeric-sort compare according to general numerical value
-M, --month-sortcompare (unknown) `JAN' ... `DEC'
-n, --numeric-sort compare according to string numerical
Jim Meyering wrote:
Pádraig Brady [EMAIL PROTECTED] wrote:
However I notice v5.2.1 at least only seems to handle ascii:
$ LANG=ga_IE.utf8 uniq -i Pádraig
Pádraig
PÁdraig
Yes, that's still a problem.
Would you like to work on it?
You should have warned me :)
Anyway I've had a look
Vinu, Uma wrote:
Hi,
ls -l Dir | grep core | wc -l - The directory doesn't has the
core file.
But wc -l returns a blank line instead of a 0. I need the output to be
0.
Why does this happen? Your reply will be of great help.
My version of wc (5.2.1) does return 0.
You should
Andreas Schwab wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
So you probably want to do:
if ls /dir | grep -q '^core$'; then
echo Core file found
fi
test -f /dir/core echo Core file found
Yes I didn't want to mention that :)
Modern linux systems at least can
have multiple core
Paul Eggert wrote:
Using strcoll is inefficient anyway
Don't we know it! If we can avoid it, we'd like to.
Well, the mbstowcs+wcscoll solution I presented
should be equivalent to strcoll on any platform,
and it's much faster in my tests.
That's good to know, though I'm puzzled as to why
Pádraig Brady wrote:
Paul Eggert wrote:
Using strcoll is inefficient anyway
Don't we know it! If we can avoid it, we'd like to.
Well, the mbstowcs+wcscoll solution I presented
should be equivalent to strcoll on any platform,
and it's much faster in my tests.
That's good to know, though I'm
Neil Adair wrote:
Why isn't the command to exit tail in the man page?
tail is not an interactive program and
so will not parse commands you enter.
It is known as a filter and just reads stdin and
writes to stdout.
So if you just type `tail`, it will block
reading from stdin which will be
Sorry Paul.
The following obvious patch is needed for the memcoll change in 6.0.
I didn't notice it in my quick test as I had forgotten I changed
xmemcoll to memcoll in uniq in my tree.
I only noticed errno being non zero for me when I redirect uniq to /dev/null
but I guess there are a million
Paul E Condon wrote:
I report a feature of uniq which seems IMHO to be a bug:
I am using test files containing the following lines:
tsttmp1:
2/dl1/f04 lnk2/f04 Europe but where?
2/dl1/f04alnk2/f04 Europe but where?
tsttmp2:
2/dl1/f04
Jim Meyering wrote:
Petter Reinholdtsen [EMAIL PROTECTED] wrote:
The ANSI C 89 compilers refuses code that fail to declare variables at
the start of the block. I found this problem on RHEL 2.1. The code
refused to compile, and I have to move the variables up to the start
of the block to get
Singh, Sundeep wrote:
Hi,
I have a printf statement in my script as follows:
printf -- %s \n $name
Pass -- first to printf to tell it you're
not passing it any (more) command line options, like:
printf -- -- %s \n $name
Pádraig.
___
cat splited.* joined.bin
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Miguel Barão wrote:
This not a bug but rather an inconsistent output between these two du
options,
which is not documented in the manpages.
Suppose 'somefile' is a file containing a lot of zeros.
Then I get:
$ du -k somefile
12
$ du somefile
12
$ du -b somefile
4194432
It seems
Peter Stuczynski wrote:
Hi,
I'm new to linux and I have a 80Gig WD drive that's going bad. I purchased
another 80Gig WD drive and I'm using dd to try to transfer the information to
the new drive. I used:
dd if=/dev/hda of=/dev/hdb conv=noerror
It's been running for
David Kastrup wrote:
Hi,
if one calls sort -u with -k fields or other things that can make
unequal files compare as equal, sort always keeps the first of all
lines that are considered equal.
If one is compressing the information of some data gathering process,
usually the last line is
Geoffrey Rommel wrote:
I've written a little utility called 'hdisp' (hex display). It displays files
in characters and hex, which makes it similar to 'od -ch', but the output is
IMHO easier to read. It also displays EBCDIC characters; for instance,
x'C1' in the input can be displayed as 'A'
Alfred M. Szmidt wrote:
I should note that I'm still waiting for the someone to step up as
miscutils maintainer, [EMAIL PROTECTED] never got back to me about it.
I was asking around elsewhere for possible
additions to miscutils, but didn't get much response.
But I guess we should start it up
James Youngman wrote:
On 11/13/06, Alfred M. Szmidt [EMAIL PROTECTED] wrote:
How about we create a miscutils project where these silly things can
be included? Coreutils is after all not the dumping point for every
imaginable utility one can come up with, it is for core system
utilities, and
John Summerfield wrote:
[EMAIL PROTECTED] ~]$ yes stuff | head -300 | cat -n | (head -2;tail -2)
1 stuff
2 stuff
[EMAIL PROTECTED] ~]$
I presume this arises because head's reading ahead (if not head, then
glibc on head's behalf), and when head's printed enough lines it simply
Paul Eggert wrote:
Dat Head [EMAIL PROTECTED] writes:
dd if=/dev/zero of=/dev/null count=100 bs=1024k
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.00933139 seconds, 11.2 GB/s
---^^^ should be 100 MB
No, MB means megabytes (i.e., 10**6
Kreuzer IT Support wrote:
Hello there,
I have a backup script running which uses sort in order to process those
files first which are modified last.
I use find (pruning several paths) as input for afio, here for the filelist:
find / -path /proc -prune -o -path /tmp -prune -o
Anshul Nigham wrote:
Hi
Using wildcard expansion, it is possible to unintentionally overwrite
files. E.g. consider a directory with two text files, a.txt and b.txt.
$ cp *.txt
$ cat b.txt
I am A!!
I don't think this could be intended or expected behavior in any
scenario. I suggest
Hi,
I was thinking it would be useful to
add an option to dd to tell it to
instruct the OS not to cache the data.
Personally I use dd to move large files like disc images etc.
around, and I know I will not need the file cached.
A very quick example patch which has only
been tested on linux is
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
I was thinking it would be useful to
add an option to dd to tell it to
instruct the OS not to cache the data.
Yes, that's handy, but doesn't dd iflag=direct already do that for you?
Not exactly. That bypasses all the kernelly
Jim Meyering wrote:
Pádraig Brady [EMAIL PROTECTED] wrote:
I was thinking it would be useful to
add an option to dd to tell it to
instruct the OS not to cache the data.
I like the idea, even if it works only with very recent Linux
kernels.
It's not that new. It's in since 2.5.60 according
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
http://www.die.net/doc/linux/man/man2/posix_fadvise.2.html
Wow. That makes it seem like POSIX_FADV_SEQUENTIAL isn't nearly as
useful as it should be.
Well linux uses POSIX_FADV_SEQUENTIAL to double the readahead currently,
which
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
But this is what POSIX_FADV_SEQUENTIAL is designed for, no?
That is, POSIX_FADV_SEQUENTIAL should be tuned for usage patterns like
dd's, right? Why isn't it?
There used to be an O_STREAM flag that did all this.
Pity they removed
qm Brad Allen wrote:
I don't have time to complete this right now; putting
|bfr inbetween the two fixes it and it makes my script work.
If I have time I can do this later.
Given the following test file named test, whose
contents and size do not matter if size is greater than
1023, then we
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
dd does not issue another read() request to fill the input buffer,
before proceeding with the write(). I'm not sure why it does this.
Because that's the way it's always done it. :-)
Anyway, POSIX requires this behavior. See
[EMAIL PROTECTED] wrote:
Hello maintainers of the mv command,
I have a problem with the mv command.
I cannot rename a file to lower case.
I used mv because Konqueror also fails.
Is there an explanation to this issue?
Greetings, Fabian.
You're trying this on a USB key right?
They generally
Jim Meyering wrote:
I've merged the SELinux changes onto the trunk. For reference, this
work is based on the patches from Fedora, as of about 6 months ago
[snip]
Unlike with other SELinux-enabled coreutils, here, mv and cp do not
provide the -Z context option. It is not the job of such
Georg Müller wrote:
Dear coreutils team,
I would like to see a sort by line length in the sort tool.
Is anything like this planned.
It seems easy to implement.
I could also write the code for that, if you wish.
That seems like a very specific need which
is probably best fulfilled with a
Philip Rowlands wrote:
On Fri, 4 May 2007, Paul Eggert wrote:
Anyway, 'shred' currently does the first, but not the second, as it
doesn't verify what it's written. That should get fixed, no?
Is there a way to ensure reading directly from disk? On Linux I see only
a whole-system,
André Nunes wrote:
Hey man!!! how are you??
i don't understand the difference of command CUT with the parammeter -b
and -c.
Please, you can help me??
thank you very much!!
No difference at present in the official coreutils.
In future (or maybe specific to your distribution),
there is
Jack van de Vossenberg wrote:
Dear Jim
I use nohup (ubuntu linux), and I have a feature request.
Often I run more than one program at a time under nohup, and some of
these programs run for at least a couple of hours.
Every now and then nohup writes the output to nohup.out, which I find
Micah Cowan wrote:
Patrick Amstutz wrote:
Hi,
I've the following behavior with the seq function on:
Linux version 2.6.18.8-0.3-default ([EMAIL PROTECTED]) (gcc version
4.1.220061115 (prerelease) (SUSE Linux)) #1
$ echo `seq 0.0 0.1 0.8`
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
$ echo `seq 0.0
John Cowan wrote:
Pádraig Brady scripsit:
The issue and work around are documented in the info page,
but why don't we do the suggestion automatically in code
(using the precision that is automatically worked out already)?
That implies using either a fixed-point or a decimal-based floating
Pádraig Brady wrote:
John Cowan wrote:
Pádraig Brady scripsit:
The issue and work around are documented in the info page,
but why don't we do the suggestion automatically in code
(using the precision that is automatically worked out already)?
That implies using either a fixed-point
Andreas Schwab wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
Yes you could use gmp, but for normal uses of `seq`
you could just use appropriate comparisons?
How about the following patch, and we can also
remove the workaround info from the docs.
Pádraig.
--- seq.orig.c 2007-06-08 07
This patch makes `seq 0.1 0.1 0.9` output 0.1 to 0.9 inclusive, as expected.
The documentation for the previously required workaround is removed.
Note I changed the Makefile for seq to link $(SEQ_LIBM) rather than $(POW_LIB),
as $(POW_LIB) was empty. Is the configure test correct for pow()? as
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
This patch makes `seq 0.1 0.1 0.9` output 0.1 to 0.9 inclusive, as expected.
I see some problems with that patch.
First, it continues to mishandle some similar cases. For example,
'seq 0.1 1e-1 0.9' outputs only 0.1 through 0.8
Andrés Ghigliazza wrote:
Hi there,
It would be useful to me, that cp has an option to copy files
alphabetical. Maybe this feature is not of general interest; in such a
case, I could program this option (although there has been years since
I developed something in C for the last time). In
Pádraig Brady wrote:
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
This patch makes `seq 0.1 0.1 0.9` output 0.1 to 0.9 inclusive, as expected.
I see some problems with that patch.
First, it continues to mishandle some similar cases. For example,
'seq 0.1 1e-1 0.9' outputs
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
OK, how about the attached patch?
Better, but it still has problems. For example, on my platform
(Debian stable with GCC 4.2.0, x86) the command
seq 0.0 0.1 0.9000 outputs something different from
seq 0.0 0.1 0.9
Pádraig Brady wrote:
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
OK, how about the attached patch?
Better, but it still has problems. For example, on my platform
(Debian stable with GCC 4.2.0, x86) the command
seq 0.0 0.1 0.9000 outputs something different
Andrés Ghigliazza wrote:
It would copy all the albums in alphabetical order, to the same target
directory!!. I am interested in having the same directories structure
in the player too, i.e: artist1/album1, etc.
untested:
find /src | sort | xargs cp --parents --target-directory=/flash
Paul Eggert wrote:
+ /* If we go one past the end, but that number prints the
+ same way last does, and prints differently from the
+ previous number, then print last. This avoids problems
+ with rounding. For example, with the x86 it causes seq
+ 0
Paul Eggert wrote:
Pádraig Brady [EMAIL PROTECTED] writes:
I haven't time to look at this now,
but will soon.
Thanks.
A couple of points came to mind.
Is it OK to look at just 1 value after last?
It should not be necessary to look 2 values after last. The problem
we're trying
Robert Millan [ackstorm] wrote:
[ Please keep [EMAIL PROTECTED] on CC ]
Hi!
I just discovered that the timeout(1) utility written by Dan Farmer on 1999
(http://www.porcupine.org/forensics/) is not free software (modification
is forbidden).
Since the program is small, I decided to
Robert Millan [ackstorm] wrote:
[ Please keep [EMAIL PROTECTED] on CC ]
Hi!
I just discovered that the timeout(1) utility written by Dan Farmer on 1999
(http://www.porcupine.org/forensics/) is not free software (modification
is forbidden).
Note for completeness,
While I was looking at the floating point rounding issues in seq
a couple of weeks ago, I noticed some anomalies with the width
automatically determined for floating point numbers,
and even for some integer number formats.
The changes this patch makes can be seen in the following
before and after
* src/seq.c: Fix the -w logic. Ignore spaces and '+'
characters of input numbers when determining width.
Set format correctly for input numbers in scientific notation.
* tests/seq/basic: Add various number width tests.
Signed-off-by: Pádraig Brady Pádraig Brady [EMAIL PROTECTED]
---
ChangeLog
[EMAIL PROTECTED] wrote:
Dear sirs,
I am writing to you due to an error encountered in command date in RHEL.
I have a lot of boxes running RHEL with several versions an date goes wrong o
well depending on the system's version.
Two examples:
---Case one: wrong
Michael A. Smith wrote:
sort -R works well when LC_ALL=POSIX; however, sort -R sorts in exactly the
same way as sort with no options with my LANG=en_US.UTF-8 and
LC_CTYPE=ja_JP.UTF8 settings.
Empirically, setting LANG or any LC* variable makes the -R option of no
effect.
Under most
Marcin Cinik wrote:
Hello!
I'm looking for the utility which could sum up numbers separated by
anything what is not a number from stdin or file. I needed such tool
very often and finally I've written one recently. It is not easy to
accomplish that using bc because it is hard to use when
Jim Meyering wrote:
Pádraig Brady [EMAIL PROTECTED] wrote:
I'm not sure such a utility fits with coreutils
(though I have required the functionality many times myself).
Here are some pointers:
http://www.pixelbeat.org/scripts/add
http://www.pixelbeat.org/scripts/funcpy
http://suso.suso.org
Karel Zak wrote:
On Tue, Jul 24, 2007 at 11:08:28AM +0100, Pádraig Brady wrote:
Mike Frysinger originally prompted this by asking
for dos2unix/unix2dos to be included
(though iconv/recode do this in a more general way).
I asked around a few mailing lists for
what people would consider
Mike Frysinger wrote:
On Monday 23 July 2007, Gabriel Barazer wrote:
The hostname utility in coreutils-6.9 is still a very old version, and
the hostname from net-tools 1.60 (released ~2001) is a better featured
utility. Since net-tools doesn't seem to be maintained anymore, what
about
Bob Proulx wrote:
[EMAIL PROTECTED] wrote:
I am not really sure if it is a bug, but the line command
touch seems incapable of changing the timestamp of a
link (on a related issue, tar does not usually recover
the timestamp of links).
There is no lutimes(2) call and therefore way way to
Lasse Kliemann wrote:
How complicated it would be to add a `-z' or `-0' switch to `comm' in order
to allow zero-terminated lines? The `sort' command, for example, allows
this, and this is very useful when dealing with filenames.
Or is such functionality already provided in a different
Pádraig Brady wrote:
Lasse Kliemann wrote:
How complicated it would be to add a `-z' or `-0' switch to `comm' in order
to allow zero-terminated lines? The `sort' command, for example, allows
this, and this is very useful when dealing with filenames.
Or is such functionality already
Martin Bernreuther wrote:
Hello,
if I invoke date, e.g.
~ date
So 23. Sep 20:33:39 CEST 2007
and especially using a relative date
with next and a weekday, like
~ date --date=next sunday
So 23. Sep 00:00:00 CEST 2007
I don't get the next sunday, but this sunday (today)
on a
Justin Watt wrote:
It'd be great if sort had an option to sort by the -h output of
the du command.
For example the current output of du is alphabetized by filename with
no options to sort:
$ du -h --max-depth=1
4.0K./bin
52M ./code
765M./Desktop
12K ./mail
17M
[EMAIL PROTECTED] wrote:
Hello there.
I think I have noticed a bug in 'sort' program, version 5.97.
When I try to sort a non-empty file and I redirect the input
to the same file as follows
$ sort testfile testfile
the file suddenly gets empty. I think the program should sort
the file
Jim Meyering wrote:
I'm beginning to wonder if this is an error in the C library after all.
Surely POSIX doesn't intend to require that all programs test every
*printf return value. That would be silly. If so, what's the point
of the stream error indicator?
You make a fair point.
Perhaps
Jim Meyering wrote:
Bruno Haible [EMAIL PROTECTED] wrote:
But my libc's printf() returned -1, signalling failure. coreutils interpreted
that as was empty output, ok. I would have expected an error message and an
exit status of 1.
Strange indeed.
Could it be a bug in printf for failing, yet
Andreas Schwab wrote:
Where do you think it is buggy? This is the classical effect of double
rounding, and the printf formatting is doing exactly the right thing.
Yes you are right.
I misread my own test (again).
sigh,
Pádraig.
___
Bug-coreutils
Jim Meyering wrote:
Here are the ChangeLog entries since the 354-68c33a snapshot:
-
2007-11-01 Jim Meyering [EMAIL PROTECTED]
Adjust a seq subtest not to depend on the vagaries of floating point.
* tests/misc/seq (float-3): Use 10.94 as
Pádraig Brady wrote:
Andreas Schwab wrote:
Where do you think it is buggy? This is the classical effect of double
rounding, and the printf formatting is doing exactly the right thing.
Yes you are right.
I misread my own test (again).
Actually I did not misread it. I added those tests
I found the info page describing the
options for the split command somewhat confusing.
Hopefully the attached version is better.
Pádraig.
From f6307e244b499f572fcdf0b8aa40450fa1ca5fdf Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= [EMAIL PROTECTED]
Date: Wed, 21 Nov 2007
Castor, David A Capt MNF-I JNCC-I Centaf LNO wrote:
Regarding the dd tool, the man page seems to be lacking information
about how noerror handles a read errors when encountered...does dd drop
the entire block of data? does it pad the output to compensate for the
unreadable data?
I don't think
Vincent Rossetto wrote:
Hi
I have the coreutils version 5.97.
I wonder why the behaviour of seq is different
for integer and non-integer INCREMENT.
Examples:
$ seq 10 10 30
10
20
30
$ seq 0.1 0.1 0.3
0.1
0.2
$
According to the man page, it should be the same result
namely
Jim Meyering wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
On Tuesday 25 December 2007, Andreas Schwab wrote:
Andreas Schwab [EMAIL PROTECTED] writes:
Brian Dessent [EMAIL PROTECTED] writes:
Daniel C. Bastos wrote:
I always miss these two programs on every system I meet. argv0 is very
Jim Meyering wrote:
James Youngman [EMAIL PROTECTED] wrote:
On Jan 5, 2008 11:34 PM, Jim Meyering [EMAIL PROTECTED] wrote:
diff --git a/NEWS b/NEWS
index 5285d51..5b1b366 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ GNU coreutils NEWS-*-
outline -*-
[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.
___
Francky Leyn wrote:
Hello,
I'm seeking for some way to revert the order of lines. The first line
read thus must get out last and the last read must be output first.
Although it's easy to write a program for it, I'm wondering if this
is not possible with the UNIX toolbox. Any ideas?
I
Bob van Loosen wrote:
Hi everyone,
Whenever I do this:
tail -f /var/log/kern.log | cut -f 8- -d | dd bs=1
I get no output, but when I do this:
tail -f /var/log/kern.log | cut -f 8- -d
I do get output, I'm using coreutils 5.97 on Ubuntu 7.10 64 bit.
I've documented that exact
James Youngman wrote:
+ join now has a --check-order option which causes join to verify that
+ the input files are indeed sorted. The option --nocheck-sorted
+ turns the check off (the check is currently off by default).
I'm not sure it's worth adding this option.
If you know to use it,
James Youngman wrote:
On Feb 17, 2008 12:16 AM, Pádraig Brady [EMAIL PROTECTED] wrote:
James Youngman wrote:
+ join now has a --check-order option which causes join to verify that
+ the input files are indeed sorted. The option --nocheck-sorted
+ turns the check off (the check
1 - 100 of 3096 matches
Mail list logo
