Subject: Bug: Symlink removal. - msg#00077

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