4 ms·

If you eval this simple pipeline file -b `echo $PATH:|sed 's/:/\/* /g'`|cut -d\ -f-2|sort|uniq -c|sort -n it prints a histogram of the types of all the

• viraptor 6y ago
  You don't. If you use it once, meh. If you share it with anyone or preserve for the future, why would you want it to be cute? It's just a few lines in python, probably takes just as long to write because you don't have to play with what needs to be escaped and what doesn't. You can actually tell what's the intent of each line and it doesn't fail on paths starting with minuses or including spaces. Outside of one time use or a code golf challenge, it's not cute. https://pastebin.com/FnBCgHUm https://pastebin.com/FnBCgHUm
  • enriquto 6y ago
    This is not about "code golfing", the "sort|uniq -c|sort" combo is in the hall of fame of great code lines. The PATH thing in my script was an unnecessary distractor, consider this: file -b /bin/* /usr/bin/* |cut -d' ' -f-2|sort|uniq -c|sort -n There are no bizarre escapes nor anything. Besides, the "file" program is called only once. The python equivalent that you wrote may be better if you want to store it somewhere, but it takes a lot to type, and it serves a different purpose. The shell line is something that you write once and run it because it falls naturally from your fingers. Moreover, you can run it everywhere, as it works in bash, zsh, pdksh and any old shell. The python version requires an appropriate python version installed (3 not 2).
    • viraptor 6y ago
      > Moreover, you can run it everywhere Issue 1: `zsh: argument list too long: file` Issue 2: `file -b /usr/bin/apt` returns 3 lines, so the entries you count end up being: 2 /usr/bin/apt (for 1 Mach-O universal Yes, it looks easier, but there are traps.
    • marcthe12 6y ago
      find-xargs combo could have been better. It also prevents the case where you cross arg max
      • enriquto 6y ago
        Definitely! It is also much slower, though, especially if you need to add "-L 1". I prefer to try first that way, if the argument list is too long, then try xargs. On the other hand, the limitations on the command lenght of modern shells are idiotic. The only limitation should be the amount of available RAM, not an artificially imposed limit.
• junke 6y ago
  - This fails on badly formed PATH, or malicious PATH - When PATH contains entries that no longer exist / are not mounted, substitution with "sed" gives a wildcard that is not expanded, and eventually makes "file" report an error, which is not filtered out - If PATH contains entries that have spaces, the expansion is incorrect
  • enriquto 6y ago
    More realistically, it also fails if you have directories on your path that are symlinks to other directories in the path. In that case their programs are doubly-counted. Anyways, if your PATH is malicious then you have worse problems than this silly script :)
    • JdeBP 6y ago
      Your error is in thinking that either of those cases is in any way malice.
    • junke 6y ago
      I agree, but "more realistically"? those cases were pretty realistic I think. If you run the script on a box where you have users who can do whatever they want, at least the script should fail on bad inputs. PATH=rm -rf :/bin