Guido Flohr wrote:
Hi Pádraig,
Pádraig Brady wrote:
Uninstalling with clean up in such cases is a frequent task, and could be
greatly simplified by:
$ rm --parents /usr/share/myapp/pixmaps/8x16/icon.png
rm: failed to remove `/usr/share': Directory not empty
$ ls
Jim Meyering wrote:
Guido Flohr wrote:
Sure. But compare that to:
rm -p $file
Clearer and more efficient to boot.
It is hard to justify adding an option to GNU rm when you can get
the desired functionality via a tiny shell script:
#!/bin/bash
fail=0
for f in $@; do
unlink $f || {
Guido Flohr wrote:
The case where the directory part is not known is quite frequent imho. I
configured a random GNU package (in this case gettext from the current
git sources), configured it with --prefix=/tmp/my_gettext, then
make, make install, and make uninstall, and finally ran find over
I was surprised to notice sort was accessing the disk on multiple runs on
a 500MB file on my 2GB RAM laptop. Here was my memory situation:
$ free -m | head -n2
total used free sharedbuffers cached
Mem: 2006603 1403 0 67
Giuseppe Scrivano wrote:
Jim Meyering j...@meyering.net writes:
I'm not convinced that adding a lot of new code just to make tail -f
handle a far-fetched case like that is worthwhile. But that's just
my opinion, and if someone can present a use-case that makes it seem
the additional code
Pádraig Brady wrote:
But I'd be worried about using rm -p generally, as I might delete an
empty dir that didn't belong to me. Though if passed relative
paths that would be alleviated I suppose.
It's trivial to protect a precious directory, by dropping a file in that
directory. Besides, not
Dear coreutils,
Actually, I'm not sure if ls is the perpetrator, but maybe you guys can find
out where things go wrong. I do not think that the filename canttouchthis
should be listed when I am not root in the following situation:
r...@system76-pc:/home/xinwei/bugreport# ls -l
total 4
d---r--r--
Guido Flohr wrote:
Pádraig Brady wrote:
But I'd be worried about using rm -p generally, as I might delete an
empty dir that didn't belong to me. Though if passed relative
paths that would be alleviated I suppose.
It's trivial to protect a precious directory, by dropping a file in
that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to PG on 7/6/2009 11:21 PM:
Dear coreutils,
Actually, I'm not sure if ls is the perpetrator, but maybe you guys can find
out where things go wrong. I do not think that the filename canttouchthis
should be listed when I am not root in
On Mon, 6 Jul 2009, PG wrote:
r...@system76-pc:/home/xinwei/bugreport# ls -l
total 4
d---r--r-- 2 root root 4096 2009-07-05 13:27 protected
xin...@system76-pc:~/bugreport$ ls -l protected/
ls: cannot access protected/canttouchthis: Permission denied
total 0
-? ? ? ? ?
Eric Blake e...@byu.net writes:
After recent Ubuntu releases there have been several people who have
been asking about Ubuntu questions on this GNU Coreutils mailing
list. If you would be so kind could you tell us what has directed you
to ask your question on this mailing list?
Perhaps
Guido Flohr gu...@imperia.bg writes:
Or even simpler because rmdir -p never has a zero exit-status.
That's not true. rmdir -p only traverses as far as the argument allows,
thus if it is a relative filename it won't try to traverse further up
than the current directory (in absense of ..). In
Hello,
Guido Flohr writes:
The case where the directory part is not known is quite frequent imho.
I configured a random GNU package (in this case gettext from the current
git sources), configured it with --prefix=/tmp/my_gettext, then
make, make install, and make uninstall, and finally
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
ah, great!
thank you for the info. That helps me understand a lot. Now I see why find
fails. And perhaps it's not worth the extra computation time required to,
upon failure of cd'ing into the directory, trying to list it.
I still think there should be an option for find that one could turn on
Bob Proulx wrote:
Matthew Woehlke wrote:
Bob Proulx wrote:
Yes. And cursed they are but so it is. :-)
Oh, come on. I know all about the inherent danger, and I still use
spaces in my file names, and probably always will. It's simply easier
for us humans to think that way.
If you couldn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Matthew Woehlke on 7/7/2009 5:38 PM:
Hmm, is xargs a GNU extension? Otherwise I'd say non-GNU xargs.
No. POSIX requires it:
http://www.opengroup.org/onlinepubs/9699919799/utilities/xargs.html
However, xargs -d is a GNU extension.
-
17 matches
Mail list logo
