ls -A

[John Chambers]

In article <1248 at virtech.UUCP>, cpcahil at virtech.UUCP (Conor P. Cahill) writes:
> In article <1989Oct7.191435.26382 at rpi.edu>, tale at pawl.rpi.edu (David C Lawrence) writes:
> > Darn those broken shells.  (To be fair, Conor didn't comment on
> > whether ls -A for root is "the right thing", but it does not have the
> > consistency he addressed in the article.)

> I don't like it.  If I wanted to see the . files I would use the -a.  I don't
> feel that it provides any special service to have it operate differently
> for root.  Root should know enough to use the -a when he wants to.

More to the point is that commands don't just come from people at keyboards;
they also come from scripts.  I've written several applications that include
some special-purpose directories containing files of one type, and scripts
that do things like:
	for f in `ls foo`
	do  <something with each $f>
	done
It is a good idea to include some documentation in all your directories,
and management often decrees that There Will Be README Files Everywhere.  
I tend to agree; in the special-purpose directories, I just call it .README 
and all is fine.  Until the script is run by a super-user, in which case 
the ls command above includes the .README in the list, and all hell breaks 
loose.

I like to test things out first as an ordinary user, then turn them over to
the systems' users, who will eventually run them when they are logged in as
root.  It's real exasperating to have something thoroughly tested and working, 
and get bitten by something as stupid as this.  With things like this lurking 
in our systems, it's not at all surprising that our software is so flakey.

Grumble...

-- 
#echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:'
echo '	John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)'
echo ''
saying