Hello,
as requested in rhbz #449985 by sectools team it will be good to have
capability displaying support in ls. This patch has no effect on systems
without function cap_get_file supported since libcap 2.x. You have to run
configure with parameter --enable-libcap.
Greetings
Kamil Dudka
From
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.
Greetings
Kamil Dudka
From
=fill -- new patch in attachment.
Kamil
From 150811acaac2ff4e9ae55f045ecc0e2c03bdc651 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Thu, 17 Jul 2008 15:31:54 +0200
Subject: [PATCH] Added support for reading of full blocks to dd.
NEWS: mentioned new parameter conv=fill of dd
doc
0cf35cbb3747502bd961bdb8cb6135034d757e74 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 11:51:46 +0200
Subject: [PATCH] Added support for reading of full blocks to dd.
NEWS: mentioned new parameter iflag=fullblock of dd
doc/coretuils.texi: mentioned new parameter iflag
, fixed.
Remove these in-function #ifdefs.
Instead, define has_capability to return false when the library
is not available.
Ok, no problem.
Kamil
From a0a2366af69016adeecb3db86ebfa5bba7c93952 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 15:43:30 +0200
On Monday 21 July 2008 17:43:52 you wrote:
Kamil Dudka [EMAIL PROTECTED] wrote:
Don't pessimize your code because doing it cleanly might not work.
Have no fear ;-), and do it cleanly.
The documentation (man cap_to_text) appears to guarantee
the required semantics, so it ought to work
Changed tests/ls/capability file mode to 0755 in patch - sorry for that
mistake, I am new to git...
Kamil
From 4f14f5e39d7687ddb252f5a7560724179635c944 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Tue, 22 Jul 2008 12:53:00 +0200
Subject: [PATCH] --color now highlights files
I hope I didn't forget anything this time. New version of patch is
in attachment.
Kamil
On Tuesday 22 July 2008 15:25:07 you wrote:
Kamil Dudka [EMAIL PROTECTED] wrote:
From 4f14f5e39d7687ddb252f5a7560724179635c944 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Tue
:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Wed, 23 Jul 2008 11:29:21 +0200
Subject: [PATCH] dd: iflag=fullblock now read full blocks if possible
* src/dd.c (iread_fullblock): New function for reading full blocks.
* (scanargs): Check for new parameter iflag=fullblock.
* (skip): Use
On Friday 25 July 2008 12:40:25 you wrote:
On what type of system did the new test succeed for you?
On rawhide, capget appears to malfunction:
# rm t;t;strace -e capget setcap cap_net_bind_service=ep t 21|cut
-c-78 capget(0x20071026, 0, NULL) = -1 EFAULT (Bad address)
On Friday 25 July 2008 12:40:25 you wrote:
On what type of system did the new test succeed for you?
On rawhide, capget appears to malfunction:
# rm t;t;strace -e capget setcap cap_net_bind_service=ep t 21|cut
-c-78 capget(0x20071026, 0, NULL) = -1 EFAULT (Bad address)
version:
$ ulimit -v 102400
$ ls -U1 | wc -l
ls: memory exhausted
0
Patched version:
$ ulimit -v 102400
$ ls -U1 | wc -l
102402
Greetings
Kamil Dudka
From 92a29217298044c1b9298d557ac6fd683effbd41 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Wed, 30 Jul 2008 12:40:49 +0200
Hello,
as requested in TODO, new option --total (-c) was added to df to produce grand
total (in the same way as du). Proposed patch in attachment.
Kamil
From 6a688c574a03ccd7499fb9864ad9c568d29b6c5b Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Tue, 2 Sep 2008 10:13:33
in main() as well.
Thank you for review. New patch in attachment.
Kamil
From 126c3f1246bc7e8eb44885b187fbcbe8b33dbbb2 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Tue, 2 Sep 2008 11:20:51 +0200
Subject: [PATCH] [PATCH] df: new option: --total (-c) to produce grand total
as !((a) ^ (b))
Replaced with (!(a) == !(b)), thanks James!
Please split long lines so as not to exceed max length of 80.
Ok, fixed, new patch in attachment...
Kamil
From dcd79cfceeb8442af4403ddb82df3bcb322cde10 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Tue, 2 Sep 2008 14
, it
was helpful for the AWK based test as well.
Kamil
From d402ecc9c1c1657cd5b213758968efd880364831 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Wed, 3 Sep 2008 10:33:06 +0200
Subject: [PATCH] df: new option: --total to produce grand total
* src/df.c (add_uint_with_neg_flag
On Wednesday 03 September 2008 11:03:22 you wrote:
Kamil Dudka [EMAIL PROTECTED] writes:
Since both arguments are already bool I see no need for LOG_EQ (it's the
only use anyway).
If you are using type bool, there is no guarantee there will be bool (0/1)
value inside. It ca be (and mostly
On Wednesday 03 September 2008 11:18:37 you wrote:
Kamil Dudka [EMAIL PROTECTED] writes:
On Wednesday 03 September 2008 11:03:22 you wrote:
Kamil Dudka [EMAIL PROTECTED] writes:
Since both arguments are already bool I see no need for LOG_EQ (it's the
only use anyway).
If you are using
recommended in glibc strverscmp() bugzilla)
Which way do you like? Or do you have different ideas?
Greetings,
Ondrej Vasik
From 321dede6df5a2df1a5a54b65ba5755e7767832a1 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Wed, 3 Sep 2008 15:29:12 +0200
Subject: [PATCH] more
On Thursday 04 September 2008 02:13:03 Yochai Meir wrote:
Hey,
I think I found a bug in the df command.
I was searching for information to manage my data and then I saw this
FilesystemSize Used Avail Use% Mounted on
/dev/sda5 23G 23G 71M 100% /media/DOWNLOADS
On Thursday 04 September 2008 00:52:08 you wrote:
We cannot take this patch, as the gnulib strverscmp function is meant to be
a substitute for the glibc function of the same name. (Sorry, the doc was
not clear about it until today.) This means, gnulib's strverscmp needs to
behave the same as
Hello,
as requested in TODO, new option --strip-program was added to install to
specify the program used to strip binaries. Proposed patch in attachment.
Kamil
From abf2ded806353d83594683af45838661e5f817d2 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Fri, 5 Sep 2008 13:12
On Sunday 07 September 2008 08:28:11 Jim Meyering wrote:
IMHO, changing sort -V to produce more intuitively-correct results
is the way to go.
With ls -v, I'm willing to make the change as well, *assuming*
no one produces a counterargument.
The question is what ordering function to use.
The
Hello Bruno,
thanks for excellent review. When the function's behavior is definitely
accepted by people here, I will improve its implementation.
On Wednesday 17 September 2008 13:13:03 you wrote:
There are still a few things to do before we can add it to gnulib:
- Do you have a copyright
:
http://lists.gnu.org/archive/html/bug-gnulib/2008-09/msg00365.html
Kamil
From 6464e9931bf7d9b480ef2dda15831a0c81530b6e Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Mon, 29 Sep 2008 15:41:43 +0200
Subject: [PATCH] ls and sort: use filevercmp instead of strverscmp
* src/ls.c
On Monday 29 September 2008 16:12:18 Ian Jackson wrote:
And which files are we talking about ?
lib/vercmp.c
NB that the dpkg comparison algorithm was recently extended to support
a new character ~ which sorts before the empty string. This work
wasn't done by me - but I approve of it and it
On Tuesday 30 September 2008 12:13:08 Ian Jackson wrote:
Sorry, I overlooked this message before. Now I'm really confused.
You seem to have already rewritten it. So why are people asking for
permission and/or copyright assignment ?
The core of filevercmp module is the verrevcmp function taken
New version of patch: removed one conflicting string from test
misc/sort-version and added test strings from gnulib test-filevercmp.
Kamil
From f9bda7974f25afd920bf95d24fb680ea57adb2f0 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Fri, 3 Oct 2008 11:03:40 +0200
Subject
On Tuesday 14 October 2008 15:27:54 Eric Blake wrote:
On the other hand, autoconf's m4_version_compare (which is what automake
uses to determine if you are using a new enough version, when you request
1.10a), treats 1.10a 1.10.1. In other words, 1.10a is the alpha in
preparation for 1.11,
Hello,
at https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/123423 is proposed
ls enhancement highlighting regular files with hardlinks (1 nlink). I tried
to implement this enhancement, but I have some questions:
1. Do you think, it would be useful? I think it would.
2. In the report
Hello,
at https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/229182 is proposed
cp/mv enhancement: -n option to not overwrite target files. This option is
available on FreeBSD cp/mv as complement to options -i, -f:
http://www.ipnom.com/FreeBSD-Man-Pages/cp.1.html
, #454072.
Kamil
From 18a8185efddb9135eea1b8d698fd913450ea98d3 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Mon, 20 Oct 2008 14:18:18 +0200
Subject: [PATCH] cp/mv: xattr support
---
configure.ac |3 +
doc/coreutils.texi | 12 ++
m4/xattr.m4| 44
$ eval `dircolors -b | sed s/ca=[^:]*:/ca=:/` # disable checking for file caps
$ strace ls --color 2 tmp grep -i cap tmp --color
Kamil
From 98db8935f54a930cb75c998e1a7f160b4e9b5cf2 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Mon, 20 Oct 2008 15:39:07 +0200
Subject: [PATCH] ls
9ee96c46bc930d8343de03be6ed65313a96c5ad1 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Mon, 20 Oct 2008 18:45:52 +0200
Subject: [PATCH] ls: --color now highlights hard linked files, too
* src/ls.c (print_color_indicator): Colorize hard linked files.
* src/dircolors.c: Add color for hard link.
* src
Hello,
proposed patch is attached.
Kamil
On Wednesday 15 October 2008 15:10:58 Jim Meyering wrote:
Eric Blake [EMAIL PROTECTED] wrote:
According to Kamil Dudka on 10/15/2008 3:50 AM:
Hello,
at https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/229182 is
proposed cp/mv
the number of hard links is
highlighted in long-style output.
Proposed patch is attached.
From e804b4ca6c9e89b668547797adbe1ea7b74e5dbf Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Mon, 27 Oct 2008 15:38:23 +0100
Subject: [PATCH] ls: --color now highlights hard linked files, too
Hello Jim,
after your agreement last week I am sending the patch for cp/mv xattr support.
Any feedback is wellcome...
Kamil
From 5c392c91880f78859189e45125ec1ff3e9992585 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Mon, 10 Nov 2008 19:07:44 +0100
Subject: [PATCH] cp/mv
Andreas.
Also, give a URL for his unmodified patch, if you can.
From ed226bca8d32b49e09a9479158e2401f667a6de0 Mon Sep 17 00:00:00 2001
From: Kamil Dudka [EMAIL PROTECTED]
Date: Fri, 14 Nov 2008 14:01:02 +0100
Subject: [PATCH] cp/mv: add xattr support
MIME-Version: 1.0
Content-Type: text/plain; charset
On Saturday 27 of December 2008 07:06:48 Eric Blake wrote:
According to Joshua Hudson on 12/26/2008 10:01 PM:
I would suggest an option kind of like -xdev to not cross mount points
and therefore prevent a lot of stupid disasters.
Kind of like rm -rf / is always a bad idea, rm -rf /tmp/*
On Thursday 25 of December 2008 01:16:56 Kent Vander Velden wrote:
When a large block size is specified with dd (coreutils 6.12), the read is
truncated at 2GiB (on a x64 Linux 2.6.25 system.) The following examples
show attempts to write 6GiB. The first example attempts to write three 2
GiB
: Kamil Dudka kdu...@redhat.com
Date: Tue, 6 Jan 2009 12:14:43 +0100
Subject: [PATCH] cp/mv: add -n option to not overwrite target
* src/cp.c (usage): Show new option -n in --help.
(main): Handle new option -n.
* src/mv.c (usage): Show new option -n in --help.
(main): Handle new option -n.
* doc
LC_ALL=C explicitly.
I don't think this is necessary as the locale
is set to C by default (using the tests/lang-default script).
Ok, thanks. Attaching new version of patch.
Kamil
From 490465e697378d38bfad41c9ada3a0a1f80923df Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Tue, 6
On Tuesday 06 January 2009 17:32:59 Kamil Dudka wrote:
On Tuesday 06 January 2009 16:50:19 you wrote:
A couple of tweaks needed I think:
a
The @option{-i} option overrides previous @option{-n} option
^
Same tweak
Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Wed, 7 Jan 2009 16:32:47 +0100
Subject: [PATCH] cp/mv: add --no-overwrite (-n) option to not overwrite target
* src/cp.c (usage): Show new option -n in --help.
(main): Handle new option -n.
* src/mv.c (usage): Show new option -n
patch attached.
Kamil
From 7e3be3500d0a7c27331131115158d608bca53ed7 Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Wed, 7 Jan 2009 19:52:28 +0100
Subject: [PATCH] cp/mv: add --no-clobber (-n) option to not overwrite target
* src/cp.c (usage): Show new option -n in --help.
(main
Maybe it's nightmare for beginners, but it is a common use case. Certain Linux
distributions define alias cp='cp -i' by default in the user's profile. So if
you type 'cp -n' it is translated to 'cp -i -n' and it should not cause an
error.
Kamil
On Sunday 11 January 2009 07:47:51 Aaron
:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Tue, 13 Jan 2009 18:35:00 +0100
Subject: [PATCH] cp/mv: add --no-clobber (-n) option to not overwrite target
* src/cp.c (usage): Show new option -n in --help.
(main): Handle new option -n.
* src/mv.c (usage): Show new option -n in --help.
(main
. There were some issues which should be solved by this patch.
Kamil
From 9d4ae524b93e3bb2f8cb2c99e22f3f192e8dfae8 Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Fri, 16 Jan 2009 11:58:26 +0100
Subject: [PATCH] install: add -C option to install file only when necessary
* src/install.c
On Sunday 18 of January 2009 09:19:01 Aaron Peterson wrote:
I'm wondering if our extended attributes and permissions can be
saved in a special file to give low feature file systems preservation
of our good stuff. Probably a project on sourceforge that addresses
this
Define our extended
if
coreutils is compiled without xattr support. Do you it should be treated as
error?
Kamil
From be354c0cb291f91849e3af4d12737349ecc430d0 Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Tue, 20 Jan 2009 17:00:26 +0100
Subject: [PATCH] cp/mv: add xattr support
MIME-Version: 1.0
/dev/null 21 ||
skip_test_ coreutils built without xattr support
Slightly changed to use cp -n instead of cp --help as --help always returns
EXIT_SUCCESS.
Kamil
From 996a5ec719df76235a30b2ca1394158ea913391d Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Fri, 23 Jan 2009 12
On Tuesday 03 February 2009 17:01:02 Jeromy Keloway wrote:
Good afternoon
What I have to say is a little bit... hard to believe.
But I think I found a bug in the Shell-Command cp. The command goes
into a endless loop when I do the following:
Endless loop? Does the cp process consume CPU or it
On Tuesday 03 February 2009 19:03:33 Elmar Stellnberger wrote:
cp -a refuses to devolve the file mode when I copy a certain file
between two ext3 volumes
whereas it does not report any error:
cat syncit
cp -a /home/./downloads/system/freebsd/bootstrap/etch/debootstrap
if there is a good reason to do so.
Kamil
From d0231bfea44b0b170139a165d98b30df55e8be17 Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Thu, 12 Feb 2009 11:44:32 +0100
Subject: [PATCH] install: add --compare (-C) option to install file only when necessary
* src/install.c
, S_ISGID, S_ISVTX) should be set, we simply short-circuit
the optimization and always unlink and then copy.
Also fixed and added new test case.
Kamil
From db84fbacbe43fcb9144f523e4a965150ed7dcc3a Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Mon, 16 Feb 2009 10:13:45 +0100
On Monday 16 February 2009 11:07:56 you wrote:
Kamil Dudka wrote:
On Thursday 12 February 2009 14:27:09 Jim Meyering wrote:
While rewriting that,
install accepts a new option, --compare (-C): compare each pair of
source and destination files, and if the destination has identical
00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Tue, 17 Feb 2009 13:16:54 +0100
Subject: [PATCH] install: add --compare (-C) option to install file only when necessary
* src/install.c (have_same_content): New function to compare files
content.
(extra_mode): New function checking for non
On Monday 23 February 2009 22:12:48 Sven Joachim wrote:
I just upgraded coreutils from 6.12 to 7.1, and the new sorting behavior
of `ls -v' really irritates me. Backup files are listed before the real
files, parent directory (..) at the very end... At first I thought that
ls -v means sort by
Hello,
proposed patch which updates info documentation about version sort (to reflect
filevercmp behavior) is attached.
Kamil
From 6ae36e04df4db674ab2022c12df0319b768260dd Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Wed, 25 Feb 2009 10:10:36 +0100
Subject: [PATCH] update
On Wednesday 25 February 2009 10:41:32 Sven Joachim wrote:
Good point, okay. But for hidden files this gets completely messed up,
because .foo is listed _before_ all non-hidden files and .foo~ _after_
them. This is really annoying.
That's unfortunate. It seems like subject for another patch.
Hello Mike,
there is an alternative: 'mv -n'. Which version of coreutils are you using?
What does 'mv --version' say?
Kamil
On Tuesday 03 March 2009 16:06:44 Mike McWilliam wrote:
Hello All
I have read many explainations why '--reply=no' does not
work as expected. I am
On Monday 09 March 2009 15:18:25 hggdh wrote:
Every so often I run a make check, and (more eventually) a root make
check. After a git pull remake this morning, I ran a root check, and
got a failure on install-C-root.
Thank you for the report. Unfortunately I am not able to reproduce it. Can
Thanks!
Now just tested on the Gentoo Linux with similar configuration, running the
test install/install-C-root in the loop, still not able to reproduce. Can I
download a snapshot of Debian with your configuration somewhere? Or is it
reproducible on the released one?
On Thursday 12 March 2009
From: Kamil Dudka kdu...@redhat.com
Date: Fri, 13 Mar 2009 11:44:52 +0100
Subject: [PATCH] update info documentation about version sort
* doc/coreutils.texi: Reflect current filevercmp behavior.
---
doc/coreutils.texi | 24 +++-
1 files changed, 15 insertions(+), 9 deletions
On Wednesday 18 March 2009 18:31:29 Kamil Dudka wrote:
Any idea how to reproduce the test failure?
Note I've tested it with the fresh Ubuntu installation and the updated one.
Kamil
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http
~]*)*$/
Now it works correctly with simple and numbered backups. Simple patch
including clarifying test cases is attached.
Kamil
From d889021cebb7bf798d1b7bf24149c354627e9553 Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Fri, 20 Mar 2009 11:20:12 +0100
Subject: [PATCH
On Friday 20 of March 2009 12:36:38 Bruno Haible wrote:
Jim Meyering wrote:
Perhaps ~ isn't the only character we should treat that way.
I'd say that '~' is pretty special here because it's used as backup file
suffix by many text editors. Which is not the case for '_', '-', and
others.
On Friday 20 of March 2009 22:25:30 Bob Proulx wrote:
Kamil Dudka wrote:
On Friday 20 of March 2009 12:36:38 Bruno Haible wrote:
Jim Meyering wrote:
Perhaps ~ isn't the only character we should treat that way.
I'd say that '~' is pretty special here because it's used as backup
Hello,
promissed patch for ls to disable hard links highlighting is attached.
A simple test case is included.
Kamil
On Friday 20 March 2009 13:43:03 Kamil Dudka wrote:
On Friday 20 of March 2009 12:15:34 Pádraig Brady wrote:
Wes Morgan wrote:
The new hard link highlighting would be nicer
On Saturday 21 March 2009 00:03:30 Kamil Dudka wrote:
On Friday 20 of March 2009 22:25:30 Bob Proulx wrote:
The '~' is often used in package version numbers. It sorts before the
version without it. For example the rule[1] for generating a stable
backport from the latest unstable version
Hi Pádraig,
thank you for review!
On Tuesday 24 March 2009 02:05:33 Pádraig Brady wrote:
Kamil Dudka wrote:
Hello,
promissed patch for ls to disable hard links highlighting is attached.
A simple test case is included.
This is better, but dircolors still outputs the hl=44;37 code
On Tuesday 24 March 2009 12:05:21 Pádraig Brady wrote:
Kamil Dudka wrote:
p.s. you forgot the '* ' on front of the filenames in the changelog
Good catch. Thanks!
Could you resubmit a patch with an addition to NEWS \** Changes in
behavior that mentions one can disable coloring
On Thursday 26 of March 2009 16:20:15 Sven Joachim wrote:
A test in make check-root fails for me. Since I usually don't make
check-root, it might have been around for a while. Full log follows:
The failure has been already reported:
On Thursday 26 of March 2009 17:17:26 hggdh wrote:
hg...@xango2:/usr/src/buildd/coreutils/coreutils-git $ ls a echo 1
sudo src/ginstall -Cv a b echo 2 sudo src/ginstall -Cv -g2 a b
echo 3 sudo src/ginstall -Cv a b echo 4 sudo src/ginstall -Cv a b
1
[sudo] password for hggdh:
`a' -
On Thursday 26 of March 2009 17:44:05 hggdh wrote:
On Thu, 26 Mar 2009 17:32:44 +0100
Kamil Dudka xdudk...@gmail.com wrote:
Could you please run stat(1) on the target between install -C
invocation to ensure owner/group are set properly?
Kamil
Yes, no problem. Here you go:
hg
Hello Dennis,
On Monday 30 March 2009 19:10:11 Dennis Heuer wrote:
i just read the message as in the subject as i tried to archive some
web-pages. the problem with dropping this option is that there is no
alternative for --reply=no, if you think twice. this option is quite
helpful to not
On Tuesday 31 of March 2009 16:58:19 Pádraig Brady wrote:
Pádraig Brady wrote:
Adam Gordon wrote:
This seems like it would be a simple feature and while it may overlap
with (or be slightly redundant to) the sort command, sorting
lexicographically, i.e., foo1, foo2, foo10, foo20 instead of
6b607c92e19430eda5ebf8d64bca94722a4f0d39 Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Tue, 7 Apr 2009 13:17:22 +0200
Subject: [PATCH] df: new option --direct to not resolve a mount point
* src/df.c (print_header): Print `File' instead of `Mounted on'.
(show_entry): Handle global variable
On Tuesday 07 of April 2009 14:22:38 Pádraig Brady wrote:
Kamil Dudka wrote:
Hello,
I am attaching a single patch for df adding a new option --direct to not
resolve mount point and show statistics directly for a file. It can be
especially useful for NFS mount points
On Tuesday 07 of April 2009 19:51:02 Pádraig Brady wrote:
Well why I asked was I did essentially that test and was confused by:
$ strace -e statfs64 ./df /home/padraig/ttt /home/padraig/
statfs64(/home/padraig/ttt, ...) = 0
statfs64(/home/padraig/, ...) = 0
I.E. it seems each param is
On Thursday 09 April 2009 09:23:37 Sven Joachim wrote:
Note that the #.b# file is listed at the top in (1) and at the bottom in
(2), despite all filenames in the directory being the same!
Thanks for discovering this! The transitive axiom of the predicate is broken.
I am working on a fix. It
the tests, the second patch does it.
Kamil
From 079b6a1e5997fd0f42fe824b0e02861b78c6e9c6 Mon Sep 17 00:00:00 2001
From: Kamil Dudka kdu...@redhat.com
Date: Thu, 9 Apr 2009 18:07:15 +0200
Subject: [PATCH] filevercmp: fix regression
---
lib/filevercmp.c | 11 +++
1 files changed, 11
On Friday 10 of April 2009 09:18:51 qiwensheng wrote:
Dear Sir or Madam:
I made a file named words.txt. And it's content as follow:
But I use the sort -r command line (sort -r words.txt ) for this file,
and it displays as follow:
So, the result of it does not all reverse the
On Thursday 14 of May 2009 03:33:35 Dave Jones wrote:
Aloha,
An undocumented -and very useful- feature of GNU's 'cp'
--reply=yes (no? query?)
Does cp --force do the job for you? If not, you can still use the following:
$ yes | cp ...
In case of --reply=no and --reply=query there are already
On Monday 25 of May 2009 15:43:50 Reuben Thomas wrote:
Hi,
If I do ls -l |head on a directory with many files in it, it takes a long
time to complete, suggesting that it has read the entire directory. Since
no sorting is involved, why has it done this?
If you want to turn off sorting, try
On Tuesday 26 of May 2009 22:55:37 Poor Yorick wrote:
Building coreutils to install in an alternate location which has its own
libcap and glibc (self-compiled):
CC ls.o
In file included from ls.c:43:
/path/to/include/sys/capability.h:34: error: redefinition of typedef
On Monday 01 of June 2009 23:14:17 Marc Perkel wrote:
I'd like to be able to run chmod on a symlink so that users can't delete
the symlink. Can it be done?
No. It's even not possible with a regular file. You can remove ordinary file
which you have no rwx access to. You rather want to adjust
On Saturday 06 of June 2009 06:13:04 Joshua Rodman wrote:
Buh buh buh -- the recommended sed does not work.
Thanks for pointing this out. Which recommendation did you follow? The one
in the NEWS file? Did you try exactly this?
$ 'eval `dircolors | sed s/hl=[^:]*:/hl=:/`
Which shell are you
On Saturday 06 of June 2009 11:07:03 Joshua Rodman wrote:
I put that line, minus the initial tick (') in my bashrc, but I thought
the demo would be clear that the hl sed cannot work since there is no hl
for it to match.
Sorry for the typo.
I am using bash, as I meant the working directory to
On Saturday 06 of June 2009 16:30:05 Pádraig Brady wrote:
Kamil Dudka wrote:
I think we should improve documentation a bit. It is not only about hard
links. Some people may also want to disable file capabilities
highlighting, etc. Pádraig, what do you think?
Well as discussed previously
On Sunday 07 of June 2009 17:30:28 Jim Meyering wrote:
Pádraig Brady wrote:
Kamil Dudka wrote:
On Saturday 06 of June 2009 16:30:05 Pádraig Brady wrote:
Kamil Dudka wrote:
I think we should improve documentation a bit. It is not only about
hard links. Some people may also want
From: Kamil Dudka kdu...@redhat.com
Date: Wed, 10 Jun 2009 16:47:53 +0200
Subject: [PATCH] ls --color: hard link highlighting is now disabled by default
* src/ls.c: Rename hl-mh, disable hard link highlighting by default.
* src/dircolors.c: Rename HARDLINK - MULTIHARDLINK, hl - mh.
* src
On Wednesday 10 of June 2009 19:12:18 Pádraig Brady wrote:
Kamil Dudka wrote:
Hi Pádraig,
On Sunday 07 June 2009 16:35:23 Pádraig Brady wrote:
Turn off completely is my vote, as hardlinks have their own column.
I polled my local LUG with a non leading question and
nobody came up
On Thursday 11 of June 2009 09:54:29 Jim Meyering wrote:
I've shortened log message lines to fit within 72-col
limit (remember: they get TAB prepended in the generated
ChangeLog file).
Then we should split the short log message into two parts to fit within
the 72-col limit as well.
Also
On Thursday 11 of June 2009 10:28:01 Jim Meyering wrote:
Kamil Dudka wrote:
On Thursday 11 of June 2009 09:54:29 Jim Meyering wrote:
I've shortened log message lines to fit within 72-col
limit (remember: they get TAB prepended in the generated
ChangeLog file).
Then we should split
On Tuesday 07 of July 2009 19:31:06 Ralf Wildenhues wrote:
There is a reason it is not done: make uninstall cannot know, from
looking at the installed tree alone, which set of directories existed
before make install and which were created as part of it. Of those
that existed before, the user
Hello Tak,
On Friday 24 of July 2009 00:17:07 Tak Ota wrote:
As a part of file name manipulation commands, in addition to the
current three commands (basename, dirname, pathchk) could you consider
introduction of a generic path name manipulation command? See
attached example.
did you
On Friday 24 of July 2009 09:15:56 Jim Meyering wrote:
Actually I don't know if we have some utility equivalent to
canonicalize_file_name() function in coreutils now.
We do. It's called readlink:
Usage: readlink [OPTION]... FILE
Display value of a symbolic link on standard output.
* src/readlink.c (usage): Adjust one-line summary.
* man/readlink.x: Likewise.
Suggested by Kamil Dudka.
---
man/readlink.x |2 +-
src/readlink.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/man/readlink.x b/man/readlink.x
index c1d6c5c..79ba758 100644
On Friday 24 of July 2009 10:37:39 Jim Meyering wrote:
Kamil Dudka wrote:
Looks good. What about updating info documentation, too? Incremental
patch attached.
Thanks!
How about this?
[added log and a cindex entry]
Yes, it looks better. I thought it's trivial enough change to not send
1 - 100 of 232 matches
Mail list logo