Tree, treeFilt 1.0 ------------------ --You Must Have Python For This One-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are two trees! Well yes, I didn't know that and I found out just before uploading (phew!). Anyway, the original tree by Steve Baker should be better since it's an ELF executable. This one has a python source (treeFilt) which you may like changing (or see how it works), and it can process ls-lR.gz files too!. A lot of very useful options such as depth, total under branches, files under dirs, subdirs total size etc are here too. If you want to keep this one and the original then rename tree which is a silly little bash script to another name and place it with the executables. Of course the original tree is the standard here, and i have no intention to claim authorship! The two programs differ in the options, the presentation and the speed. That tree doesn't show all files while it concentrates on directories and directory sizes while it has the old MS-DOS \-- thing. Big Deal! To see what it does do a 'tree -st /etc' Gee! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Now what? --------- I see you've just unpacked & untared. So now all that remains is to move tree.1 to /usr/man/man1 and 'tree' and 'treeFilt' to /usr/bin or wherever you keep file utilities. And we're ready to roll. Try a 'tree /etc' for example (i insist). What does it Do? ---------------- You know a Unix's directory tree is a jungle. And sometimes we don't only care for locating a file, but it's also useful to have an 'idea' of how things are organized. That is the Tree. And tree shows the Tree in a nice way. The main thing is done by the script (this is the python script) treeFilt. TreeFilt is actually working as a filter and takes for input a recursive directory listing (in the form of ls -lR), and outputs the tree-like structure. I don't know what will be the result if a different file is piped to treeFilt (very possible is IndexError), so since it's pointless to do that don't complain about bugs if you do! I waited too Long and i was afraid it would erase everything and i CTRL^Ced? ---------------------------------------------------------------------------- TreeFilt may take some time to process a 'BIG' directory listing, that happens because all dirs of the listing must FIRST be loaded before it can be processed. So be patient! (well, it's not that long actually. Calculate how long it would take an ls -lR anyway). Why is it a filter? ------------------ I made treeFilt to be a filter (that means that it can take the listing from redirection only f.e. 'cat listing.file | treeFilt'), because this way we can easily process compressed files, etc. For instance 'zcat ls-lR.gz | treeFilt' was a good reason to make treeFilt a filter! Also, unix people love redirections, pipes and filters ! Now tree is a silly little BASH script that all it does is actually piping the ls -lAR to treeFilt (and passing parameters). Check it out. Options & Features? ------------------- Now to the very interesting part. TreeFilt understands four options 'f', 's', 't', and 'd'. First of all let's leave out the 'd' thing and see the rest. For each directory displayed the 'f' option additionally shows the number of files contained in it. In a similar way the 's' option shows the total size of files in each directory. The 't' option shows a grand total of the size of the whole tree! The 'd' option now, specifies the depth at which treeFilt should go down showing branches. The number of depth is the next argument in the command line following the a 'd'. For instance a valid invocation is 'treeFilt -fst -d 3'. IF at the same time depth and 'f' or 's' are invoked then the result depends upon 't'. Without 't' treeFilt will print normally the number of files or their sizes as if no depth limitation was set. On the other hand if 't' is set then treeFilt will print the TOTAL size or number of files BELOW each branch it stops. For example 'tree -fs -d 1 /' will show the size of the files contained in the directory usr next to the +--usr branch, while the command: 'tree -fst -d 1 /' will show the total size of ALL the subdirectories below the +--usr branch. In my computer for example the first shows 168kB and 2 files in /usr while the second 131341 kB and 5930 files! That is cool. If 'tree' is invoked then the form must be 'tree [[options] path]', that is the last argument (if there is one), is assumed to be the path to the directory to the tree's top (that is up to the script and not to treeFilt). So if one wants to tree the current directory AND se some of the options, it should be 'tree -fst .' One strange thing? ------------------- Yeah. I Know. If one tries 'ls -lAR /usr/lib | treeFilt -d 2' he/she will get nothing! That is because the ls shows full path dirs in that case so depth starts at 2. The tree script doesn't have this problem since it will 'cd' to the desired directory and THEN perform the 'ls -lAR'. So bash scripts are better! Take a look at the script (the tree one) to get an idea of what is going on. And if one wants to write a better version of the script remember: "you have to cd before you tree" But seriously folks, i'd rather cd in the script than fix that in treeFilt (it a looot more than a simple cd). Another strange thing in the code? ---------------------------------- In the '#get from the stdin' was it eh? Well it seems that the same code is repeated twice with little differences (hmm, smells like OOP here). It's the usual problem of the below C code : for (;i<10000;i++) if (a==ADD) b[i]+=c; else b[i]-=c; as we can see the check if a==ADD is done 10000 times while only one would be ok. But then again: if (a==ADD) for (;i<10000;i++) b[i]+=c; else for (;i<10000) b[i]-=c; has a very _same_ code twice. Now as the commands in the for() loop become more the dillema of which implementation to use becomes bigger (i have a graph somewhere :) In our program now, it seems like things could be faster. (we don't want to be like M$oft and spend CPU for fun) The way i see it, we should have different 'for' loops depending on the following : show_sizes?, show_numbers?, count_totals?, is_depth_limited? So that is (mumble mumble...) 16 different but very _same_ 'for' loops there to get the fastest results. I guess it's time for the OOP approach. If any good person has any ideas about that, contact now! What else can i change? ------------------------ One more thing that can be changed (well a lot can but this is made in a way that can be easily changed), is the distance between the tree's branches. At first you may notice that the distance is 3 characters. That can be changed by adjusting the BRANCHWIDTH variable in the python script at a number you prefer. 2Do? --- Yeah, well, one thing actually. Find a way to avoid showing directories which are symbolic links by an additional option. Symbolic link directories are often big and having little important info (especially if their link is also included in the tree). Also if there are bad links (infinitive recursion) we will have memory problems. So it would be nice to have an option to avoid listing those. Ah! yes, and second thing is to make a binary version for those who don't have python (but not for those who have a different CPU:) About & Copying? --------------- The program is written in Python (tested in 1.3), and well i have to say that python is a pretty cool language alright. Check out www.python.org for more. Let's say I'll be happy if you find this useful (and use it). I mean people like Linus, the guys at X, and all the others who have written HUGE programs give them away for free. I'm ashamed even for having a 'COPYING' section here. It's absolutely free. Anyway. And you can do whatever you want with it (ahem). For anything else contact me at Stelios