coreutils
[Top][All Lists]
Advanced

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

Re: [PATCH] filter ls output by filetype


From: Pádraig Brady
Subject: Re: [PATCH] filter ls output by filetype
Date: Thu, 28 Nov 2013 14:09:10 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 11/28/2013 01:49 PM, Hal Ashburner wrote:
> ls filters by filename - leading dot -a -A or --ignore pattern
> I have shell script that just shows directories by interposing `test` between 
> two calls to ls in a pipeline to give me ls like behavior. Ls actually knows 
> the filetype so I thought why not just filter on it in ls given filtering is 
> something ls does? I noted this was not a rejected feature request and 
> thought it might go well as a request accompanied by a patch.
> 
> --just
> was the best switch I could think of to achieve this end. I could easily be 
> convinced there exists a better one. (--show-only? --showing?)
> 
> examples:
> just list the block device files
> 
> 
> ./ls --just b /dev
> loop0  loop3  loop6  ram1   ram12  ram15  ram4    ram7  sda   sda3  sda6    
> sda9
> loop1  loop4  loop7  ram10  ram13  ram2   ram5    ram8  sda1  sda4  sda7    
> sdb
> loop2  loop5  ram0   ram11  ram14  ram3   ram6    ram9  sda2  sda5  sda8
> 
> ./ls --just=normal
> ABOUT-NLS    config.log     NEWS
> aclocal.m4    config.status  README
> AUTHORS        configure      README-hacking
> bootstrap    configure.ac <http://configure.ac>   
> README-package-renamed-to-coreutils
> bootstrap.conf    COPYING        README-prereq
> cfg.mk <http://cfg.mk>        dist-check.mk <http://dist-check.mk>  
> README-release
> ChangeLog    HACKING        README-valgrind
> ChangeLog-2005    init.cfg       thanks-gen
> ChangeLog-2006    Makefile       THANKS.in
> ChangeLog-2007    Makefile.am    THANKStt.in
> ChangeLog-2008    Makefile.in    TODO
> 
> can filter on two types by applying the switch twice.
> 
> ./src/ls --just=normal --just=symbolic-links -l test
> total 0
> lrwxrwxrwx 1 hal hal 13 Nov 29 00:20 link-to-somefile -> test/somefile
> -rw-rw-r-- 1 hal hal  0 Nov 29 00:20 somefile
> 
> 
> Why might rejection of this feature and patch be a good idea?
> You can get this kind of thing done (sort of) with
> $ find . -type d --maxdepth=1 -ls
> or shell globbing abuse eg
> $ ls -d */
> but obviously such things are not ls and lose the familiar and consistent ls 
> options such as find displaying a differing long format, no colored output, 
> sorting, control of display of dotfiles etc. However all of these 
> alternatives' shortcomings can be alleviated with fairly ordinary shell 
> pipelines involving sed and/or test at the cost of a simple, robust and 
> convenient user interface as provided by ls.

> 
> Shortcomings/BUGS/Possible future enhancements :
> 1) doesn't work with -R for anything except directories
> 2) Doesn't have a mode to filter based on permissions (eg show only 
> executables or setuid etc).
> 3) Doesn't follow symbolic links and then filter them based on the type of 
> file they are pointing at and I haven't yet worked out how to add the command 
> interface for "including symlinks to" in a way that is not too ugly.
> 4) Others that exist of which I haven't considered.

3 at least would be handled by filtering outside ls,
by leveraging the --classify option.

ls --color -lF | sed -n 's#/$##p'

> On the off chance that there does happen to be interest in this feature and 
> patch by coreutils hackers, I am more than happy to assign the copyright to 
> GNU on the understanding it will be published under the appropriate version 
> of the GPL for coreutils.
> The patch should apply cleanly to the current default git checkout. I'm 
> subscribed to the list and interested in any and all feedback.
> 
> Thank you for taking the time to give this request an appropriate level of 
> consideration.

Thanks for taking the time to do the patch.
However the bar is high for new options to ls,
and I'm not sure this provides enough benefit.
I'd be 60:40 against adding it.

thanks,
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]