On Thu, Dec 31, 2009 at 09:18:42PM EST, Eric Blake wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > According to Chris Jones on 12/31/2009 8:31 AM: > > $ ls -alh -F --full-time --color=always > > > > drwxr-xr-x 7 user user 4.0K 2009-12-31 [..] -0500 ./ > > drwxrwxrwt 27 root root 12K 2009-12-31 [..] -0500 ../ > > drwxr-xr-x 2 user user 4.0K 2009-12-31 [..] -0500 d1/ > > -rw-r--r-- 1 user user 0 2009-12-31 [..] -0500 f1 > > lrwxrwxrwx 1 user user 3 2009-12-31 [..] -0500 argetmld1: -> d1: > > > coreutils 6.10-6 The GNU core utilities > > Wow, that's old.
That is the privilege of running debian "stable". > The latest stable version is 8.2. I'm not reproducing your behavior, > whether I tested with 7.0 or the latest git. It looks like ls is > misinterpreting the 'ln=target' portion of LS_COLORS, and trying to > treat the last 5 characters as literal bytes to output for the color > sequence rather than treating the whole directive as a command to swap > the coloring rules over to following through the symlink. I didn't > see anything in the NEWS that specifically mentions a change in that > area, but I may have overlooked something. I ran another test and this time was unable to recreate. So, I went through my bash session's history file and extracted the commands I had issued to the following script: ------------------------------------------------------------------------ #!/bin/bash cd /tmp/dirtests mkdir dir1 cd dir1 mkdir d1 d2 d3 for i in $(ls d*); do ln -s $i l$i; echo l$i; done ls -alh -F --full-time --color=always ------------------------------------------------------------------------ :-( The 'ls d*' explains the appended colons and has nothing to do with dircolors. The only curious behavior is the following: 1. Untainted shell: ------------------------------------------------------------------------ $ ls -alh -F --full-time --color=always drwxr-xr-x 5 [..] 2010-01-01 07:12:50.000000000 -0500 . drwxr-xr-x 4 [..] 2010-01-01 07:19:40.000000000 -0500 .. drwxr-xr-x 2 [..] 2010-01-01 07:01:56.000000000 -0500 d0 drwxr-xr-x 2 [..] 2010-01-01 07:01:56.000000000 -0500 d1 drwxr-xr-x 2 [..] 2010-01-01 07:01:56.000000000 -0500 d3 lrwxrwxrwx 1 [..] 2010-01-01 07:12:27.000000000 -0500 ld0: -> d0: lrwxrwxrwx 1 [..] 2010-01-01 07:12:27.000000000 -0500 ld1: -> d1: lrwxrwxrwx 1 [..] 2010-01-01 07:12:27.000000000 -0500 ld3: -> d3: ------------------------------------------------------------------------ 2. Tainted¹ shell: ------------------------------------------------------------------------ $ ls -alh -F --full-time --color=always drwxr-xr-x 5 [..] 2010-01-01 07:12:50.000000000 -0500 ./ drwxr-xr-x 4 [..] 2010-01-01 07:19:40.000000000 -0500 ../ drwxr-xr-x 2 [..] 2010-01-01 07:01:56.000000000 -0500 d0/ drwxr-xr-x 2 [..] 2010-01-01 07:01:56.000000000 -0500 d1/ drwxr-xr-x 2 [..] 2010-01-01 07:01:56.000000000 -0500 d3/ lrwxrwxrwx 1 [..] 2010-01-01 07:12:27.000000000 -0500 argetmld0: -> d0: lrwxrwxrwx 1 [..] 2010-01-01 07:12:27.000000000 -0500 argetmld1: -> d1: lrwxrwxrwx 1 [..] 2010-01-01 07:12:27.000000000 -0500 argetmld3: -> d3: ------------------------------------------------------------------------ 3. What bash sees: ------------------------------------------------------------------------ $ echo * d0 d1 d3 ld0: ld1: ld3: ------------------------------------------------------------------------ ¹By 'tainted', I mean a shell where the dircolors command picked up the 'LINKED target' statement in my ~/.dircolors database. As a matter of fact, once I get rid of the 'ls d*' nonsense, the 'ls -F' and "LINKED target' combinations works as advertised, with both the link and the target colored in pale blue for a directory 'ld0 -> d0' and the corresponding 'lf0 -> f0' for regular files in the default white. So recreating the problem was really as simple as ln'ing a broken soft link: ------------------------------------------------------------------------ $ ln -s xxx lxxx # where there is no such file as 'xxx' ------------------------------------------------------------------------ There must be some good reason why 'ln' accepts to create such links in the first place. Doesn't bother me, since I could remove the target after the fact, just makes it easier to create broken links, I guess. OTOH, maybe the spurious display of 'argetm' - not sure where the 'm' comes from - could be considered a bug. Or maybe a feature, since is does make broken links very visible? I'll boot into debian testing and ubuntu 9.10 later today, and see what versions of coreutils they ship.. see if I can still reproduce. Would have the added merit that AFAIRC, I haven't fiddled the dircolors stuff on those systems. > But rest assured that your filesystem was not altered - the spurious > 'arget' in the listing comes from a bad attempt at outputting a color > code, not from a changed name. > > - -- > Don't work too hard, make some time for fun as well! Thanks for the tutoring, and Happy 2010. CJ
