Handover Phist wrote:

> Wow, must be because I'm using a Debian system at the moment. The
> entry for -l in my man page is:
>
> -l use a long listing format

Add "one" to Slackware's score, then. :-)

> ...
> NameVirtualHost *
>
> <VirtualHost *>
> ServerName name.com
> ServerAlias name.com
> DocumentRoot /home/user/name
> </VirtualHost>
>
> Each entry is identical in implementation, but one of them just
> doesn't want to serve from it's own directory, and is listing itself
> as the first named server in the resulting error pages. The only
> difference I can see is a discrepancy in the dir size, which you've
> just explained.

Right; That's certainly not causing the problem you're seeing. Are all
the other virtual servers using document roots under "/home/user"?
If not, are the permissions to every component in the path to
"/home/user/name" correct? Are permissions to files expected to be
served up correct? I don't suppose the web server's error log has any
insight-providing entries?

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On 2007-02-16, Sylvain Robitaille <syl@alcor.concordia.ca> wrote:
> Handover Phist wrote:
>
>> Wow, must be because I'm using a Debian system at the moment. The
>> entry for -l in my man page is:
>>
>> -l use a long listing format
>
> Add "one" to Slackware's score, then. :-)
>
>> ...
>> NameVirtualHost *
>>
>> <VirtualHost *>
>> ServerName name.com
>> ServerAlias name.com
>> DocumentRoot /home/user/name
>> </VirtualHost>
>>
>> Each entry is identical in implementation, but one of them just
>> doesn't want to serve from it's own directory, and is listing itself
>> as the first named server in the resulting error pages. The only
>> difference I can see is a discrepancy in the dir size, which you've
>> just explained.
>
> Right; That's certainly not causing the problem you're seeing. Are all
> the other virtual servers using document roots under "/home/user"?

Yeah, configuration demands it. My client has a whole whack of domains
and communicates with his account through Samba. This necessarily means
that pretty much everything is 644 perms (damn MS for not making an NFS
client).

> If not, are the permissions to every component in the path to
> "/home/user/name" correct? Are permissions to files expected to be
> served up correct? I don't suppose the web server's error log has any

Yeah, like I said before it's all uploaded vie Samba. There's a single
account with several directories each representing a domain like so:

/home/user/domain1.com
/home/user/domain2.com
/home/user/domain3.com
/home/user/domain4.com
/home/user/domain5.com

Yet for some reason, www.domain4.com reads from /home/user/domain1.com,
even though that's not the declared DocumentRoot. I'm missing a
misspelling or something somewhere I'm sure. `apachectl configtest`
reports OK.

> insight-providing entries?

No, my only clue was hitting domain4 with a browser and seeing domain1
show up in the server string. The logs are the default common logs
though, and I may look at that this weekend. For now I have a Powerbook
that needs a pile of data transferred to it (I need minions for this
kind of work).

--
"Take that, you hostile sons-of-bitches!"
-- James Coburn, in the finale of _The_President's_Analyst_

http://www.websterscafe.com

On Fri, 16 Feb 2007 05:47:51 +0000, Sylvain Robitaille wrote:

> Handover Phist wrote:
>
>> Wow, must be because I'm using a Debian system at the moment. The entry
>> for -l in my man page is:
>>
>> -l use a long listing format
>
> Add "one" to Slackware's score, then. :-)


i have slack 11.0, and 'man ls' gives:

-l use a long listing format

the package that provides this man page is:
/var/log/packages/coreutils-5.97-i486-1:usr/man/man1/ls.1.gz

do you know why do i get different man page?

--
i.

Ivan Rajkovic <ivanrajkovic@gmail.com> wrote:
> i have slack 11.0, and 'man ls' gives:
>
> -l use a long listing format
>
> the package that provides this man page is:
> /var/log/packages/coreutils-5.97-i486-1:usr/man/man1/ls.1.gz
>
> do you know why do i get different man page?

If so it seems as if Slackware 11 has upgraded to the same upstream
sources as debian have. On my Slackware 9.1 I get the following:

/var/log/packages/coreutils-5.0-i486-4:usr/man/man1/ls.1.gz

-l Write (in single-column format) the file mode, the
number of links to the file, the owner name, the
...

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc1(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

On 2007-02-16, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> Ivan Rajkovic <ivanrajkovic@gmail.com> wrote:
>> i have slack 11.0, and 'man ls' gives:
>>
>> -l use a long listing format
>>
>> the package that provides this man page is:
>> /var/log/packages/coreutils-5.97-i486-1:usr/man/man1/ls.1.gz
>>
>> do you know why do i get different man page?
>
> If so it seems as if Slackware 11 has upgraded to the same upstream
> sources as debian have. On my Slackware 9.1 I get the following:
>
> /var/log/packages/coreutils-5.0-i486-4:usr/man/man1/ls.1.gz
>
> -l Write (in single-column format) the file mode, the
> number of links to the file, the owner name, the
> ...
>
> regards Henrik

That's what I get on 10.1 also. Wonder why the page got b0rked.

--
"Take that, you hostile sons-of-bitches!"
-- James Coburn, in the finale of _The_President's_Analyst_

http://www.websterscafe.com

Ivan Rajkovic wrote:

>> Add "one" to Slackware's score, then. :-)
>
> i have slack 11.0, and 'man ls' gives:
>
> -l use a long listing format

Argh! Take one back from Slackware's score! :-(

> the package that provides this man page is:
> /var/log/packages/coreutils-5.97-i486-1:usr/man/man1/ls.1.gz

The system I had originally checked on has coreutils-5.0-i486-4. I'm
sure that that's where the difference lies.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Handover Phist wrote:

> That's what I get on 10.1 also.

10.2 also, with coreutils-5.2.1-i486-1.

> Wonder why the page got b0rked.

Newer coreutils package. I find "info" pages annoying not only because
the interface to them is far from intuitive, but also because it tends
to make for incomplete man pages. :-(

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Sylvain Robitaille wrote:
> Handover Phist wrote:
>
>> That's what I get on 10.1 also.
>
> 10.2 also, with coreutils-5.2.1-i486-1.
>
>> Wonder why the page got b0rked.
>
> Newer coreutils package. I find "info" pages annoying not only
> because the interface to them is far from intuitive, but also
> because it tends to make for incomplete man pages. :-(

The system can generate man, info, ps, pdf, html, and text versions
from a single source. It's not the fault of the info system, but
the fault of the packager.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

Sylvain Robitaille wrote:
> ...I find "info" pages annoying not only because
> the interface to them is far from intuitive...
>

You are correct, running info in a term window is nightmarish!

But the tkinfo program solves all that. I've been running version
2.5 for years, but I think they're up to 3.5 or thereabouts by now.

The development has been a bit fractured, I'm not sure where the most
recent version lives these days...

Handover Phist <jason@nospamwebsterscafe.com> wrote:
> I'm having trouble googling up a description of the fields produced by
> ls -l. For example:
>
> drwxr-xr-x 10 user users 20480 2007-02-15 12:13 filename

The 2nd field is called the "link count", essentially:
how many "filenames" does this file have (hard links, not symbolic
ones). A directory has at least 2 - its filename itself and the . entry
IN it (which points to current dir, so TO this directory.
When the dir has subdirs, each of those has a .. entry, so will add one
to the link count.
In essence (unless you created OTHER hard links) thus the 2nd field is:
number of subdirs + 2
for any directory.

> I know what every one of these is except the second field. This is the
> output of a directory name using ls -ld, and I want to know why it's
> using 20k when every other dir uses 4k.

This is probably in a ext2 or 3 file system?
Directories in that file system do NOT shrink, so if at any time that
directory contained SO many files that the directory got extended, it
will never get smaller again.
probably in this dir you once had a LOT of files, which now have been
deleted. As the size is also dependant on the length of those filenames,
it isn't easy to say HOW many filenames that would have been.
But for instance (if your root fs is ext2/3 too) look at the size of dirs
in /usr and you'll see that /usr/bin and /usr/lib are very large too
(about 64 K here). In MY system /usr/bin contains some 2000 files, while
/usr/lib _only_ has 1200, but they are of comparable size as /usr/lib
has many more "longer" filenames.

PS: this IS one of the advantages of reiserfs, because of the total
different way of storing directories (not as a linear list of file-
names) directories on THAT fs reflect the true (and current) size of
the filenames (always: including those of subdirs, but not the content
OF those subdirs) themselves, in reiserfs directories DO get smaller
when files are removed out of them.
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************