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-sorte
Steven Schubiger wrote:
> Attached is a patch that enhances seq's diagnostics. If you agree
> that this is the right way to go, I'll amend other files (ChangeLog,
> etc.) as needed.
Seems sensible. This is what I get on a reasonably recent tree:
$ ./seq -f% 1
./seq: memory exhausted
Note however
James Youngman wrote:
> This is a consolidated patch including all the previous changes,
> implementing order checking in join by default. "make distcheck"
> works (if I move distcheck-hook from Makefile.am to GNUmakefile).
While I like the idea, I'm a little worried about the implementation.
You
Jim Meyering wrote:
> Russell Coker <[EMAIL PROTECTED]> wrote:
>> If I have a file that is 2G in size but wish to discard the last 1G of data
>> then there seems to be no program available to do this.
>>
>> I think it would be ideal to have a program as part of coreutils that allows
>> you to resiz
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
handy when dealing with programs that care about argv[0] and psfoo
Jim Meyering wrote:
> Paul Eggert <[EMAIL PROTECTED]> wrote:
>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>> If you don't mind truncating first, how about this?
>>>
>>> true > /var/spool/whatever/foo
>>> dd bs=1 seek=2G of=/var/spool/whatever/foo < /dev/null
>> Also, the latter command work
Russell Coker wrote:
> On Tuesday 26 February 2008 21:03, Pádraig Brady <[EMAIL PROTECTED]> wrote:
>>> That depends on your definition of "works".
>>> If you don't mind retaining the first 2GiB of content in
>>> a preexisting output file, the
Heijnen wrote:
> Hi,
>
> I want to report a bug in "sort" utility.
For the umpteenth time this locale "bug" has been reported,
because the default behaviour is unexpected and fixing it requires
knowledge of how locales and environment variables work.
I wonder should we flag the common case on ex
Eric Blake wrote:
> Pádraig Brady draigBrady.com> writes:
>
>> I wonder should we flag the common case on exit with something like:
>>
>> if (only_ascii_read && LC_COLLATE!="C" && !LC_ALL) {
>>fprintf(stderr, "Warning, sorting
Eric Blake wrote:
> Pádraig Brady draigBrady.com> writes:
>
>>> Nice thought. But it would violate POSIX if done by default
>> POSIX says you can't warn users about potential problems?
>
> One person's bug is another person's feature. The entir
Tony Kocurko wrote:
> Hi, All...
>
> It might be that the man page for sort needs some
> polishing. I discovered that in the "-k F[.C],F[.C]"
> command line argument pair, for fields beyond the
> first, the first character appears to be the first
> delimiter character prior to the field.
That (c
Jari Aalto wrote:
> Package: coreutils
> Version: 6.10-3
> Severity: wishlist
>
>
> Description:
>
> $ wc -l README
> 200 README
>
> This is fine for interactive use, but not convenient in shell scripts,
Options are bad because of the extra complexity presented to users.
Currently
Thomas Guettler wrote:
> Hi,
>
> I use "du -ax / | sort -rn > /var/tmp/du-`date --iso`" to get the sorted
>
> Unfortunately you can't see a difference between a directory and a file
> in the output. It would be nice if the directories would be added by a
> slash.
>
> This way you can see if a li
Hi Karel,
I've attached a patch to add the "timeout" utility
which was previously discussed on coreutils and util-linux-ng lists.
I've tested this in a lot of situations and have
noted the following caveats:
If you start a command in the background, which reads from the tty
and so is immediately
Thomas Guettler wrote:
> Hi,
>
> I use "du -ax / | sort -rn > /var/tmp/du-`date --iso`" to get the sorted
> total size of all
> files and directories.
>
> Unfortunately you can't see a difference between a directory and a file
> in the output. It would be nice if the directories would be added by
Eric Blake wrote:
> I don't think you can do it by default - it must be via an option. POSIX
> states:
>
> ~The output from du shall consist of the amount of space allocated to a
> file and the name of the file, in the following format:
>
> ~"%d %s\n", ,
>
> http://www.opengroup.org/on
Thomas Guettler wrote:
> Pádraig Brady schrieb:
>> Thomas Guettler wrote:
>>
>>> Hi,
>>>
>>> I use "du -ax / | sort -rn > /var/tmp/du-`date --iso`" to get the sorted
>>> total size of all
>>> files and directories.
>&g
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Thomas Guettler wrote:
>>> Thank you for being interested. I wrote a patch which makes the slash
>>> optional:
>>>
>>> src/du --help:
>>> ...
>>> -z, --dir-with
Thomas Guettler wrote:
>>> I'm very dubious about adding this as an option.
>>> Do you really think an option is warranted for this,
>>> considering you can already get the desired behavior
>>> with a small wrapper, as I demonstrated:
>>>
>> The wrapper is awkward, but it's better than a new o
Pádraig Brady wrote:
> find / -xdev -printf "%p%y\n" |
> sed 's/d$/\//;t; s/.$//;' |
> tr '\n' '\0' |
> xargs -r0 du -s |
> LC_ALL=C sort -rn -k1,1
Note that will give the output you want but will be very inefficient :(
So Jim
Eric Blake wrote:
> According to [EMAIL PROTECTED] on 3/15/2008 10:33 PM:
> | (P.S., you might enjoy writing `' instead of "", but it just leads to
> | cut and paste accidents sent to the shell, for me at least, about
> | twice a year.
>
> You do realize that it is possible to create a custom LC_M
Jim Meyering wrote:
> Eric Blake <[EMAIL PROTECTED]> wrote:
>> According to Jim Meyering on 3/25/2008 3:47 PM:
>> | - user_name = pwd ? pwd->pw_name : NULL;
>> | + user_name = pwd ? xstrdup (pwd->pw_name) : NULL;
>>
>> Doesn't this leak memory?
>
> Thanks for mentioning it, but I think o
Proposed truncate command attached
>From 34b9bc72ffe70ec83710b12021e889d5ae65e508 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <[EMAIL PROTECTED]>
Date: Wed, 26 Mar 2008 14:03:31 +
Subject: [PATCH] Add new program: truncate
* AUTHORS: Register as the author.
* NEWS: Mention
Take 2 attached
>From 345b3af13f3e44d365535b93691ae897b5512805 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <[EMAIL PROTECTED]>
Date: Thu, 27 Mar 2008 01:11:25 +
Subject: [PATCH] Add new program: truncate
* AUTHORS: Register as the author
* NEWS: Mention this change
* README
attached
>From e2c2d212bfea29540bb433bb8d00e1e9e9fd3ff6 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <[EMAIL PROTECTED]>
Date: Fri, 28 Mar 2008 11:05:55 +
Subject: [PATCH] Add new program: timeout
* AUTHORS: Register as the author
* NEWS: Mention this change
* README: Add ti
Mike Frysinger wrote:
> On Tuesday 01 April 2008, Pádraig Brady wrote:
>> + /* Setup handlers before fork() so that we
>> + * handle any signals caused by child, without races. */
>> + signal (SIGALRM, cleanup);/* our timeout. */
>> + signal (SIGINT, cleanup)
Jim Meyering wrote:
> Thanks!
>
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Subject: [PATCH] Add new program: timeout
> ...
>> +/* Given an integer value *X, and a suffix character, SUFFIX_CHAR,
>> + scale *X by the multiplier implied by SUFFIX_CHAR. SUFFI
Bo Borgerson wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Subject: [PATCH] Add new program: timeout
>
> Great idea for a tool!
Not my idea TBH:
http://mail.linux.ie/pipermail/ilug/2006-November/thread.html#90654
> Have you considered an alternate run-mode whe
Mike Frysinger wrote:
> On Wednesday 02 April 2008, Pádraig Brady wrote:
>> To be sure, are you referring to races where a signal
>> can be received while in the signal handler on some systems?
>>
>> Also there is the issue of restarting system calls
>> after the s
Bo Borgerson wrote:
> On Wed, Apr 2, 2008 at 10:20 AM, Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> It will always go through though as the kernel will buffer it.
>
> Yes, that introduces some fuzz, but I think the principle remains
> viable -- the kernel will only buffer
take 2 attached.
Note I kept the time interval parsing function
separate between `kill` and `timeout`, as they
operate on different types.
Pádraig.
>From 95c61d20933a749482c3d1d54eb3b1032735ab75 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <[EMAIL PROTECTED]>
Date: Fri, 28 Mar 2
James Youngman wrote:
> On Wed, Nov 15, 2006 at 1:19 AM, Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> It has been proposed to start the miscutils project,
>> to include utilities not seen as core to the system.
>> I.E. utilities that are of less general use, but
>
Matthew Woehlke wrote:
> [EMAIL PROTECTED] wrote:
>> | So far, it includes the following utilities:
>> | - sponge: soak up standard input and write to a file
>
> Eh? That sounds like 'cat > file'...
I was wondering that too.
It basically buffers the file in mem
so that one can modify a file thro
dd handles skip weirdly
disk=/dev/sda8
dd if=$disk bs=8M count=1 skip=1000 of=/dev/null #ok
dd if=$disk bs=8M count=1 skip=1000K of=/dev/null #reads whole disk! as seek
fails
I had a 10s look at the source and noticed a comment
saying POSIX doesn't specify what we should do when
skipping past t
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> dd handles skip weirdly
>>
>> disk=/dev/sda8
>> dd if=$disk bs=8M count=1 skip=1000 of=/dev/null #ok
>> dd if=$disk bs=8M count=1 skip=1000K of=/dev/null #reads whole disk! as seek
>> f
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>
>> Jim Meyering wrote:
>>> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>>>> dd handles skip weirdly
>>>>
>>>> disk=/dev/sda8
>>>> dd if=$disk bs=8M coun
Pádraig Brady wrote:
> There are actually 3 cases to consider with large skip values.
> Currently dd does the following for various values of skip:
>
> if skip > file_size && skip < max_file_size
> lseek returns new offset, and read() returns 0
>
>
Bruno Haible wrote:
> Jim Meyering wrote:
>>> - Processing in unibyte locales should not become significantly slower
>>> than before.
>>> - Code duplication should be avoided, for maintainability.
>>> - Macros which expand to one thing in the multibyte case and to another
>>> thing fo
Christopher Kerr wrote:
> After being burned by using `head -c6 /dev/urandom | base64` as part of a
> directory name, I realised that it would be useful if base64 had an option to
> generate URL and Filename safe encodings, as specified in RFC 3548 section 4.
>
> This would make
> cat FILE | bas
Bo Borgerson wrote:
> Pádraig Brady wrote:
>> Perhaps `tr '+/' '._'` would be better so that
>> you don't need to worry about "-" at the start of a filename?
>
>
> I'm think `.' at the beginning of a filename also has the poten
Jan Engelhardt wrote:
>
> https://bugzilla.novell.com/show_bug.cgi?id=381873
>
> Forwarding this because it is a GNU issue, not specifically a Novell one.
> I reproduced this myself with the latest coreutils from git
> (BTW: You might want to repack that repo, "counting objects" during the
> clon
Bo Borgerson wrote:
> Pádraig Brady wrote:
>> canonically équivalent
>> canonically équivalent
>>
>> Pádraig.
>>
>> p.s. I Notice that gnome-terminal still doesn't handle
>> combining characters correctly, and my mail client thunderbird
>>
Bo Borgerson wrote:
> Jim Meyering wrote:
>> Bo Borgerson <[EMAIL PROTECTED]> wrote:
>>> I may be misinterpreting your patch, but it seems to me that
>>> decrementing count for zero-width characters could potentially lead to
>>> confusion. Not all zero-width characters are combining characters, ri
Bo Borgerson wrote:
> Pádraig Brady wrote:
>> In the first 65535 code points there are also 404 chars which are
>> not classed as combining in the unicode database, but are classed
>> as zero width in the glibc locale data at least (zero-width space
>> being one of
Bruno Haible wrote:
> As a consequence:
> - The number of characters is the same as the number of wide characters.
> - "wc -m" must output the number of characters.
> - In a Unicode locale, is one character, and is
> two characters,
Fair enough.
> If you want wc to count characters af
>From 9228e10c4c68ffd585bbb6e5fd7efbab6f6c5f97 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <[EMAIL PROTECTED]>
Date: Mon, 19 May 2008 07:54:07 +0100
Subject: [PATCH] Clarify field delimiter description in uniq --help output
* src/uniq.c: Clarify in help output that field delimi
Jim Meyering wrote:
>> Hi Pádraig,
>>
>> Thanks!
>> Your summary is right, but the --help change is slightly
>> inaccurate, since "blank" can mean more than just SPC or TAB.
Yes you're right for non C locales.
In my en_IE.utf8 locale isblank() is the larger set of:
0009 TAB
0020 SPACE
1680 OGHAM
Jim Meyering wrote:
>
> I agree that more detail would be better.
> What do you think of this additional change?
>
> -A field is a run of blanks, then non-blank characters.\n\
> -Fields are skipped before chars.\n\
> +A field is a run of blanks (usually spaces and/or TABs), then non-blank\n\
> +c
Hauke Laging wrote:
> Hello,
>
> I just read an interesting hint in the German shell Usenet group
> (<[EMAIL PROTECTED]>). As I could not find anything about
> that point in your mailing list archive I would like to mention it here.
>
> The author claims that he achieved a huge performance incr
Eric Blake wrote:
> I just noticed the addition of the timeout command:
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=265c4b8
>
> But was this hunk to configure.ac intentional? It isn't mentioned in
> ChangeLog:
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit
There have been some interesting "counting UTF-8 strings" threads
over at reddit lately, all referenced from this article:
http://www.daemonology.net/blog/2008-06-05-faster-utf8-strlen.html
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
Bruno Haible wrote:
> Building coreutils 6.12.29-a16be on Solaris 7, with gcc 3.2.2. It fails
> like this:
>
> ===
>GNU coreutils 6.12.29-a16be: tests/test-suite.log
> ===
>
> 1 of 344 t
Bruno Haible wrote:
> Building coreutils-6.12.29-a16be on HP-UX 11.00, there are 3 failures.
>
> FAIL: misc/truncate-fail-diag.log (exit: 1)
> ===
>
> + dir=no/
> + truncate -s0 no/
> + 1> out 2>& 1
> + fail=1
So that's the same issue as solaris 7 had, yes
William Tambe wrote:
> Hi,
> Can you please add a synchronization feature to the GNU cp so that files
> not found in the source files/folders get removed from the destination
> folder?
>
> This is a very useful feature for backups without having to use very
> expensive routines.
>
> I know rsync
Joseph Butler wrote:
>
> Hello Tech Support:
>
> For some reason, I'm unable to remove duplicate lines using the uniq utility.
>
> Any solution to this issue would be appreciated.
Trailing whitespace:
sed 's/[ \r]*$//' test03 | sort | uniq -d
___
B
Bo Borgerson wrote:
> [EMAIL PROTECTED] wrote:
>> Hello
>> Few minutes ago i used sort -u for sorting big file(236 Mb). I have 2 core
>> cpu(core 2 duo), but i found that sort use only one cpu(work in one thread).
>> I think it is good idea to make option(or by default) for sorting in threads
>>
Poor Yorick wrote:
> Building latest snapshot of coreutils, coreutils-6.12.29-a16be, on SunOS 5.9,
> with gcc-4.2.2 and gnu ld:
>
> FAIL: misc/truncate-fail-diag.log
This is a bug in SunOS which is worked around in later gnulibs.
Please try the latest snapshot just released.
thanks,
Pádraig.
Poor Yorick wrote:
>> From: Pádraig Brady <>
>> Sent: 2008-06-21 14:19
>>
>> Poor Yorick wrote:
>> > Building latest snapshot of coreutils, coreutils-6.12.29-a16be, on SunOS
>> 5.9,
>> > with gcc-4.2.2 and gnu ld:
>> >
>&g
Michael Geng wrote:
> Hi,
>
> When I'm running make distcheck on the Coreutils I get an error message
>
> ...
> gcc -std=gnu99 -I. -I../lib -I../lib -Werror -ansi -Wno-long-long -MT
> truncate.o -MD -MP -MF .deps/truncate.Tpo -c -o truncate.o truncate.c
> cc1: warnings being treated as error
return 0;
> +}
> +
> + errno = (e == LONGINT_OVERFLOW ? EOVERFLOW : 0);
> + return -1;
> }
>
> static void
>
I reviewed all uses of off_t in the code and came up with
an almost identical patch, so I'm happy to go with the above.
Signed-off-by: Pádraig Brady
Michael Geng wrote:
> On Wed, Jun 25, 2008 at 08:19:56PM +0100, Pádraig Brady wrote:
>> Micheal there still is something wrong with your system I think.
>> Did you perhaps compile glibc from scratch and didn't pass
>> a required configure option for Large File Support?
&
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> Here's a tentative patch:
> ...
>> I reviewed all uses of off_t in the code and came up with
>> an almost identical patch, so I'm happy to go with the above.
Jim Meyering wrote:
> By the way, does %zu work reliably everywhere now?
> In the past, we've converted such values to strings via umaxtostr,
> to accommodate older systems.
>
> For ssize and nsize, I have a slight preference for the
> cast-free approach of using %s with imaxtostr.
Yes I suppose
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> By the way, does %zu work reliably everywhere now?
>>> In the past, we've converted such values to strings via umaxtostr,
>>> to accommodate older system
Poor Yorick wrote:
> compiling 6.12.70-4f470 with 64-bit gcc (with -m64) and 64-bit gnu ld on
> Solaris 9:
So on this system `timeout 4294967296 sleep 0` is invalid
but `timeout 49711d sleep 0` is OK?
The apply_time_suffix() function should be returning an
error for the latter case but is not.
I
Rather than relying on code inspection to find places
where signed ints would be erroneously promoted to unsigned,
I went looking for a gcc option to automatically detect this.
It's -Wsign-compare which is automatically included in -Wextra.
Note it might be good to add to README-hacking to run conf
Paul Eggert wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>> diff --git a/src/truncate.c b/src/truncate.c
>> index 02d4102..fd321c6 100644
>> --- a/src/truncate.c
>> +++ b/src/truncate.c
>> @@ -189,9 +189,9 @@ do_ftruncate (int fd, char const *f
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>
>> Paul Eggert wrote:
>>> This indicates a bug in the underlying code, which GCC was right to
>>> warn us about, and which we should not have worked around by inserting
>>> casts blindly
Jon Grant wrote:
> Hi,
>
> I am running dd from coreutils 6.10 on the latest Knoppix disc, trying
> to copy a failing drive to a new drive so i can try mount the partition.
>
> I noticed that dd tries the to read the same 512-byte block 40 times
> before giving up.
In addition if dd can't read t
Mildred wrote:
> Hi,
>
> I noticed that du takes a long time to scan directories and measure
> disk usage.
>
> I was thinking that perhaps caching the size of directories could bu
> useful. Perhaps, after du computes the size of a directory, it could
> write its size in its extended attributes (i
I noticed Jim fixed a couple obvious
issues highlighted by the -Wsigned-compare gcc option
we were talking about a few days ago.
The attached patch silences all other instances,
so that this option may be used to help find these
hard to spot errors, when they're introduced in future.
Note this pa
Pádraig Brady wrote:
> I noticed Jim fixed a couple obvious
> issues highlighted by the -Wsigned-compare gcc option
> we were talking about a few days ago.
>
> The attached patch silences all other instances,
> so that this option may be used to help find these
> hard to spot
This issue is still present on fedora 9 at least,
which you can confirm with this command:
printf " \tif\n" | expand --initial -t4 |
grep -qF "$(printf '\t')" && echo buggy
So it's worth adding a test I think.
cheers,
Pádraig.
>From b36ea40fc24c6d3aca6094de90657e067fa80ff6 Mon Sep 17 00:00:00 20
Pádraig Brady wrote:
> Mildred wrote:
>> Hi,
>>
>> I noticed that du takes a long time to scan directories and measure
>> disk usage.
>>
>> I was thinking that perhaps caching the size of directories could bu
>> useful. Perhaps, after du computes the si
Kamil Dudka wrote:
> Hello,
>
> as solution to rhbz #431997 and #449263 I propose patch for dd - support for
> reading of full blocks. This support is activated with dd parameter
> conv=fullblk. This patch has no effect if parameter conv=fullblk is omitted.
This feature makes a lot of sense.
I'
Pádraig Brady wrote:
> Kamil Dudka wrote:
>> Hello,
>>
>> as solution to rhbz #431997 and #449263 I propose patch for dd - support for
>> reading of full blocks. This support is activated with dd parameter
>> conv=fullblk. This patch has no effect if parameter c
Paul Eggert wrote:
> Pádraig Brady <[EMAIL PROTECTED]> writes:
>
>> or conv=wait, though I do have a strong preference
>> for iflag=block as it's the most accurate.
>
> I dunno, iflag= is supposed to be symmetric with oflag=.
Well there is no harm in having
Paul Eggert wrote:
> "James Youngman" <[EMAIL PROTECTED]> writes:
>
>> Although libgmp itself has no further dependencies other than the C
>> library, this is still a large-ish extra dependency. Should we also
>> introduce a --without-gmp option to configure?
>
> Yes, particularly if it's added
smu johnson wrote:
> Hi,
>
> I hope this is the right place to ask this. I think a very handy argument
> to add to the list of aliases for character classes in tr would be a new one
> that behaves like [:cntrl:], except that it will not include newline
> characters in that class.
>
> The reason
Same error happens on fedora.
So it's probably related to that horrible i18n patch applied
by distros but rightly used the upstream coreutils project.
$ file test
test: ISO-8859 text
$ echo $LANG
en_IE.UTF-8
$ rpm -q coreutils
coreutils-6.9-12.fc8
$ ~/git/coreutils/src/uniq --version
uniq (GNU
Jim Meyering wrote:
> I suspended a 'make check' run, and when I resumed it I was not
> surprised to see this particular test fail.
> Then I kicked myself for not thinking to use coreutils' own
> new timeout program before this.
I presume you mean suspended the machine here, rather than
suspended
Giuseppe Scrivano wrote:
> Hello,
>
> what do you think about the following way to remove the sigs_to_ignore
> hack in the timeout.c file?
> It ignores temporarily the signal inside the `send_sig' function instead
> of using the `sigs_to_ignore' array.
I'll test this tonight, as this stuff is tri
Klein, Roger wrote:
> Hi,
>
> Now I found a hint on the Web
> (http://www.programmersheaven.com/mb/linux/187697/245244/re-how-to-chang
> e-filesize-in-linux/?S=B2)
using `cut` to remove both truncate and "unsparse" files
is both inefficient an buggy. From the cut man page:
"cut - remove sec
Pádraig Brady wrote:
> Giuseppe Scrivano wrote:
>> Hello,
>>
>> what do you think about the following way to remove the sigs_to_ignore
>> hack in the timeout.c file?
>> It ignores temporarily the signal inside the `send_sig' function instead
>> of usin
Giuseppe Scrivano wrote:
> Hi Pádraig,
>
> I think that the only problem can raise when the sent signal is received
> by the monitor process after the handler is reinstalled. In that case
> the signal will be dispatched again to the process group. This can
> repeat again and again until it is fi
Eric Blake wrote:
> On the other hand, POSIX is explicit that mixing signal and sigaction is
> not portable. For that matter, now that gnulib provides a guaranteed
> sigaction, why don't we just change all of coreutils to use it? Affected
> are: csplit, dd, install, ls, nohup, sort, tee, and time
Giuseppe Scrivano wrote:
> Hello,
>
> do you have suggestions on this patch? It replaces any `signal' with
> `sigaction'.
[snip]
> diff --git a/src/timeout.c b/src/timeout.c
> index 8b506f0..6ef7218 100644
> --- a/src/timeout.c
> +++ b/src/timeout.c
> @@ -278,8 +278,6 @@ main (int argc, char **
Eric Blake wrote:
> According to Pádraig Brady on 10/14/2008 3:47 AM:
>>> With native versions of expr, and expr from GNU coreutils prior to
>>> version 7.0, the expansion of lscmd usually begins "-rw-r--r--", but
>>> the leading hyphen does not cause t
Jim Meyering wrote:
> Ed Avis <[EMAIL PROTECTED]> wrote:
>> Jim Meyering meyering.net> writes:
>>
A few tools are required to build coreutils from a git checkout, but
not checked in a friendly way.
>>> The newer automake-1.10a is actually required.
>> Ah, ok, it could do with a comment b
Nelson H. F. Beebe wrote:
> I've just filed a bug report with The Mathworks, vendor of the
> widely-used Matlab matrix algebra system. Their bin/matlab startup
> script (all versions up to current) contains code like this:
>
> if [ `expr "$lscmd" : '.*->.*'` -ne 0 ]; then
>
> With native v
Nelson H. F. Beebe wrote:
> I agree with a previous poster that the altered behaviour of expr in
> coreutils-7.0 as a result of using getopt() for option parsing is
> acceptable, and consistent with many other utilities, and with GNU and
> POSIX interpretation of a double-hyphen option.
I don't ag
The attached tests pass with both your and Paul's patches.
I didn't add --bignum into the tests as I assumed
those options are being removed imminently.
cheers,
Pádraig.
>From cc29aaeaa6f1d22199abc6eb2e94a62fab46a8f5 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <[EMAIL PROTECTE
Jim Meyering wrote:
> For reference, here's a small patch I just wrote that solves
> at least some of the problems reported here, while retaining
> the ability to use MP at run time.
I'd essentially done the same thing, so I think that will solve
most of the backwards compat issues.
Note if leavi
Excellent stuff. You got a net reduction of 366 lines,
and another 91 lines are not used in the common case
where GMP is available.
I'm a bit worried by signed overflow checking in the following.
I know gcc won't do it's ignore undefined signed overflow
code shenanigans with this, but does this as
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> Thanks for writing that up.
>>> Would you care to ensconce it somewhere more permanent?
>> How about the attached?
>
> Thanks!
> However, since your instructio
Jim Meyering wrote:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
> ...
>>> Are you interested in doing something like that?
>> Well all missing dependencies are currently reported I think,
>> but it can be minutes into the build bef
Version 2 of bootstrap requirements checking patch attached.
Note if one wanted to fully support all (old) version formats
as automake does, one could normalize them before comparison
with something like the following:
normalize_version() {
ver="$1"
echo "$ver" | sed '
s/^\([0-9]\{
Eric Blake wrote:
> According to Pádraig Brady on 10/21/2008 4:04 PM:
>> echo "$ver" | sed '
>> s/^\([0-9]\{,\}\)\.\([0-9]\{,\}\)[.0]*$/\1.\2.0/; #1.10 ->
>> 1.10.0
>> s/^\([0-9]\{,\}\)\.\([0-9]\{,\}\)\([a-z]\)/\1.\2.99\3/
Paul Eggert wrote:
> Here's a patch to remove the --bignum and --no-bignum options from
> 'factor'. The case for removing --bignum isn't as strong as that for
> 'expr', but still, it seems to me that these options are not needed and
> complicate the documentation unnecessarily.
>
>
> Remove --bi
1 - 100 of 3437 matches
Mail list logo