Ferdinand [EMAIL PROTECTED] wrote:
I just wanted to point out that the problem I mentioned in
http://mail.gnu.org/archive/html/bug-coreutils/2003-01/msg8.html
also occurs in the mv test part-symlink, in 4.5.6 too.
I mentioned it in that email, but I guess it wasn't picked up that
time.
on
Steven G. Johnson's ACX_C_RESTRICT macro.
2003-02-12 Jim Meyering [EMAIL PROTECTED]
* regex.m4 (jm_PREREQ_REGEX): Require ACX_C_RESTRICT.
* restrict.m4 (ACX_C_RESTRICT): Minor syntactic changes:
Split long lines, use AC_COMPILE_IFELSE, indent, use `case
...
(http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=131113)
and comment?
Hi Martin!
Thanks for bringing that to my attention!
I've just fixed it like this:
2003-02-19 Jim Meyering [EMAIL PROTECTED]
* src/df.c (print_header): Rather than using a hard-coded literal
Hi Bruno,
Thank you for reporting that!
Although I wouldn't go so far as to say that df is broken in that case :-),
I agree that it is misleading now that it displays the `Mounted on'
directory for such files.
So I've changed it as you suggest, so that now the `Filesystem' part
is always the
Gerard Beekmans [EMAIL PROTECTED] wrote:
I tried out coreutils-4.5.7 and noticed a problem with the C stack
overflow detection check performed by the configure script.
It seems to loop infinitely until it gets killed by the kernel. The test
runs for a few minute in which is consumed 512 MB
:
**
ChangeLog 21 Feb 2003 20:38:16 - 1.246
**
2003-02-21 Jim Meyering [EMAIL PROTECTED]
* Version 4.5.8.
Merge in changes from autoconf's
Jeff Boerio [EMAIL PROTECTED] wrote:
I played around with the source code a bit, and found that for this
particular fstype, it was expecting to see nfs3. So it looks like df
is working as expected. So I'd like to change my bug request to a
feature enhancement.
If I were to say df -x nfs it
Jim Meyering [EMAIL PROTECTED] wrote:
Iida Yosiaki [EMAIL PROTECTED] wrote:
It seems for me that mv in coreutils 4.5.8 failes to move files
in a certain condition.
* How to reproduce the bug.
...
Thank you for the very nice bug report!
To reassure anyone who might be worrying about
Moltonel 3x Combo [EMAIL PROTECTED] wrote:
I'm not sure this is the same bug as the parent subject, but here it is:
Total size is wrong on big directories (small ones seem fine)
If it helps:
* du versions are 4.1.11 (not buggy) and 4.5.8 from gnu ftp
* filesystem is fat32 (mounting as nfs or
Nelson H. F. Beebe [EMAIL PROTECTED] wrote:
I attempted builds of coreutils-4.5.9 on
Intel Itanium 2 (2CPUs, 1GHz, 8GB RAM, 36GB disk)
GNU/Linux 2.4.18-e.12smp [Red Hat Linux Advanced Server release 2.1AS (Derry)]
with gcc (2.96), gcc3 (3.0.4), and Intel ecc (Version 7.0, Build
Thanks.
I've just done this:
* tests/du/basic: Make the test larger than 64 bytes, so that we don't
immediately disqualify file systems (e.g., NetApp) on which smaller
files take up zero disk blocks. Reported by Vin Shelton.
:
**
ChangeLog
**
2003-03-14 Jim Meyering [EMAIL PROTECTED]
* Version 4.5.10.
* tests/du/slink: Relax the test for the `local'ness of a file system
three files. I'll
see about getting access to such a system for pre-release testing. ]
2003-03-14 Jim Meyering [EMAIL PROTECTED]
* automake.in (scan_aclocal_m4): Define ACLOCAL_M4 even in
subdirectories. Makefile.in depends on that variable.
Index: automake.in
Thank you for the report.
Here's some previous discussion on the matter:
http://mail.gnu.org/archive/html/bug-fileutils/2003-01/msg6.html
rm fails to remove a symlink specified with a trailing slash
because the unlink syscall also fails for such an argument.
Making rm detect that
Jeff Bailey [EMAIL PROTECTED] wrote:
I'm also wondering whether su should eventually migrate over.
Hi Jeff!
Migrating su from coreutils to sysutils sounds like
the right thing to do -- and is fine with me.
Jim
___
Bug-coreutils mailing list
[EMAIL
Jerome Zago [EMAIL PROTECTED] wrote:
...
[EMAIL PROTECTED]:~/src/tmp$ cat k.c
#include stddef.h
size_t n;
[EMAIL PROTECTED] cc -c k.c echo OK
OK
[EMAIL PROTECTED] gcc -c k.c echo OK
OK
-
Note that coreutils-4.5.12 does build with cc:
-
[EMAIL
Daniel Yacob [EMAIL PROTECTED] wrote:
I found that the date utility was not displaying the format defined
in locales properly for %r (aka t_fmt_ampm). The 'r' case at line
1173 in coreutils-5.0 seems to be the problem. There is no
goto underlying_strftime; statement as seen for the related
defined.
2003-05-29 Jim Meyering [EMAIL PROTECTED]
* time/strftime.c (my_strftime) [!defined _NL_CURRENT HAVE_STRFTIME]:
Use underlying_strftime for %r.
Suggested by Daniel Yacob [EMAIL PROTECTED].
Index: time/strftime.c
Tim Care [EMAIL PROTECTED] wrote:
Got this error message while running make check for the coreutils-5.0 I
downloaded from the web.
...
FAIL: row-col-1
Thanks for reporting that.
What type of system were you using?
Were you logged on to its console or accessing it remotely?
If remotely, via
Bruno Haible [EMAIL PROTECTED] wrote:
OK, taking these suggestions into account, here is a revised patch.
Thanks Paul.
2003-05-25 Bruno Haible [EMAIL PROTECTED]
* src/touch.c (look_inside): New variable.
(longopts): Add --inside.
(time_from_inside): New function.
John David Anglin [EMAIL PROTECTED] wrote:
Here is an updated patch that allows building 5.0.1 under ultrix 4.3.
Thanks, but wouldn't the new part of your stat.c patch make it fail to
compile on Ultrix 4.4? The code makes me think that ultrix-4.4 lacks
one of sys/mount.h and sys/param.h. As
Bruno Haible [EMAIL PROTECTED] wrote:
This patch removes a useless system call (close(-1)) in some cases.
diff -r -c3 coreutils-5.0/src/touch.c coreutils-5.0-touch/src/touch.c
*** coreutils-5.0/src/touch.c 2002-12-20 21:09:22.0 +0100
--- coreutils-5.0-touch/src/touch.c 2003-05-25
Dan Jacobson [EMAIL PROTECTED] wrote:
The date command documentation doesn't say how to turn
$ date +%s
1055452108
back into something readable.
There is an example showing how to do that:
* If you're sorting or graphing dated data, your raw date values may
be represented as seconds
Alfred M. Szmidt [EMAIL PROTECTED] wrote:
From todays CVS the following test(s) fail (full log, so scroll down a bit):
...
Have you perhaps hacked ls.c so that it always prints the `author' name?
It seems like something like that is causing these differences: e.g.,
- 1 cp loc_reg rem_sl [cp:
Paul Eggert [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
I have found a linux-specific use for this in my boot scripts, and would
like to be able to see other errors from ln without cluttering up the
boot process with this one.
How about if we just remove the warning instead? It
Dan Jacobson [EMAIL PROTECTED] wrote:
I know, on the info page that says
`%s'
seconds since the epoch, i.e., 1 January 1970 00:00:00 UTC (a GNU
please add a Info-follow-reference right there, to your
Jim example showing how to do that:
Jim* If you're sorting or graphing dated
Dan Jacobson [EMAIL PROTECTED] wrote:
I know, on the info page that says
`%s'
seconds since the epoch, i.e., 1 January 1970 00:00:00 UTC (a GNU
please add a Info-follow-reference right there, to your
Jim example showing how to do that:
Jim* If you're sorting or graphing dated
Keith Thompson [EMAIL PROTECTED] wrote:
The --verbose option to the split command doesn't work (where by
doesn't work, I mean that specifying the option has no effect on the
command's output).
The problem seems to have been introduced in coreutils-4.5.10. I see
the problem in releases
MONWHEA JENG [EMAIL PROTECTED] wrote:
I think there is a bug in expr. When I type
expr 2 * 3, I get expr: syntax error. The man page for expr
leads me to think that I should get 6.
Thanks, but that's not a bug.
Your shell is expanding the `*' to a list of all (or most)
of the files in
Paul Eggert [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Paul Jarc) writes:
Paul Eggert [EMAIL PROTECTED] wrote:
POSIX long ago decided that FD is not optional with test -t. GNU
'test' conforms to POSIX in this respect.
bash's does, but coreutils' doesn't.
Good point. I looked at
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
However, if you can find a few other people who say
they'd like that functionality and make a good case
for it, I'll reconsider.
If you go that route, I'd suggest adding an option
--suffix-alphabet=STRING, so
Thank you for the report!
Here's a patch:
Fix the bug that would make `du /' omit the `/' on the last line.
E.g., `du --exclude='[^/]*' -x /' would print only 4\t\n for me.
* ftw.c (ftw_dir): Don't clobber the leading `/'.
Reported by Chris Lesniewski as
Dan Jacobson [EMAIL PROTECTED] wrote:
If it matters to you, who(1) makes wasteful trailing whitespace,
$ who|cat -e
jidanni :0 Jun 28 01:23 $
jidanni pts/0Jun 28 01:23 (:0)$
jidanni pts/1Jun 28 01:23 (:0)$
root pts/6Jun 28 13:36 (:0.0)
Steven Mocking [EMAIL PROTECTED] wrote:
Note the small difference. The ls documentation informs what is done when the
standard output is a terminal *and* what is done when stdout is _not_ a
terminal. The nohup docs, on the other hand, only inform about behaviour _if_
stdout is a terminal, not
2003-07-14 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (uname invocation): Explain the POSIX
terminology behind uname -m and uname -s.
Thanks.
I've applied that.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
:
**
ChangeLog
**
2003-07-15 Jim Meyering [EMAIL PROTECTED]
* Version 5.0.1.
* Makefile.maint (%.asc): Remove target first, so gpg doesn't
prompt us about
Jim Meyering [EMAIL PROTECTED] wrote:
* tests/rm/fail-2eperm: Now that we have setuidgid, use it in
place of the kludge in this test.
Thanks. I think NON_ROOT_USERNAME should be mentioned in README too.
(ATM, README still has a now-out-of-date note that setuidgid ought to
be used
There's a pretty bad bug in kill. Mea culpa.
This means that coreutils-5.0.2 (or maybe coreutils-5.0.90)
will be coming soon.
$ sleep 9 ./kill $!
[2] 27983
./kill: ./kill: invalid process id
[2]+ Terminated sleep 20
[Exit 1]
You'll notice that kill tried to kill the
Paul Eggert [EMAIL PROTECTED] wrote:
It'd be an amusing option to build, albeit not as easy as one might
think at first glance. Here's a proposed addition to the coreutils
TODO list.
This functionality has been requested often enough that I suspect the
alternatives (scripts galore and
Andreas Schwab [EMAIL PROTECTED] wrote:
| Anyway, it's still possible that 'uniq' has a bug, or perhaps
| 'strcoll', depending on your further investigation.
It _is_ a bug in coreutils, not in strcoll:
- AC_CHECK_FUNCS(strcoll) is missing,
- the fallback implementation of memcoll using
Paul Eggert [EMAIL PROTECTED] wrote:
Anyway, I noticed on glitch in the merged version; here's a patch.
2003-07-20 Paul Eggert [EMAIL PROTECTED]
* src/wc.c (get_input_fstatus): Fix typo: `stat' was being
invoked with a null pointer when there were no file arguments.
Glad you
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Instead, I'm adding a configure-time test of utimes, so that
if it works, coreutils will use it.
OK, but a couple of things. First, I would change this:
static struct timeval timeval[2] = {{9, 10}, {11, 12
Paul Eggert [EMAIL PROTECTED] wrote:
Sun patch 109933-02 for Solaris 8 sparc, released August 1, added
support to cp -p to set file timestamps to microsecond resolution,
instead of the old behavior, which set them only to 1-second
resolution. Sun make relies on this new behavior so that make
I wrote:
Why does utimens.c bother with utimes at all?
:-)
Because utimes lets you specify the fractional part of the file times.
Now, I prefer the way you wrote utimens.c, but we'll need a
replacement utimes function for systems where it's broken.
2003-08-08 Paul Eggert [EMAIL PROTECTED]
* tests/du/basic: Ensure that a/b/F has at least 65 bytes too.
Applied. Thanks!
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Nelson H. F. Beebe [EMAIL PROTECTED] wrote:
I applied the patches to tests/shred/remove, src/nice.c, and
lib/stdbool_.h in coreutils-5.0.90 and repackaged it as
coreutils-5.0.90.1, then launched builds on just those platforms where
build failures had previously occurred.
I still get some
Vin Shelton [EMAIL PROTECTED] wrote:
3. 'shred' fails the remove test under both SunOS-5.5.1 and SunOS-5.8:
Thanks for reporting that.
It was fixed like this:
2003-08-01 Jim Meyering [EMAIL PROTECTED]
* tests/shred/remove: Ensure that $? is 0 for the final `exit 0'.
Otherwise
Dan Jacobson [EMAIL PROTECTED] wrote:
$ stat .|sed -n 's/ $/-watseful trailing blanks/p'
Device: 349h/841d Inode: 16321 Links: 32 -watseful trailing blanks
Thanks. I've just fixed that:
* src/stat.c (do_stat): For link count at end of line, use %h format,
instead
Danny Levinson [EMAIL PROTECTED] wrote:
Configure only tests to see if it can create up to 30 temp files using
the system mkstemp. (Ref: in coreutils-5.0, configure, line 27177 or
Thank you for reporting that!
I've fixed it as you suggest: (note that the URL is not yet valid)
*
Tommi Kyntola [EMAIL PROTECTED] wrote:
It appears that stat source function print_it (stat.c:574) can be tricked
into performing a strchr (and after that either an fputs or worse with %
manipulation) beyond the terminator in the string received from
char *format = strdup (masterformat);
This
Dan Jacobson [EMAIL PROTECTED] wrote:
I have discovered paste(1) adds a \377 to files with no final newline.
Try this:
echo -e '1\n2\c' f
echo -e '1\n2' g
paste f g|od -c
Thank you for reporting that bug!
Here's what I've done to fix it:
* src/paste.c (paste_parallel): Don't output
Lawrence Teo [EMAIL PROTECTED] wrote:
Here's a patch against 5.0.1 to allow md5sum.c to support generic BSD
message digest formats. Version 5.0.1 already has support for BSD MD5
format; this patch modifies the code so that `sha1sum --check' will
also work with BSD-style SHA1 checksum files.
Patrick Mauritz [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 5.0.90-3
Severity: normal
seq -w 0 -11 returns
000
-01
...
-11
while
seq -w -4 -11 returns
-4
-5
..
-11
the latter doesn't seem to be correct
Thanks for the report!
I'll look more closely at it later.
In the
:
**
ChangeLog
**
2003-09-08 Jim Meyering [EMAIL PROTECTED]
* Version 5.0.91.
* man/Makefile.am (programs): Use ../src, not $(srcdir)/../src.
(check-programs-vs-x): Fail if $(programs) is empty
Varga Dániel [EMAIL PROTECTED] wrote:
$ factor 3628746859628453216852492
factor: `3628746859628453216852492' is not a valid positive integer
Try `factor --help' for more information.
--
I firmly believe that `3628746859628453216852492' is a valid positive
integer. :)
George [EMAIL PROTECTED] wrote:
First off, I am not sure my first message made it to any where.
It did.
...
I have two suggestions for split:
1) numeric suffix: I noticed that a numeric suffix options was purposed:
http://mail.gnu.org/archive/html/bug-coreutils/2003-08/msg00020.html
Perhaps
Olivier Delhomme [EMAIL PROTECTED] wrote:
Hello,
I added some lines to dd.c in order to have some stats displayed while
copying a file.
As i have read somewhere, some people do not like such a behavior so i added
a command line option : stat=on in order to work.
Let me know if the diff
Alfred M. Szmidt [EMAIL PROTECTED] wrote:
[I'm keeping bug-hurd in the CC since maybe someone on that list has
something to comment.]
Ping.
Thanks for the patch and the prod :-)
Please mention that this option is Hurd-specific
in both --help output and in coreutils.texi.
...
There is two
[EMAIL PROTECTED] (Paul Jarc) wrote:
Jim Meyering [EMAIL PROTECTED] wrote:
And if you build the GNU coreutils on a system that conforms to
POSIX 1003.1-2001, then you'll find that the above all fail, e.g. like this:
$ head -1
head: `-1' option is obsolete; use `-n 1'
Try `head --help
[I removed [EMAIL PROTECTED] from the Cc: list, since
that list bounces mail from non-members]
[EMAIL PROTECTED] (Paul Jarc) wrote:
Jim Meyering [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Paul Jarc) wrote:
Given the significant number of complaints about this behavior, I
think it would make
Thanks again for the report.
I was able to reproduce it consistently with this:
(while :; do echo =; yes jj|head -n1; done) \
| csplit - '/=$/' '{*}'
I got output like this:
0
270002
253910
csplit: memory exhausted
Here's the patch:
Don't
Craig Bourne [EMAIL PROTECTED] wrote:
I am running RedHat Linux 9.0
Linux version 2.4.20-6 ([EMAIL PROTECTED]) (gcc version
3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Feb 27 10:06:59 EST 2003
I find that files which have names starting with the characters hp are
invisible to /bin/ls (
Tobias Burnus [EMAIL PROTECTED] wrote:
chown (coreutils) 5.0.90
chgrp (coreutils) 5.0.90
don't support the -L, -H and -P options which are required by SUSv3.
(By the way, those options _are_ supported by cp.)
Thanks for the suggestion.
They're coming soon, along with rewrites to make chmod,
Simon Josefsson [EMAIL PROTECTED] wrote:
Index: announce-gen
===
RCS file: /cvsroot/coreutils/coreutils/announce-gen,v
retrieving revision 1.17
diff -u -p -u -w -r1.17 announce-gen
--- announce-gen 26 Aug 2003 07:19:57
Paul Eggert [EMAIL PROTECTED] wrote:
JGraham [EMAIL PROTECTED] writes:
tell me you've never run a process that needed to run, then realized
that you had to log off?
I can't tell you that. OK, you're starting to convince me.
http://www.chiark.greenend.org.uk/~peterb/linux/interfereproc/
Steven Augart [EMAIL PROTECTED] wrote:
I could not agree more.I am not terribly pleased that there is now a
`now'? It's been in the sh-utils/coreutils for over 8 years.
I agree in principle that these days coreutils `hostname' program
is often not useful. But bear in mind that the vast
Steven Augart [EMAIL PROTECTED] wrote:
I examined the md5sum documentation, and it is indeed incomplete. For
each file, `md5sum' outputs the MD5 checksum, a flag indicating binary or
text input file, and the filename.
It seems clear that this whole backslashing thing is done in order to
Steven Augart [EMAIL PROTECTED] wrote:
I looked through the Open Group documents that the letters you sent me
pointed to. I'm not clear on whether it's required to reject unknown
arguments starting with a - but not after a --. That would significantly
influence my implementation -- I would
2003-10-12 Paul Eggert [EMAIL PROTECTED]
* tests/du/no-x: Change wording of diagnostic to match latest du.c.
I'd done that but hadn't checked it in :-)
* tests/sort/sort-tests: Remove from CVS; assume that people
brave enough to check coreutils out from CVS can rebuild
Paul Eggert [EMAIL PROTECTED] wrote:
Georgi Guninski [EMAIL PROTECTED] writes:
The heap is quite screwed, but ls is killed by the kernel due to
memory usage.
Thanks for reporting the bug. As it happens, I had already been
preparing a more general patch for address arithmetic overflow bugs
Dan Jacobson [EMAIL PROTECTED] wrote:
I see four sentences written as two:
$ man mv
-f, --force
do not prompt before overwriting equivalent to --reply=yes
-i, --interactive
prompt before overwrite equivalent to --reply=query
Thanks. I've
ari [EMAIL PROTECTED] wrote:
The thread you mention does follow a similar discussion, but i don't
believe it obviates my argument.
I notice that the 'head' and 'tail' commands, in the latest version of
coreutils, were modified to do away with the following options:
-number (head,
Robert Millan [EMAIL PROTECTED] wrote:
Coreutils from CVS has trouble with dynamicaly generated false.c:
[...]
make[3]: Entering directory `/home/rmh/shared/gnu/coreutils/build/po'
make[3]: *** No rule to make target `../../coreutils/src/false.c', needed by
`coreutils.pot-update'. Stop.
Robert Millan [EMAIL PROTECTED] wrote:
Ouch. For some reason I thought builddir != srcdir was the recommended build
method for coreutils.
I don't know about `recommended', but I've always tried to make sure both work.
And from a release tarball, both do work just fine. It's only from CVS that
[EMAIL PROTECTED] (Paul Jarc) wrote:
Jim Meyering [EMAIL PROTECTED] wrote:
After 10 years of being merely `obsolescent', head -N has finally
been officially declared to be `obsolete'.
This doesn't respond to Ari's argument, though: given that GNU
utilities already go beyond the standard's
David Daney [EMAIL PROTECTED] wrote:
$ mipsel-linux-gcc --version
mipsel-linux-gcc (GCC) 3.3.1
...
$ ../coreutils-5.0/configure --build=i686-linux --host=mipsel-linux
--target=mipsel-linux
Results in the following lines in config.h:
...
#define UTILS_OPEN_MAX cross compiling run-test in
Dennis Smit [EMAIL PROTECTED] wrote:
I've been playing with valgrind and the gnu coreutils and found that
some of these utils have small memleaks, i would love to fix them and
send patches. Are you people intrested in such patches ?
Yes.
Please base any changes on the very latest versions in
Good point. The README is a bit obsolete anyway, as it talks about
POSIX.2. Here's a proposed patch.
2003-11-04 Paul Eggert [EMAIL PROTECTED]
* README: Document _POSIX2_VERSION.
--- README.~1.12.~Tue Jul 29 13:55:00 2003
+++ READMETue Nov 4 10:50:42 2003
Thank you,
Paul Eggert [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Paul Jarc) writes:
I think it ought to be possible for the user building coreutils to say
what version of conformance they want - say, with a ./configure
argument - and this should override the unistd.h definition.
That might be
Paul Eggert [EMAIL PROTECTED] wrote:
I noticed this problem while building coreutils from CVS:
test echo 'spy:;@echo $(all_programs)' | MAKEFLAGS= make -s -C ../src -f Makefile
-f - spy | ../src/tr -s ' ' '\n' | LC_ALL=C sort -u | grep -v '\[' : || exit 1
/bin/sh: all_programs: command not
Paul Eggert [EMAIL PROTECTED] wrote:
I went through cut.c and found some problems on hosts where size_t is
wider than int. While I was at it, I fixed the widths of all the
integer types that I could find. Here's a proposed patch.
2003-11-05 Paul Eggert [EMAIL PROTECTED]
Fix 'cut'
Dennis Smit [EMAIL PROTECTED] wrote:
These patches are like that i send for users.c so people won't confuse
the leaks for real serious leaks.
Thank you.
I've applied those patches and added this ChangeLog entry:
2003-11-05 Dennis Smit [EMAIL PROTECTED]
* src/wc.c (main): Free
Edmund [EMAIL PROTECTED] wrote:
I've experienced a very interesting bug with Coreutils.[...]
With the base installation's fileutils 4.1.11 everything is fine,
but after the system updates itself to coreutils, some of the file
operations are broken. [...]
ls returns all files with size
Ed Avis [EMAIL PROTECTED] wrote:
% mkdir -p fred/jim
% chmod a-x fred/jim
% rm -rf fred
rm: cannot chdir from `fred' to `jim': Permission denied
But since I own the directory I could change the permissions and then
remove it. Shouldn't rm do this if I gave the 'force' option? I
thought
Olivier Delhomme [EMAIL PROTECTED] wrote:
I send a patch on november 2 and i was wondering if
it was sent directly to /dev/null ?
You sent it to the right place.
But sometimes it takes a long time for me to handle feature additions.
Please let me know, where i am wrong with this patch
as it
Ed Avis [EMAIL PROTECTED] wrote:
In that case could I make a feature request for a new flag
-F, --really-force
As --force but also change permissions if necessary.
It's feasible.
I'm not enthusiastic about this, but not strongly opposed either.
Let's see if anyone else has
Alexandre Duret-Lutz [EMAIL PROTECTED] wrote:
I can't distcheck coreutils, because it hangs like this:
[using my private, hacked-up version of cvsu]
Hi Alexandre!
Thanks for reporting that.
I knew that particular little sin would come back to haunt me :-)
It's a copy of
Alexandre Duret-Lutz [EMAIL PROTECTED] wrote:
While trying to distcheck CVS Coreutils with CVS Autoconf and
CVS Automake I've seen this:
gcc -g -O2 -o tail tail.o ../lib/libfetish.a ../lib/libfetish.a -lm -lrt none
required
gcc: none: No such file or directory
gcc: required: No such
[EMAIL PROTECTED] (Bob Proulx) wrote:
Jim Meyering wrote:
Ed Avis wrote:
In that case could I make a feature request for a new flag
-F, --really-force
As --force but also change permissions if necessary.
It's feasible.
I'm not enthusiastic about this, but not strongly
Olivier Delhomme [EMAIL PROTECTED] wrote:
[25 lines of unnecessary context removed -- please trim context of
quoted messages]
Thank you for replying so quickly,
sorry for that mistake, i'm so confused. Here is the patch
against today's cvs sources :
Thank you for the patch.
Have you read
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
Maybe `--files-from', since GNU tar uses that, but those names
aren't separated with NUL bytes.
Other ideas?
tar uses --files-from=NAME (-T NAME) to read files from NAME, and a
separate option --null to say
ashes [EMAIL PROTECTED] wrote:
Hello. I should note I built coreutils with full bounds checking. I applied 3
patches first:
coreutils-5.0-hostname-2.patch
coreutils-5.0-uname.patch
coreutils-5.0-90563.patch -- for the du file descriptor bug
Thank you for the report, but since then, I've
Dennis Smit [EMAIL PROTECTED] wrote:
I had a glance at the TODO list and saw that df -mP had an alignment bug
so i fixed that. Also i saw that an --total option was requested so
did that as well.
Thanks for the patches.
Fixing the -mP alignment problem is not so simple.
With your patch, `df
Dennis Smit [EMAIL PROTECTED] wrote:
previous week we were discussing the du, wc --files-from options
which didn't lead to much result. However I've got the FSF
license post on it's way so i would love to put some work
in this.
I'am still in favor for Pauls idea to have a --files-from=NAME
[EMAIL PROTECTED] (Paul Jarc) wrote:
What about --files-from0, or some such, so that the difference between
it and --files-from in other tools is apparent?
I like that.
Thanks.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
[coreutils-5.0 `make check' problems with csplit and dd on HPUX]
Thanks for the reports.
Would you please try the latest test release?
BETA
ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.0.91.tar.gz
ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.0.91.tar.bz2
Oh. I see from your config.log (55k lines!) that you were using
this sort of system:
hostname = w408lynx
uname -m = 9000/778
uname -r = B.10.20
uname -s = HP-UX
uname -v = A
If you send a big attachment like that again, please compress it first.
for `cat' as an example:
$ cat src/vg/cat
#!/bin/sh
export PATH=/work/fetish/cu/src:...
exec /p/bin/valgrind --suppressions=/tmp/cu-vg --gen-suppressions=yes --quiet
--num-callers=9 cat $@
=
2003-11-17 Jim Meyering [EMAIL PROTECTED
The ptx man page lacks the address for mailing bugs.
Thanks!
I've just fixed that.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
dear maintainers, i have coreutils-4.5.8-13 from my distro suse 8.2 and a dvd
burner which i use as a backup device. some of my backup files exceed the 4G
limit so i have to split before i burn. in doing so i noticed that split seems
to have a size limitation somewhere around the 2000m mark.
1 - 100 of 4474 matches
Mail list logo
