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.
