On 06/02/2013 11:09 PM, Javier Lopez wrote:
Hi,
Attached patch adds colorizing for *.pnm images. Pnm images are amongst others
generated by Xsane scans. Although they're basically text files, they are
considered as images (a file command returns Netpbm PPM rawbits image data
so their color
unarchive 11794 13902
forcemerge 11794 13902 14525
stop
On 06/01/2013 02:02 AM, Linda Walsh wrote:
in Coreutils 8.21.1.1 (x86_64) on snoozy
When I type in ls -k, I get a small listing (filenames only horizontally)
(and no sizes).
When I type in ls -lk, I get a long listing -- but it isn't
On 05/28/2013 02:38 AM, Jim Meyering wrote:
Paul Eggert wrote:
On 05/27/2013 06:04 PM, Jim Meyering wrote:
+lim=$(echo $SIZE_MAX | subtract_one_)
+lim=$(expr $lim - $max_BUFSIZ)
Sorry, I don't see how this will work either.
It's common for a GMP-less expr to handle values
only up to
unarchive 9987
stop
On 05/28/2013 10:10 AM, Ondrej Oprala wrote:
Hi,
I'd like to propose a patch based on
http://lists.gnu.org/archive/html/bug-coreutils/2011-11/msg00024.html .
The -{0,1} option is only enabled for some option combinations (as discussed
in above link)
although I have
On 05/26/2013 11:06 PM, Stefano Lattarini wrote:
* tests/misc/numfmt.pl: Here. This avoids a spurious failure when
/bin/sh is dash (as can happen on Debian systems).
---
tests/misc/numfmt.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/misc/numfmt.pl
On 05/27/2013 01:29 AM, Jim Meyering wrote:
Pádraig Brady wrote:
unarchive 13530
stop
Thanks.
...
@@ -358,6 +356,14 @@ elide_tail_bytes_pipe (const char *filename, int fd,
uintmax_t n_elide_0)
if (buffered_enough)
{
+ if (n_elide_0 != n_elide
On 04/25/2013 02:34 AM, Pádraig Brady wrote:
On 01/23/2013 11:58 PM, Lei Zhang wrote:
Hi All,
In the `split' program of coreutils 8.20, we found a bug which is similar
to the bug reported in bug#13530:
Invoking `split -C T' or `split -C P' or `split -C E' will cause memory
exhaustion
tag 14416 notabug
close 14416
stop
On 05/17/2013 02:33 PM, Konstantin Weber wrote:
Hello,
today I received a large text file with fixed-length data fields to import
them into our databases.
I used the mighty cut but had to discover that it stops inserting
output-delimiters when there are
tag 14391 notabug
close 14391
stop
grep is not a coreutils so closing this.
You may want to discuss this on the grep mailing list,
but I've added a couple of notes below.
On 05/12/2013 06:04 AM, Linda Walsh wrote:
My grep is :
grep (GNU grep) 2.14
Copyright (C) 2012 Free Software Foundation,
On 05/10/2013 11:55 AM, Pavel Machek wrote:
Hi!
On systems like linux, cp / -a --one-file-system (destination) will
not copy whole root filesystem. It is not cp's fault, but the
behaviour is quite surprising to the users, so maybe it would be worth
warning in man page?
Something like
On 05/06/2013 07:54 PM, Cojocaru Alexandru wrote:
On Mon, 29 Apr 2013 00:59:20 +0100
Pádraig Brady p...@draigbrady.com wrote:
So I reinstated the bit vector which was a little tricky
to do while maintaining performance, but it works very well.
I think it works because we are avoiding
On 05/07/2013 01:10 PM, Pádraig Brady wrote:
On 05/06/2013 07:54 PM, Cojocaru Alexandru wrote:
On Mon, 29 Apr 2013 00:59:20 +0100
Pádraig Brady p...@draigbrady.com wrote:
So I reinstated the bit vector which was a little tricky
to do while maintaining performance, but it works very well.
I
tag 14318 notabug
stop
On 04/30/2013 02:37 AM, Kenneth Dickman wrote:
Why does putting depot in the input file, corrupt the sort function? How
can I get sort to operate properly?
$ cat good
bin/... //b/bin/...
logs/... //logs/...
... //b/...
$ sort good
... //b/...
bin/... //b/bin/...
On 04/28/2013 12:44 PM, Cojocaru Alexandru wrote:
On Sun, 28 Apr 2013 02:51:13 +0100
Pádraig Brady p...@draigbrady.com wrote:
So looking in detail, this central print_kth function is of most importance
to performance.
I made the same conclusion as yours, see:
http://lists.gnu.org
On 04/28/2013 07:14 PM, Cojocaru Alexandru wrote:
On Sun, 28 Apr 2013 15:04:31 +0100
Pádraig Brady p...@draigbrady.com wrote:
On 04/28/2013 12:44 PM, Cojocaru Alexandru wrote:
Another problem may be the merging and the call to `xrealloc' that
we do at the end of `set_fields'.
That's only
So I reinstated the bit vector which was a little tricky
to do while maintaining performance, but it works very well.
So in summary with the attached 3 patch series, the CPU
usage of the common cut path is nearly halved, while the
max memory that will be allocated for the bit vector is 64KiB.
severity 14283 wishlist
On 04/27/2013 03:26 AM, Linda Walsh wrote:
Just as 'l's displays the presence of access lists by putting a
'+' after the normal mode-bits, perhaps it could put a '^' after
mode-bits to indicate capabilities are set.
I'm aware that if I'm on a color terminal I can get
On 04/26/2013 05:11 PM, Pádraig Brady wrote:
This separate patch to simplify the print_kth() function
by removing the comparison from it, is simple and
has a significant perf advantage. Tests pass so I'll apply.
I'll adjust the commit log to summarise the perf change,
but I notice
On 04/26/2013 05:07 PM, Pádraig Brady wrote:
I've rebased this to master and attached.
The rebase wasn't trivial so I might have messed up.
The cut.pl test is now failing on master. Could you have a look.
Also could you add a test (or just a bit of shell) to demonstrate
which options
forcemerge 14275 13127
stop
On 04/26/2013 02:02 PM, Cojocaru Alexandru wrote:
Hi,
a while ago I've sent a patch. Could it be applied now?
You can find it here:
http://lists.gnu.org/archive/html/bug-coreutils/2012-12/msg00032.html
PS: I've already assigned the copyright to the FSF.
I've rebased this to master and attached.
The rebase wasn't trivial so I might have messed up.
The cut.pl test is now failing on master. Could you have a look.
Also could you add a test (or just a bit of shell) to demonstrate
which options the memory is not allocated for example.
Ideally some
This separate patch to simplify the print_kth() function
by removing the comparison from it, is simple and
has a significant perf advantage. Tests pass so I'll apply.
I'll adjust the commit log to summarise the perf change,
but I notice the change isn't as great as yours on my sandybridge i3
On 04/26/2013 11:49 PM, Alexandru Cojocaru wrote:
The cut.pl test is now failing on master. Could you have a look.
I had no problems. Could you show me your output?
Ah the failures are in tests I added in the meantime:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=51ce0bf8
On 04/25/2013 08:15 AM, Bernhard Voelker wrote:
On April 25, 2013 at 12:08 AM Pádraig Brady p...@draigbrady.com wrote:
While I'm slightly hesitant above adding support for
this closed source file system, there is precedence,
and I see the clients are GPL.
So I propose to support
On 04/25/2013 09:53 AM, Pádraig Brady wrote:
On 04/25/2013 08:15 AM, Bernhard Voelker wrote:
On April 25, 2013 at 12:08 AM Pádraig Brady p...@draigbrady.com wrote:
While I'm slightly hesitant above adding support for
this closed source file system, there is precedence,
and I see the clients
On 04/24/2013 07:47 AM, Guenter Ressel-Herbert wrote:
Folks,
my name is Guenter Ressel-Herbert and I'm working in Quantum's StorNext
Sustaining Engineering team.
I have a customer that needs support for tail -f on our StorNext SAN clients.
StorNext (ex cvfs) is a distributed
file system
On 01/23/2013 11:58 PM, Lei Zhang wrote:
Hi All,
In the `split' program of coreutils 8.20, we found a bug which is similar
to the bug reported in bug#13530:
Invoking `split -C T' or `split -C P' or `split -C E' will cause memory
exhaustion.
However, smaller units (e.g., K, M, G) work
On 04/23/2013 01:57 PM, Camion SPAM wrote:
Hello, I could like to suggest the following patch for tee.
It addresses the following problems :
1/ Add a new -t parametre to have tee work line per line instead of block by
block (Usefull if you use tee to check script results while they are sent
On 04/18/2013 01:24 PM, Donald Berry wrote:
If an invalid TZ argument is passed to /bin/date, it silently fails but
prints the UTC result:
[dberry@dberry ~]$ TZ=EDT date -d @0
Thu Jan 1 00:00:00 EDT 1970
[dberry@dberry ~]$ TZ=foo date -d @0
Thu Jan 1 00:00:00 foo 1970
It works
On 04/18/2013 08:41 AM, George Brink wrote:
On Wed, Apr 17, 2013 at 9:13 PM, Pádraig Brady p...@draigbrady.com wrote:
On 04/17/2013 02:26 PM, George Brink wrote:
Hello,
I have a task of extracting several fields from the text file. The
standard `cut` tool could be a perfect tool for a job
On 04/17/2013 02:26 PM, George Brink wrote:
Hello,
I have a task of extracting several fields from the text file. The
standard `cut` tool could be a perfect tool for a job, but...
In my file the '\n' character is a legal symbol inside fields and therefore
the text file uses other symbol for
forcemerge 14113 7176
stop
On 04/01/2013 01:38 PM, Mihai Capotă wrote:
The units used in the outputs of human-readable and si look
identical when K/k is not present. Add two block_size_args, binary
and decimal, that disambiguate between the outputs of human-readable
and si by adding human_B
On 01/23/2013 12:34 PM, Pádraig Brady wrote:
On 01/23/2013 02:32 AM, Lei Zhang wrote:
Hi All,
We found a bug in the `head' program of coreutils 8.20:
Invoking `head -c -P' or `head -c -E' will cause memory exhaustion.
However, smaller units (e.g., b, K, M) work fine; bigger units (e.g., Z
On 04/12/2013 10:30 PM, Ellis N. Thomas wrote:
On 12 Apr 2013, at 02:37, Pádraig Brady wrote:
Great thanks.
That shows that the gid of the files is 80, which I presume is
separate to your gid. That can happen if you're in a dir hierarchy
that's g+s to a group other than your own.
Hmm I
Bringing back on list.
I didn't intend to take off list sorry.
Details below...
On 04/11/2013 06:57 AM, Gao, Jie (Kyrie, HPIT-DS-CDC) wrote:
On 04/10/2013 09:53 PM, Pádraig Brady wrote:
On 04/10/2013 10:48 AM, Gao, Jie (Kyrie, HPIT-DS-CDC) wrote:
Hello sir,
Not sure if it is tee's
On 04/11/2013 03:30 PM, Ellis N. Thomas wrote:
Pádraig,
The Gnu bug-coreutils Archives does not seem to have linked
my reply message of April 10, 2013, and your reply as below, to our
previous messages for bug#14024 on and before March 27, 2013.
See my message of 27 March 2013
Could you indicate the file system you're using,
and give the output of:
echo test a
/usr/local/bin/install -Cv -m0644 a b
/usr/local/bin/stat a b
/usr/local/bin/install -Cv -m0644 a b
thanks,
Pádraig.
On 04/07/2013 08:20 AM, Linda Walsh wrote:
Rémy Lefevre wrote:
[ Pádraig Brady wrote:
Doing that though breaks `ln -sr target1 target2 dir` where dir is a
symlink.
]
But could you provide me an example where the final component of the link
should be resolved ?
---
What happens
On 04/07/2013 10:59 AM, Enrico Scholz wrote:
Pádraig Brady p...@draigbrady.com writes:
What system does the build fail on as a matter of interest.
This will occur on any system that has umask set to 022. Here is an
example:
$ umask 022
$ touch foo
$ chmod ug+w foo
$ chmod -w
On 04/06/2013 01:23 PM, Enrico Scholz wrote:
'chmod -w' is not portable and breaks the build:
| WARNING: Cannot create proper 'hostid.1' man page, since perl is missing or
| WARNING: inadequate on this system. Creating a stub man page instead.
| chmod: man/hostid.1-t: new permissions are
On 04/06/2013 11:27 PM, Bob Proulx wrote:
Pádraig Brady wrote:
- chmod -w $@-t \
+ chmod a-w $@-t \
I'll apply that fix.
I think it is always a good idea to use 'a' when there isn't any other
On 04/02/2013 11:30 AM, Rémy Lefevre wrote:
I'm not sure to understand your first sentence. Resolving the last component
is already the existing behavior, but maybe not the intended one.
Anyway, I agree that the path should be resolved without its last component.
I wrote a new patch for
On 04/04/2013 12:06 AM, Bernhard Voelker wrote:
On 04/03/2013 07:43 PM, Pádraig Brady wrote:
Subject: [PATCH 1/2] ln: --relative: fix updating of existing symlinks
Don't dereference an existing symlink being replaced.
I.E. generate the symlink relative to the symlink's containing dir
On 04/01/2013 03:40 PM, Rémy Lefevre wrote:
Overwriting relative symlink leads to undesirable behavior. Consider the
following example:
# Create some directories
mkdir test
mkdir test/folder1
mkdir test/folder2
#Create some files
touch test/folder1/file1
touch test/folder1/file2
On 04/01/2013 09:10 PM, Rémy Lefevre wrote:
Rémy.
2013/4/1 Pádraig Brady p...@draigbrady.com mailto:p...@draigbrady.com
On 04/01/2013 03:40 PM, Rémy Lefevre wrote:
Overwriting relative symlink leads to undesirable behavior. Consider the
following example
On 03/27/2013 11:47 AM, Ellis N. Thomas wrote:
Pádraig,
Thanks for your response and provision of 8.21.
I have rebuilt coreutils just to see if the test bug
is still present. Unfortunately, this shows two more!
Results of grep FAIL: tests/test-suite.log
FAIL:
On 03/27/2013 09:08 PM, Ellis N. Thomas wrote:
Pádraig,
Concerning the file system: The Apple Finder 'get info' on the hard
drive says:
Format :Mac OS Extended (Journaled)
and mount for root says:
mount
/dev/disk0s2 on / (hfs, local, journaled)
I could not locate
On 03/20/2013 10:01 PM, Joseph Chen wrote:
Not sure if this is an already known issue but I was asked to report this
error:
tail: unrecognized file system type 0x24051905 for
'/var/log/asterisk/messages'. please report this to bug-coreutils@gnu.org.
reverting to polling
This file that
On 03/21/2013 04:55 PM, Ellis N. Thomas wrote:
Test failure in coreutils 8.13
To: bug-coreutils@gnu.org
1 Background
The release used was NOT the latest, so it is quite likely that these
matters
have been previously addressed. On the other hand, it is possible that
On 03/21/2013 04:55 PM, Ellis N. Thomas wrote:
Configure problem in coreutils 8.13
To: bug-coreutils@gnu.org
1 Background
The release used was NOT the latest, so it is quite likely that these
matters
have been previously addressed. On the other hand, it is possible that
On 03/22/2013 02:10 PM, Pádraig Brady wrote:
So it seems on your system that the lib is available to the linker
but the header is not. We can work around that in configure
with the attached patch.
The last patch should have fixed the build issue,
but wouldn't have issued a warning that GMP
On 03/22/2013 04:03 PM, Eric Blake wrote:
On 03/22/2013 09:45 AM, Pádraig Brady wrote:
@table @samp
@item a
named character, ignoring high-order bit
@item c
-ASCII character or backslash escape,
+printable single byte character or backslash escape,
Hmm, we output octal sequences
On 03/14/2013 03:10 PM, Thomas Wolff wrote:
Hi,
the coreutils 'expand' fails on multi-byte characters (test file attached).
Please make it locale-aware.
Kind regards,
Thomas
You're in luck.
We're actually working on that at present:
On 03/13/2013 09:34 PM, Eric Blake wrote:
On 03/13/2013 02:16 PM, Marc Grondin wrote:
Good Afternoon,
Hello, and thanks for the report.
My client was attempting to run the command : od -c on this xml file (sample
only)
On 03/11/2013 08:39 PM, Tyler Hobbs wrote:
If I run stat --printf='%D', the result is 10ca70, which is correct.
However, if I run stat --printf='%t %T' /mountpoint, the result is
erroneously 0 0. If I instead run stat against the device directly (stat
--printf='%t %T' /dev/xvdx), I get the
tag 13919 notabug
close 13919
stop
On 03/10/2013 12:44 PM, 王宾 wrote:
--
hi,
As we know:
[polar@localhost my_shell]$ echo $PATH
/usr/local/Trolltech/Qt-4.7.4/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/polar/bin:/sbin
[polar@localhost
tags 13896 notabug
close 13896
stop
On 03/07/2013 04:21 AM, Shahram Farhadi Nia wrote:
I get the following error when making the attached Makefile
basename: extra operand `rm'
Can you help me with that?
$ basename 1 2 3
basename: extra operand `3'
$ basename 1 2 3
1
forcemerge 13894 12820
stop
On 03/06/2013 11:49 PM, Souvik Banerjee wrote:
I was trying to compile coreutils v8.21 on my system (Arch GNU/Linux). One
of the tests failed when compiling.
Here is src/coreutils-8.21/gnulib-tests/test-suite.log:
tag 13893 notabug
stop
I agree with the analysis here.
We can open again if necessary.
thanks,
Pádraig.
On 02/12/2013 10:45 PM, Javier Lopez wrote:
Hi,
Attached patch adds colorizing for *.arc archives. This was suggested /
requested by zapman in lp #1088131:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1088131
Greetings,
Javier López
tag 13786 notabug
close 13786
stop
On 02/22/2013 10:14 AM, Doh Smith wrote:
Hi,
I could not get the pr command to fold the lines. Is this a bug?
I am using pr (GNU coreutils) 8.13 under GNU bash 4.2.24.
Here is an example - the following pr command produced an output that
instead of folding
On 02/19/2013 09:08 AM, Joachim Schmitz wrote:
-Original Message-
From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
Sent: Tuesday, February 19, 2013 9:18 AM
To: '10...@debbugs.gnu.org'; 'bug-gnu...@gnu.org'
Subject: coreutils-8.21, some changes needed
Hi folks
In an attempt to
diff -EBbu ./src/numfmt.c.orig ./src/numfmt.c
-__attribute ((pure))
+__attribute__ ((pure))
Oops. I'll fix this up with a more extensive patch in coreutils.
3 patches attached.
thanks,
Pádraig.
From 8ebe5ae503a0f6955456bc94dc9c771cc579d533 Mon Sep 17 00:00:00 2001
From: Joachim Schmitz
On 02/19/2013 12:10 PM, Joachim Schmitz wrote:
You seem to have missed one change, unless I'm missing something? This is your
patch:
diff --git a/src/chroot.c b/src/chroot.c
index 1c1a976..bb45825 100644
--- a/src/chroot.c
+++ b/src/chroot.c
@@ -57,7 +57,7 @@ static struct option const
On 02/19/2013 04:25 PM, Paul Eggert wrote:
_Noreturn is typically put before the return type, e.g.,:
static _Noreturn void randread_error (void const *);
rather than putting the _Noreturn after the 'void',
or after the ')'.
C11 does not allow putting _Noreturn after the ')',
if I'm reading
On 02/11/2013 07:29 AM, Bernhard Voelker wrote:
On 02/11/2013 02:42 AM, Pádraig Brady wrote:
On 02/10/2013 10:11 PM, Bernhard Voelker wrote:
I'll push tomorrow unless I receive further comments.
+1
Thanks, pushed:
http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=b5f45b64
Actually I
On 02/09/2013 08:45 PM, Paul Eggert wrote:
On 02/09/2013 11:26 AM, Pádraig Brady wrote:
These are function names and not to be translated.
These are developer debug strings, which I'm tempted to remove entirely.
Certainly simple_strtod_human:\n should not be translated,
as it's referring
On 02/10/2013 06:55 PM, Benno Schulenberg wrote:
Hi,
The new command numfmt includes a bunch of debugging messages that
are only meant for the developers. They shouldn't be gettextized.
Offering things up for translation which are only for developers
is a waste of translators' time. Attached
On 02/10/2013 07:10 PM, Benno Schulenberg wrote:
Hi,
The synopsis of numfmt currently says:
Usage: %s [OPTIONS] [NUMBER]
But multiple numbers are allowed, and a single option too,
so it should read:
Usage: %s [OPTION]... [NUMBER]...
Further, the command description says:
Reformat
On 02/10/2013 05:15 PM, Bernhard Voelker wrote:
On 02/10/2013 05:28 PM, Pádraig Brady wrote:
I've cleaned this up in the attached so that both use the same
method to output the messages, and both now enable these messages
with the the same ---debug option.
Also translations are removed from
On 02/10/2013 10:35 PM, Bernhard Voelker wrote:
On 01/23/2013 11:48 AM, Ondrej Oprala wrote:
Hi Bernhard,
thanks for the remarks. Also, you were right about the corner case, the
succession of commands
$ touch a
$ dd if=a seek=1 bs=1
$ ^D
actually caused a segfault. Sorry, I didn't notice it
On 02/10/2013 10:11 PM, Bernhard Voelker wrote:
On 02/10/2013 09:34 PM, Benno Schulenberg wrote:
On Sun, Feb 10, 2013, at 21:01, Pádraig Brady wrote:
I'll apply this for the upcoming release.
Thanks. Just to be sure: this will require a pre3, if translations
are meant (where possible
On 02/09/2013 06:42 PM, Göran Uddeborg wrote:
I started the translation of coreutils 8.20-pre2 which just arrived
via the Translation Project. I got a bit uncertain about messages
like:
msgid
simple_strtod_human:\n
input string: '%s'\n
locale decimal-point: '%s'\n
and
On 01/14/2013 09:08 AM, Jim Meyering wrote:
Benno Schulenberg wrote:
On Fri, Jan 11, 2013, at 8:39, Jim Meyering wrote:
wwarn (_(%s: read failed), src_name);
When things go wrong, I would prefer to see a word like
failed, error, mistake, bad, invalid or mayday
at the beginning of
tag 13640 notabug
close 13640
stop
On 02/06/2013 06:27 PM, Cojocaru Alexandru wrote:
I am trying to compile from the git master and I am getting the following error:
make[2]: *** No rule to make target `doc/perm.texi', needed by
`doc/coreutils.info'. Stop.
How to fix it?
That file is
On 02/04/2013 09:22 AM, Marcel Böhme wrote:
Dear all,
The current version of cut (after 6.12.2012) exposes a SEG_FAULT:
$echo 123 | cut --output-del=. -b-1,9-
How the commit introduces the bug:
Earlier, memory of length eol_start_length was allocated for the array
On 02/04/2013 01:23 PM, Marcel Boehme wrote:
Dear Pádraig,
For completeness, would it be possible to reference the bug introducing
revision (ec48bead) in the commit message?
Otherwise, the commit looks good to me.
Cool thanks.
Updated patch attached.
From
On 01/31/2013 07:06 PM, j...@dockes.org wrote:
When moving a file having extended attributes to a target filesystem which
does not support them (e.g. an NFS mount), the attributes are silently
lost.
I think that mv should not complete the move in this case, as the current
behaviour leads to
On 01/23/2013 05:44 PM, Stephan Krempel wrote:
Hi there,
If the calling process has SIGALRM blocked, timeout simply never times out.
Find attached a small program to demonstrate the problem and a patch to
fix it by unblocking the necessary signal (at least on x86/linux).
The sigprocmask
On 01/23/2013 12:53 PM, Bernhard Voelker wrote:
On 01/23/2013 01:34 PM, Pádraig Brady wrote:
There is the argument that we _should_ allocate
everything up front to indicate immediately
that the system can't (currently) support the requested operation,
but given the 'currently' caveat above I
On 01/23/2013 01:21 PM, Bernhard Voelker wrote:
On 01/23/2013 02:03 PM, Pádraig Brady wrote:
On 01/23/2013 12:53 PM, Bernhard Voelker wrote:
head doesn't allocate everything up front - instead, it only
allocates the pointer array which would hold the actual data.
Sure. I was wondering
On 01/22/2013 10:43 AM, Marcel Böhme wrote:
Dear all,
There is another bug that sneaked into the speed patch of seq on 13.09.12:
560 if (all_digits_p (argv[optind])
561(n_args == 1 || all_digits_p (argv[optind + 1]))
562(n_args 3 || STREQ (1, argv[optind + 2]))
563
On 01/22/2013 11:23 AM, Pádraig Brady wrote:
On 01/22/2013 10:43 AM, Marcel Böhme wrote:
Dear all,
There is another bug that sneaked into the speed patch of seq on 13.09.12:
560 if (all_digits_p (argv[optind])
561(n_args == 1 || all_digits_p (argv[optind + 1]))
562(n_args
On 01/22/2013 12:17 PM, Pádraig Brady wrote:
On 01/22/2013 11:23 AM, Pádraig Brady wrote:
On 01/22/2013 10:43 AM, Marcel Böhme wrote:
Dear all,
There is another bug that sneaked into the speed patch of seq on 13.09.12:
560 if (all_digits_p (argv[optind])
561(n_args == 1
On 01/22/2013 12:28 PM, Bernhard Voelker wrote:
On 01/22/2013 01:17 PM, Pádraig Brady wrote:
Updated patch attached.
That one is looking good ... but while we're at it:
Anyone tried this, i.e. a Zero as INCREMENT?
$ seq 1 0 2
This is equal to `yes 0`. Well, this is probably
Proposed patch at:
http://lists.gnu.org/archive/html/coreutils/2013-01/msg00076.html
On 01/21/2013 07:51 PM, Assaf Gordon wrote:
Hello,
Testing the latest coreutils on Mac OS X, tests/rm/unread3 fails.
The immediate cause is:
rm: unable to record current working directory: Too many open files
Attached is the relevant part from the log file.
The programs were compiled
On 01/09/2013 10:08 AM, Pádraig Brady wrote:
On 01/09/2013 07:36 AM, Bernhard Voelker wrote:
why not check input_seekable where it is set - ~60 lines above?
I was trying to keep related code together.
Thanks for all the reviews, which I've fixed locally.
To provide an argument for why
On 01/15/2013 02:27 PM, Jim Meyering wrote:
Pádraig Brady wrote:
...
I could go either way.
There is precedent, but it's such a corner case,
it may not be worth the added code.
given the confusion above, it might be worth the
clarification error message.
Yes, I've demonstrated that rather
On 01/10/2013 08:06 PM, Paul Eggert wrote:
On 01/10/13 11:20, Benno Schulenberg wrote:
Several error messages in some of the utilities say things
like reading %s. They sound like progress messages, and
translators might be tempted to translate them as if they
said busy reading %s
-
tag 13464 notabug
close 13464
stop
On 01/16/2013 06:05 PM, PK wrote:
Hi,
readlink -m file displays the absolute path of a file
The bug is that it displays, even if the file is non-existent.
This does not solve the purpose and I see it creates more ambiguity in
showing a non-existent file.
$
On 01/15/2013 08:23 AM, Ken Irving wrote:
(Previously sent in error to the bug-gnu-utils list.)
I've been using symbolic links in a non-file-related way, e.g., to store
arbitrary string values, but find that if I try to create a symlink with
an empty 'target' name, e.g., as 'ln -s foo', the
On 01/15/2013 09:31 AM, Jim Meyering wrote:
Pádraig Brady wrote:
On 01/15/2013 08:23 AM, Ken Irving wrote:
(Previously sent in error to the bug-gnu-utils list.)
I've been using symbolic links in a non-file-related way, e.g., to store
arbitrary string values, but find that if I try to create
unarchive 6394
forcemerge 6394 13301
stop
Note I documented how to achieve this with `awk` or `join`
in the coreutils cut documentation at:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=38cdb01
thanks,
Pádraig.
On 11/17/2012 10:56 AM, Benno Schulenberg wrote:
From 855f5c860acb350125476765cf064f6ccc4d2aaa Mon Sep 17 00:00:00 2001
From: Benno Schulenbergbensb...@justemail.net
Date: Sat, 17 Nov 2012 11:49:21 +0100
Subject: [PATCH] uptime: gettextize an overlooked string, and normalize another
*
On 01/10/2013 07:23 PM, Benno Schulenberg wrote:
From 1874463b2f554378cd2b71f21b3b0fc03f7b116a Mon Sep 17 00:00:00 2001
From: Benno Schulenbergbensb...@justemail.net
Date: Fri, 4 Jan 2013 22:07:49 +0100
Subject: [PATCH 1/2] ln: make a help text fragment identical to three others
Pushed with
On 01/10/2013 07:20 PM, Benno Schulenberg wrote:
Hi,
Several error messages in some of the utilities say things
like reading %s. They sound like progress messages, and
translators might be tempted to translate them as if they
said busy reading %s -- whereas I think they are trying
to say
On 01/09/2013 07:36 AM, Bernhard Voelker wrote:
why not check input_seekable where it is set - ~60 lines above?
I was trying to keep related code together.
Thanks for all the reviews, which I've fixed locally.
To provide an argument for why this shouldn't go in,
the following is equivalent:
On 01/09/2013 11:01 AM, Erik Auerswald wrote:
Hi,
On 01/09/2013 11:34 AM, Bernhard Voelker wrote:
On 01/09/2013 11:14 AM, Marcel Böhme wrote:
There are the following problems with the -w parameter of the seq tool:
[...]
Hmm, according to the TEXI manual, the FIRST number should also use
a
On 01/08/2013 08:55 PM, Paul Eggert wrote:
On 01/08/13 10:11, Neil Klopfenstein wrote:
Note that it begins reading at the _beginning of the ar file_ -- the 'skip'
argument has failed silently.
But the 'skip' hasn't failed. It's merely being implemented via 'read'
rather than via 'lseek'.
1501 - 1600 of 3108 matches
Mail list logo
