Re: [PATCH] filter ls output by filetype

[Hal Ashburner]

On 29 November 2013 03:21, Pádraig Brady <address@hidden> wrote:

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:
>

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

 

Yep that's some other ways. I think if we put our minds to it we could get well into double figures and we could work out how to make the equivalent of ls -A or its absence work too adding grep -v or similar. I think coreutils users are familiar with much of how ls works and the consistency and robustness of that interface has value in getting the command one wants fluently fairly early on in ones experience of command lines and its output correct and unsurprising.

As for human consumption, I absolutely agree. Which is where I personally found the power of the command line really kick in.

The interactive command can be copied into a file and it runs. It can be thrown into a pipeline to process that output you just saw. For me, the simpler each command the better. In general I'd advocate in favour of making things simpler and more convenient for less experienced users, and given the functionality id done correctly and not a millstone ends up being used by people who know all the other ways and can construct complex pipelines correctly, first time, every time with the benefits of decades of experience.

> 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!

I strongly feel that sysadmins and users have got by for what, four decades or so? Without this feature so it surely isn't world changing or critical. I mentioned at the outset there exist many existing solutions to the problem and this constitutes a n argument for not adding the feature. Coreutils will continue to be wonderfully useful without the suggested feature. I hope I've made the case that the feature make sense to have what ls already does in filtering its output generalized to apply to what it knows and work consistently with the remainder of its interface for maximal discoverability. I think it makes the command line learning curve more intuitive and the probability of error lower. It also appeals to me on aesthetic grounds. -F then using sed to strip a particular trailing character or the whole thing if it's not there seems like an approach that has been rejected for -a -A, -I, -B, --hide, -r, --sort, -t etc.   (But as for what I like, you might hate it and have a superior approach, there's no accounting for taste despite it being important in such things :-)

Anyway that's it. If coreutils hackers and maintainers remain unconvinced I shall say thanks for the discussion and move on to work on something else.

Otherwise I'd be happy to spend some time working through it to ensure it is done the right way - especially from the interface point of view which it would obviously be better to not have to change more than once.