|
|
Subject: Bug: Symlink removal. - msg#00077
List: gnu.core-utils.bugs
Hi,
Currently in gentoo, we offer fileutils-4.1.11 and coreutils-4.5.10 (which is
currently masked for testing, and we are ready to replace the 3 utils with
coreutils, as soon as it goes stable according to GNU).
The problem is a slight modification of one reported here:
http://mail.gnu.org/archive/html/bug-fileutils/2003-01/msg00002.html
Now, the results are as follows:
trinity@sephora temp $ mkdir test
trinity@sephora temp $ touch test/testfile
trinity@sephora temp $ ln -s test test2
trinity@sephora temp $ rm test2/
rm: remove directory `test2/'? y
rm: cannot remove directory `test2/': Is a directory
trinity@sephora temp $ rmdir test2/
rmdir: `test2/': Not a directory
trinity@sephora temp $ rm test2/
rm: remove directory `test2/'? y
rm: cannot remove directory `test2/': Is a directory
trinity@sephora temp $ rm test2
rm: remove symbolic link `test2'? y
What gives? is it a directory or isn't it? :P
Note, that a user pointed my attention to this in gentoo's bugzilla:
http://bugs.gentoo.org/show_bug.cgi?id=17838
Thanks for your attention,
--
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux http://www.gentoo.org/~seemant
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E
pgppuFpty9HzT.pgp
Description: PGP signature
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@xxxxxxx
http://mail.gnu.org/mailman/listinfo/bug-coreutils
Was this page helpful?
Thread at a glance:
Previous Message by Date:
click to view message preview
Re: patch: use color mode if CLICOLOR is set
[CCing bug-coreutils. hope you don't mind, Bob.]
On Wed, 19 Mar 2003 11:40:31 -0700 bob@xxxxxxxxxx (Bob Proulx) wrote:
> Michael Wardle wrote:
> > I work in a mixed environment of mostly FreeBSD, GNU/Linux, and IRIX
> > systems. FreeBSD has a color ls that will enter color mode if the
> > -G option is specified or if the CLICOLOR environment variable is
> > set. GNU has a color ls that will enter color mode if the --color
> > option is specified. IRIX does not have a color ls mode.
> >
> > In this environment, a simple shell alias such as "ls"="ls
> > --color=auto" to automatically colorize ls output will not suffice,
> > as non-GNU versions of ls do not understand the--color option. I
> > prefer the FreeBSD approach, which is to use color mode if the
> > CLICOLOR environment variable is set, and if the output is a
> > recognized terminal type, similar to "--color=tty" in GNU ls.
>
> How about something like this in your user shell cusomization?
>
> if ls --version 2>/dev/null | grep -q -e fileutils -e coreutils;
> then
> eval $(dircolors -b)
> alias ls='ls --color=auto'
> elif sometestforbsd; then
> alias ls='ls -G'
> fi
Thanks for the example. It's quite possible I will end up using
something like that (at least in the short term).
> And, of course, the whole topic of color is one of personal
> preference. A large can of worms for those who tread there.
Part of the fun is that ls does not accept the same flags on different
platforms in the first place. I decided to tackle this when I noticed
that Red Hat Linux and Debian GNU/Linux both attempted to have colorized
ls happen by default, but neither of their implementations was
satisfactory to me.
I had a suspicion that colorization might have been a sacred issue, but
I don't really understand why. It is clear to me that various GNU/Linux
distributions wish colorization to happen by default, and I believe my
approach provides a simple setting that will avoid use of aliases, will
work on more platforms, will not colorize if the output is not a
terminal, and will still allow the user to override it using the usual
"--color=<arg>" flag. This does not break any existing behavior, and
only even attempts colorzation if the user has set the CLICOLOR
environment variable. Can you think of a situation where automatically
colorizing output if $CLICOLOR is set could have a negative side effect?
Another approach would be to automatically colorize the listing if
$LS_COLORS is set. It seems to me that LS_COLORS is traditionally set
by running "dircolors", and that the existence of this environment
variable is already a clue that the user (or the vendor/sysadmin) would
like to try to colorize the listing if possible. As previously stated,
it would be trivial to change my suggested patch to do things this way
as well/instead.
Thanks for your reply
--
Michael Wardle
Adacel Technologies
Next Message by Date:
click to view message preview
Re: Bug: Symlink removal.
Thank you for the report.
Here's some previous discussion on the matter:
http://mail.gnu.org/archive/html/bug-fileutils/2003-01/msg00006.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 condition earlier would not be hard,
but would incur some cost -- cost to be borne by non-failing uses
of rm. You might want to incur the cost only when prompting
the user, but then that'd make rm behave differently with -i
than without.
The reason it used to work is because older versions of rm (prior
to the rewrite for fileutils-4.1.9) improperly removed any trailing
slashes. POSIX prohibits that.
I admit that the diagnostics are contradictory,
and I may well fix that some day, but it's not a high priority.
Seemant Kulleen <seemant@xxxxxxxxxx> wrote:
> Currently in gentoo, we offer fileutils-4.1.11 and coreutils-4.5.10 (which is
> currently masked for testing, and we are ready to replace the 3 utils with
> coreutils, as soon as it goes stable according to GNU).
>
> The problem is a slight modification of one reported here:
>
> http://mail.gnu.org/archive/html/bug-fileutils/2003-01/msg00002.html
>
> Now, the results are as follows:
>
> trinity@sephora temp $ mkdir test
> trinity@sephora temp $ touch test/testfile
> trinity@sephora temp $ ln -s test test2
> trinity@sephora temp $ rm test2/
> rm: remove directory `test2/'? y
> rm: cannot remove directory `test2/': Is a directory
> trinity@sephora temp $ rmdir test2/
> rmdir: `test2/': Not a directory
> trinity@sephora temp $ rm test2/
> rm: remove directory `test2/'? y
> rm: cannot remove directory `test2/': Is a directory
> trinity@sephora temp $ rm test2
> rm: remove symbolic link `test2'? y
>
> What gives? is it a directory or isn't it? :P
>
> Note, that a user pointed my attention to this in gentoo's bugzilla:
>
> http://bugs.gentoo.org/show_bug.cgi?id=17838
Previous Message by Thread:
click to view message preview
resubmit: use color ls if is set
Hi
I have remade my patch against coreutils-4.5.10, and this time will
paste the patch into the message body as suggested by:
<http://www.gnu.org/software/coreutils/>
Sorry for not doing things this way the first time, I usually find
separate attachments more useful.
Please see my original message for discussion of the patch.
Thanks
----->8----->8----->8----->8----->8----->8----->8----->8-----
--- src/ls.c.orig 2003-03-19 22:26:01.000000000 +1100
+++ src/ls.c 2003-03-19 22:25:24.000000000 +1100
@@ -1368,6 +1368,12 @@
}
}
+ /* Set default color mode to color_if_tty if CLICOLOR is set. */
+ if (!getenv ("POSIXLY_CORRECT") && getenv ("CLICOLOR"))
+ {
+ print_with_color = color_if_tty;
+ }
+
while ((c = getopt_long (argc, argv,
"abcdfghiklmnopqrstuvw:xABCDFGHI:LNQRST:UX1",
long_options, NULL)) != -1)
@@ -1601,23 +1607,11 @@
{
int i;
if (optarg)
- i = XARGMATCH ("--color", optarg, color_args, color_types);
+ print_with_color = XARGMATCH ("--color", optarg, color_args,
color_types);
else
/* Using --color with no argument is equivalent to using
--color=always. */
- i = color_always;
-
- print_with_color = (i == color_always
- || (i == color_if_tty
- && isatty (STDOUT_FILENO)));
-
- if (print_with_color)
- {
- /* Don't use TAB characters in output. Some terminal
- emulators can't handle the combination of tabs and
- color codes on the same line. */
- tabsize = 0;
- }
+ print_with_color = color_always;
break;
}
@@ -1661,6 +1655,24 @@
}
}
+ /* print_with_color can be set inside the case statement if the
+ --color option is specified or outside the case statement
+ if the CLICOLOR environment variable is set, so handle it after
+ all command line options are processed. */
+ if ((print_with_color == color_if_tty) && !isatty (STDOUT_FILENO))
+ {
+ /* If the color mode is color_if_tty, but output is not a
+ terminal, turn colors off. */
+ print_with_color = 0;
+ }
+ if (print_with_color)
+ {
+ /* Don't use TAB characters in output. Some terminal
+ emulators can't handle the combination of tabs and
+ color codes on the same line. */
+ tabsize = 0;
+ }
+
filename_quoting_options = clone_quoting_options (NULL);
if (get_quoting_style (filename_quoting_options) ==
escape_quoting_style)
set_char_quoting (filename_quoting_options, ' ', 1);
----->8----->8----->8----->8----->8----->8----->8----->8-----
--
Michael Wardle
michael@xxxxxxxxxxxxxx
http://endbracket.net/michael
Next Message by Thread:
click to view message preview
Re: Bug: Symlink removal.
Thank you for the report.
Here's some previous discussion on the matter:
http://mail.gnu.org/archive/html/bug-fileutils/2003-01/msg00006.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 condition earlier would not be hard,
but would incur some cost -- cost to be borne by non-failing uses
of rm. You might want to incur the cost only when prompting
the user, but then that'd make rm behave differently with -i
than without.
The reason it used to work is because older versions of rm (prior
to the rewrite for fileutils-4.1.9) improperly removed any trailing
slashes. POSIX prohibits that.
I admit that the diagnostics are contradictory,
and I may well fix that some day, but it's not a high priority.
Seemant Kulleen <seemant@xxxxxxxxxx> wrote:
> Currently in gentoo, we offer fileutils-4.1.11 and coreutils-4.5.10 (which is
> currently masked for testing, and we are ready to replace the 3 utils with
> coreutils, as soon as it goes stable according to GNU).
>
> The problem is a slight modification of one reported here:
>
> http://mail.gnu.org/archive/html/bug-fileutils/2003-01/msg00002.html
>
> Now, the results are as follows:
>
> trinity@sephora temp $ mkdir test
> trinity@sephora temp $ touch test/testfile
> trinity@sephora temp $ ln -s test test2
> trinity@sephora temp $ rm test2/
> rm: remove directory `test2/'? y
> rm: cannot remove directory `test2/': Is a directory
> trinity@sephora temp $ rmdir test2/
> rmdir: `test2/': Not a directory
> trinity@sephora temp $ rm test2/
> rm: remove directory `test2/'? y
> rm: cannot remove directory `test2/': Is a directory
> trinity@sephora temp $ rm test2
> rm: remove symbolic link `test2'? y
>
> What gives? is it a directory or isn't it? :P
>
> Note, that a user pointed my attention to this in gentoo's bugzilla:
>
> http://bugs.gentoo.org/show_bug.cgi?id=17838
|
|