Re: [PATCH] filter ls output by filetype

[Pádraig Brady]

On 11/28/2013 03:09 PM, Hal Ashburner wrote:
> 
> 
> 
> On 29 November 2013 01:09, Pádraig Brady <address@hidden 
> <mailto:address@hidden>> wrote:
> 
>     On 11/28/2013 01:49 PM, Hal Ashburner wrote:
>     > 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'
> 
> 
> That's pretty neat. I wonder how many people know that. I got about 8 
> responses at my local user group on how to do it and that didn't come up.I 
> think the respondents all have between 10 and 30 years professional unix 
> sysadmin and dev experience. The fact I didn't know it less interesting - 
> there's lots I don't know.
> 
> But 3, hmm, not so much for me. You can't easily do ls -IF | sed -n 's#/$##p' 
> | while read DIR; do something_with $DIR; done. That kind of very simple and 
> very powerful pipeline I love. But of course you can with a pipe to more sed 
> or awk or perl or anything turing complete? Many of us will get it right 
> eventually too.
> The information to filter on is there, ls has it and can display it. It's 
> just how convenient and robust it is to use it to make decisions. ls is used 
> by people with all levels of experience, expertise and confidence. Most if 
> not all the scripting languages give you total control of what is listed and 
> how to display with no need of ls and that's another way to go too. Obviously 
> it also doesn't work where -F does nothing for you, eg block & character 
> devices.

I presume you meant -lF not -IF
If you're processing the output of ls then it's best
to avoid the long listing and also handle symlinks like:

 ls -ALF | sed -n 's#/$##p' | while read DIR; do echo process "$DIR"; done

However as a general rule ls is for human consumption,
and if you want to further process the output you'd
be better off starting with find(1), which is better
suited to filtering and generating output for further processing.
That might also help to handle non printable chars in a robust way:

 find -L . -mindepth 1 -maxdepth 1 -type d -print0 |
 while read -d $'\0' DIR; do echo process "[$DIR]"; done

> I think all of 1,2 and 3 are quite doable cleanly by filtering inside ls 
> (which filters already so it's not a new task, just an extension and 
> generalization of existing functionality). I'm in favor of the simplicity, 
> discoverability and robustness of the interface that ls can provide. I don't 
> think this is just any old junk, but something that is powerful and yet 
> simple. I'd want to be thinking carefully about the appropriate switches to 
> keep it as simple and robust as possible.
> 
> Anyway, thanks for the review. Not going to touch it further if you're 
> against it.

Please continue to debate if you feel strongly.
Open discussion is encouraged.

thanks,
Pádraig.