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.
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.
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...
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.
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.
> 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.
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 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
- 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 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!
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
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.
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 "...".
57 comments
[ 2.2 ms ] story [ 133 ms ] threadMay I suggest the name txtree?
Have you found any solutions for grepping on matching lines? Presumably, one could use awk, but awk takes a lot of cycles.
(Really I just want `tree` on `s3`. There's `s3-tree` but that uses the entire bucket rather than a prefix)
The detailed examples are great too, showing different use cases and features.
Thank you very much for creating this tool and sharing it.
For the record, the relevant commands are
andI am a heavy user for `find <> | xargs grep` -- this makes my life so much sweeter. Thank you @birchb!
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.
What do you do when the same line is encountered?
Any way you could add build instructions to the README?
Somewhat unrelated: I discovered some time ago that the column command (from util-linux) can print trees of hierarchical data (up to 2 levels deep).
From the man page:
column(1): https://github.com/karelzak/util-linux/blob/master/text-util...I always thought it was weird that "do one thing and one thing well" stopped short of dealing with tree representations on the commandline.
So it fits well with the UNIX ethos of a small tool doing one thing well, but not so much the concept of pipelines, which is closely related.
Obviously not this tool’s fault.
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.
This only happens every other decade or so.</sarcasm>
https://news.ycombinator.com/newsguidelines.html
Please review https://news.ycombinator.com/newsguidelines.html and stick to the rules from now on.
```
<img src="frangipanni.jpg" alt="A Tree" width="200" align="right">
```
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
- swap pointers to flip buffers instead of strcpy
- handle corner case of directory printed after contents (find -depth) by avoiding printing nothing but spaces, or nothing but spaces followed by a slash
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
Yet, this project is cool enough that I’m not even disappointed.
And of course empty line was "ditto". Except this wasted paper and was later replaced with "...".