Re: list files but not directory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2009-08-22 at 13:00 -0400, William Case wrote:
> Hi Patrick;
> 
> To continue as a conversation, but not belabour the point.
> 
> On Sat, 2009-08-22 at 11:14 -0430, Patrick O'Callaghan wrote:
> > On Sat, 2009-08-22 at 03:59 -0400, William Case wrote:
> > > Hi Tim;
> > > On Sat, 2009-08-22 at 16:58 +0930, Tim wrote:
> > > > On Fri, 2009-08-21 at 10:35 -0400, William Case wrote:
> > > > > It seems illogical, that 'ls' wouldn't have a flag that just shows
> > > > > files when it has a flag for directories.
> > > > 
> > > > Though that flag "ls -d" has a completely different purpose (show
> > > > directory names, rather than go into them and list their contents).
> > > > 
> > > True.  But whatever its purpose, it does give me a list of directory
> > > names.
> > 
> > In fact it lists *all* its arguments as usual (the default being ".", as
> > always), except that those which are directories are not listed
> > recursively. It doesn't "give a list of directory names", unless that's
> > what the arguments happen to be.
> > 
> 
> Yea, I know.  But by reading the ls man page and a couple of experiments
> I was able to get ls -d ./* to print a list of the directories to stout.

"ls -d ./*" is exactly the same as "ls -d *", which in turn is the same
as "ls". Try sending the output of each of these to a temp file (not in
the current directory of course :-) and running diff on them.

> > There are no flags to ls which mean "ignore any arguments which belong
> > to this class of object".
> > 
> And isn't that a shame.

That's a matter of opinion of course, but many people think ls already
has too many options. As the old saying goes, when your subroutine takes
13 arguments, you probably forgot a few.

> > > All that I am saying is that it would be handy to have a simple util
> > > that listed file names.
> > 
> > If you want to filter out directories, use grep, as several people have
> > pointed out. That's the Unix Way (tm).
> 
> But why make people use grep ( a whole to learning curve; particularly
> if you are new) when I simple option could do it for you.

Someone who uses the Unix Shell but doesn't know about grep is working
with one hand behind his back. I don't mean he needs to know all of
grep's more exotic options, but the basic usage is, well, basic.

> > 
> > >  I suggest 'ls' because it is probably the most
> > > used and first learned listing utility and therefore would be the place
> > > to have it.  It would be useful to beginners (particularly those who do
> > > not yet have any idea what a regexp is) and for script writing or piping
> > > to sed, awk, grep or a new file (or for appending).
> > 
> > Said beginners need to learn that *directories are files* (and devices
> > are files, named pipes are files, etc.). This is an important concept
> > which should not be hidden.
> 
> I don't limit my remarks to "Said beginners", I think the option would
> be useful to practised Linux users too.  But remembering the
> befuddlement, confusion and fluster I felt as a new user did bring the
> issue back to mind.

Here's another oldie: Windows is easy to learn, but Unix is easy to use.
Two entirely different things. Plus of course you have the GUI tools *as
well* these days.

> Nor do I think it is the place of any Linux distribution to decide when
> and what users should learn.  To me, that's M$ type of thinking.
> Perhaps some users can't remember as far back as when they first started
> using Linux or Unix, or perhaps they have always had an intuitive grasp
> of how computers work.

We all had to learn this stuff. IMHO the fact that it's now
second-nature to us is evidence of good design. The original Unix
designers had good taste, meaning they knew what to leave out.
Unfortunately a lot of that's been lost over the years, but the core
system is still pretty much the same. If it weren't, I'd be using a Mac.

> Or, maybe, there is just the natural old pro desire to force an
> unnecessarily onerous initiation period on beginners. 

Is it better to learn to drive with a manual or automatic gearbox? I
insist that my kids learn with a stick shift, even if they later drive
automatics, and it as nothing to do with wanting them to suffer.

> In lieu of providing an additional option to 'ls' coreutils could
> provide an 'lsf' command that would print the simple information that is
> desired.  I didn't jump into this thread because it was something I
> REALLY NEEDED, but because I thought it might be useful to others.

It's easy to write a Shell one-liner that *uses* the existing ls, and
hence has all its options as well. A separate command for this single
purpose is just teeth-gratingly wrong.

poc

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux