Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Oct 2000 01:50:21 +0200
From:      "Jose M. Alcaide" <jose@we.lc.ehu.es>
To:        Warner Losh <imp@village.org>
Cc:        Will Andrews <will@physics.purdue.edu>, Jordan Hubbard <jkh@winston.osd.bsdi.com>, Jeremy Lea <reg@FreeBSD.ORG>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Who broke "ls" in FreeBSD? and why?
Message-ID:  <39F6203D.123CCE95@we.lc.ehu.es>
References:  <20001024081136.K1604@puck.firepipe.net>  <scott@scottyelich.com> <12367.972372237@winston.osd.bsdi.com> <200010241757.LAA17136@harmony.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Speaking of ls(1)...

$ mkdir Arghh
$ touch Arghh/{one,two,three}
$ ls Arghh
one   three two
$ chmod a-x Arghh
$ ls Arghh && echo SUCCESS
SUCCESS
$ ls -l Arghh && echo SUCCESS
SUCCESS

ARGGGGHHHHH!!!! :-)

This is not the expected behavior. If a directory does not have
search permission, but it has read permission, a plain "ls" (or "ls -i")
should list its contents, while "ls -l" should fail. And still worse,
when ls fails to list the non-searchable directory contents, it
does _not_ return an error code.

I tried to find the cause of this behavior in the ls source code,
but it uses the fts(3) functions, which I am not used to.

Cheers,
-- JMA
****** Jose M. Alcaide  //  jose@we.lc.ehu.es  //  jmas@FreeBSD.org ******
** "Beware of Programmers who carry screwdrivers" --  Leonard Brandwein **


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39F6203D.123CCE95>