Maybe this is not super relevant, but my favorite hack is that any tree-like structure like this can be browsed with ncdu. Here's a gist for breaking down redis traffic by command for example:
https://gist.github.com/petethepig/0f33c910fb2edad8969a5775e...
Author here: Often I have to digest log files and lists of Azure resource names. I prefer to work with hierarchies of things, so I wrote this simple filter. Turns out to quite handy, especially when combined with awk and its friends.
Sorry macos people, I don't own an Apple. (Not strictly true, I have an iMac rescued from a dumpster, but it's running Ubuntu now). Apparently greadlink is available https://stackoverflow.com/a/4031502 for you.
I love this as a post-processor for log-files. We actually have something like this at work. Unfortunately, it's applied to log-files by default. It's terrible: it breaks grep, and I haven't been able to figure a way around that.
Have you found any solutions for grepping on matching lines? Presumably, one could use awk, but awk takes a lot of cycles.
One suggestion: it may help to generalize the newline as the node separator. You may already be doing this (my go is rusty) but instead of https://github.com/birchb1024/frangipanni/blob/7543b4ee15ae7... be able to override the "newline" as the node separator, like you've done with the "spacer" param.
This is really very nice and useful! I read through the examples and thought about something that would be a good addition and then see that “-skip” was just implemented! I can skip (pun intended) using an additional layer of cut or awk because of this.
The detailed examples are great too, showing different use cases and features.
Thank you very much for creating this tool and sharing it.
Definitely very interesting! But I think I'd often end up stuck in the middle of a file with no context about the time of the current line, and struggling to scroll up to capture the parent without shooting past it.
Maybe that could be resolved if it were combined with some sort of GUI / TUI that collapsed subtrees with default (maybe with child count and total anscentor count) e.g. folding by indentation in Vim / Emacs
Seen this about 50 years ago. It was method of saving expensive Teletype ink ribbons. Instead of printing same repeating messages on mainframe log, it printed only those parts that were different from previous line.
And of course empty line was "ditto". Except this wasted paper and was later replaced with "...".
In retrospect, it’s not clear to me why I somehow expected this project to be something more literally arboreal. I even got my hopes up further when I clicked the link and saw that photo of plumerias.
Yet, this project is cool enough that I’m not even disappointed.
I does take advantage of pipelines, as long as it is on the end. You can use awk, sed, cut, sort, grep and a hose of other tools to massage the data before it gets put into graph form.
To become the front-end of a pipe requires that its or some other hierarchical format become an effective standard shared by a number of tools. It can happen.
Looks nice. Perhaps a next step could be an ncurses program that allows you to fold/unfold the trees at arbitrary places, and select entries to reveal their full path (useful for copy+paste).
I find I think about things a lot in tree structures, documentation, todo lists, technical information. I’m really keen to give this a go in my work. Thanks!
- handle corner case of directory printed after contents (find -depth) by avoiding printing nothing but spaces, or nothing but spaces followed by a slash
I love your enthusiasm, and thanks for the code. But 1) the above only works with sorted input and 2) adding it to find that would be like adding '-v' to 'cat' which as we know is considered harmful. http://harmful.cat-v.org/cat-v/
Actually, what it works with is a partially sorted input: an input in some tree-order input, which is what any recursive file system traversal will always put out. It will work with depth first or breadth-first order, with usefully different results, and that order preserved.
All it is doing is hiding the redundancy with spaces to improve the human readability of find's output.
Here it is on the same data in breadth-first. Note the lack of any lexicographic sort: "interfaces" is flanked by "if-down.d" and "if-pre-up.d":
My first program in TXR Lisp in the grandparent comment builds the tree structure from the paths in any order and then prints that, so the paths could be scrambled into random order, yet it will recover the tree structure.
However, not munging the the output in that way and just tweaking the original output for readability has some advantages
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
