On Mon, Apr 2, 2012 at 13:10, Karel Zak <kzak@xxxxxxxxxx> wrote: > On Sun, Apr 01, 2012 at 08:19:32PM +0200, Sami Kerola wrote: >> The new version of the command is nearly identical to old. Major >> differences are: >> >> * New output is a little rough what comes to alignment. This is >> flagged as FIXME item in source. >> * The command is much quicker than perl implementation which used >> to exec ls -ldU. >> * Size of chkdupexe binary is about five times bigger than perl >> script. > > I have doubts about chkdupexe, do we really need this command? > > * it provides very rarely used functionality (for example nobody > complains that the command is missing in Fedora/RHEL ;-) > > * it seems that you can replace it by > > ls $(echo "$PATH" | tr : ' ') | sort | uniq -d > > or we can extend which(1) or so... > > > I see two possible ways: > > 1) mark chkdupexe as deprecated and remove it from distros > > 2) or add new command (lspath ?) and get much more information from > $PATH (like duplicates, per-directory stats, per-owner stats, > per-device stats, selinux summary, suids, etc.) and make chkdupexe as > alias to the new command (just for backward compatibility). > > If 2) makes sense then it would be better to have it in coreutils ;-) > > > CC: Padraig > > ... let's flame :-) I am in favour of removal. As you said few, if anyone, is using this command and to be honest I do not know why I would use it. Duplicated commands in path are more likely to be intentional than interesting. Perhaps extended 'lspath' might be more useful, but again I'm struggling to come up with real use case, and the fact that existing tools allow quite easily do similar things. For example find suid bit executables. find $(echo $PATH | tr ':' ' ') -mindepth 1 -maxdepth 1 -perm -u+s Besides isn't the path polluted enough with all sort of legacy things? Shouldn't removing of crud be considered virtue? -- Sami Kerola http://www.iki.fi/kerolasa/ -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
