ls on symlinked directories

Alexander Kriegisch Alexander at Kriegisch.name
Wed Feb 28 10:18:28 UTC 2007


Hi community!

Accidentally, I answered Denis' first reply without sending a copy to
the list, so now I am quoting our conversation FYI in ascending
chronological order below. Just two more annotations:

1. Busybox also has the ls -L switch mentioned in my last post. It works
   fine, even without Denis' patch, i.e. ls -L <symlinked_dir> shows a
   dereferenced and detailed directory listing. Even so, the patch is
   great and should be integrated into Bb.

2. The attached patch is my version with the cleaned up diff header
   lines, not Denis' original.

Regards
--
Alexander Kriegisch


----------------------------------------------------------------------


Hi Denis!

>>> >>>  * KNOWN BUGS:
>>> >>>  * 1. ls -l of a directory doesn't give "total <blocks>" header
> >
> > But I don't miss this feature. Is it a real problem?

Nope.

>>> >>>  * 2. ls of a symlink to a directory doesn't list directory contents
> >
> > Coreutils doesn't do it either:

Whatever Coreutils is. I was comparing the behaviour to that of other
(desktop) Linuxes. And each one I know shows the symlinked directory's
content. It is not a good argument that another tool is also buggy. It
is listed as a known bug by the author, after all.

>>> >>>  * 3. hidden files can make column width too large
> >
> > Can you elaborate on #3?

No, I was really just writing because of #2, as I said. I only quoted
all three, because SVN says they are all several years old. I would be
happy enough geeting #2 fixed.


Kind regards
--
Alexander Kriegisch


----------------------------------------------------------------------


On Tuesday 27 February 2007 22:34, Alexander Kriegisch wrote:
>>>> > >>>  * 2. ls of a symlink to a directory doesn't list directory
contents
>> > >
>> > > Coreutils doesn't do it either:
> >
> > Whatever Coreutils is.

coreutils is the GNU package which is used by virtually all Linux
distributions. It contains ls, among other utilities.

> > I was comparing the behaviour to that of other
> > (desktop) Linuxes. And each one I know shows the symlinked directory's
> > content.

Does ls -l follow links on your desktop Linux?
If yes, which distro is it?

> > It is not a good argument that another tool is also buggy.

I am not arguing whether it is bug or not. I want to
simply match coreutils ls, in case people parse
ls output in shell scripts.

> > It is listed as a known bug by the author, after all.

As others indicate, the bug is that bbox ls _without_ -l
doesn't follow links, but GNU ls does.

Attached patch makes bbox ls compatible with GNU coreutils one
regarding link dereferencing.
--
vda


----------------------------------------------------------------------


> > Does ls -l follow links on your desktop Linux? If yes, which distro
> > is it?
> >
> > As others indicate, the bug is that bbox ls _without_ -l
> > doesn't follow links, but GNU ls does.

You are right, it only follows without -l by default. My mistake, I
apologise. There are two switches that can do this, if necessary (Ubuntu
6.10 and others). Quote from the ls manpage:

> > -H, --dereference-command-line
> >     follow symbolic links listed on the command line
> > --dereference-command-line-symlink-to-dir
> >     follow each command line symbolic link that points to a directory

The difference is that the former (-lH) also works for symlinked files
(lists the size and modification date of the referenced file rather than
that of the link), whereas the latter only expands directories. It would
be nice to have those switches in Busybox, too, but if they are not part
of Coreutils, I understand we won't get them. I will try and apply your
patch and check the behaviour of ls without the -l switch, though, and
give you feedback later.

Thanks for now, I think that especially you support on this list is
exemplary. Compliments
--
Alexander Kriegisch


----------------------------------------------------------------------


> > Attached patch makes bbox ls compatible with GNU coreutils one
> > regarding link dereferencing.

As promised, here is my feedback: It works. Thank you. Maybe you could
provide patches for 1.4.1 and other relevant versions still supported. I
guess there might be more users wishing to profit from this.

BTW: I called by patch file busybox-1.4.1-ls_symlink.patch and slightly
changed the header, like so:

Before:
diff -d -urpN busybox.7/coreutils/ls.c busybox.8/coreutils/ls.c
--- busybox.7/coreutils/ls.c	2007-02-11 17:14:18.000000000 +0100
+++ busybox.8/coreutils/ls.c	2007-02-28 00:21:14.000000000 +0100

After:
--- coreutils/ls.c	2007-02-11 17:14:18.000000000 +0100
+++ coreutils/ls.c	2007-02-28 00:21:14.000000000 +0100


----------------------------------------------------------------------


Sorry, yet another message. BTW, was it on purpose to keep this
conversation private and not send copies to the list?

I wrote:
> > You are right, it only follows without -l by default. My mistake, I
> > apologise. There are two switches that can do this, if necessary (Ubuntu
> > 6.10 and others). Quote from the ls manpage:
> >
>> >> -H, --dereference-command-line
>> >>     follow symbolic links listed on the command line
>> >> --dereference-command-line-symlink-to-dir
>> >>     follow each command line symbolic link that points to a directory
> >
> > The difference is that the former (-lH) also works for symlinked files
> > (lists the size and modification date of the referenced file rather than
> > that of the link), whereas the latter only expands directories. It would
> > be nice to have those switches in Busybox, too, but if they are not part
> > of Coreutils, I understand we won't get them. I will try and apply your
> > patch and check the behaviour of ls without the -l switch, though, and
> > give you feedback later.

There also is this option:
> > -L, --dereference
> >     when showing file information for a symbolic link, show information
> >     for the file the link references rather than for the link itself

In Coreutils 6.7 (current version, I did not check others and don't know
which one exactly Busybox is intended to compatible with) we have this:

> > enum Dereference_symlink
> >   {
> >     DEREF_UNDEFINED = 1,
> >     DEREF_NEVER,
> >     DEREF_COMMAND_LINE_ARGUMENTS,      /* -H */
> >     DEREF_COMMAND_LINE_SYMLINK_TO_DIR, /* the default, in certain
cases */
> >     DEREF_ALWAYS                       /* -L */
> >   };

Greetings from Germany (where are you?)
--
Alexander Kriegisch


----------------------------------------------------------------------

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: busybox-1.4.1-ls_symlink.patch
Url: http://lists.busybox.net/pipermail/busybox/attachments/20070228/61c6147d/attachment.diff 


More information about the busybox mailing list