I use the piping feature of less to add some interactivity to git-log.
When a commit is "selected" (at the top line of the screen), usually after a series of n/N, I can press a shortcut that invokes an action on this commit.
Currently, I use it for two things:
1. Running git-show on a commit I'm interested in. The cool thing is that once I quit the git-show's less, I'm back to where I was in git-log's less. They stack.
2. fixup-ing a commit, after verifying with the command from 1. that it really is the one I want. I've had enough problems with git-absorb and git-fixup that I prefer to do it myself.
I detect when a particular command is running[1] and set up keyboard shortcuts that send key sequences to less and ultimately lead to the top line of the screen being piped to a short script of mine that extracts the commit hash and does something with it.
[1]: via a debug trap in bash, which sets the terminal title, which, in turn, is detected by keyd-application-mapper; other setups are possible, I used to use tmux for that.
If that's what you use as your yardstick of what's Unixy, then I guess you don't consider "find" to be Unixy, in spite of being one of the early Programmer's Workbench tools.
Short options were a compromise to deal with the limits of the input hardware at the time. Double dashes were a workaround for the post-dash option car crash traditional Unix tooling allows because teletypes were so slow. There is nothing particularly Unixy about any of these options other than the leading hyphen convention.
Articles like this one are more likely to drive people away from make(1) than teach them to appreciate it.
This Makefile is anything but simple. It uses advanced features that are meant for complicated situations, just to create a few symlinks. The same symlinks, every time. And if you introduce a new dotfile to the repo, you have to update the Makefile too.
It also makes no use of the main feature of make(1) - to track files for changes, and update them.
For demonstration, here is the same functionality, in sh(1):
What's funny is people use make as just an imperative task runner. For some reason people prefer to write a makefile with 10 commands rather than write 10 short shell scripts.
The real point of make is it's a declarative build system. You just tell it to make and it will do what needs to be done by figuring out dependencies and rebuilds.
Make is also a highly discoverable entry point to a project.
A Makefile with tasks that just run external scripts is much easier to find than the scripts directly. Add some help texts and it’s a great DevEx multiplier.
With a Makefile I can generally just run `make` or `make <tab>` to have a feel for what's available. It's right there on my terminal, which is usually the first thing I interact with when I open a repository. If enough of the engineers use it, it stays up-to-date as it gets fixed and updated along with any other changes.
Documentation OTOH has a tendency to be forgotten and left for dead. IME this is especially true for internal documentation, and the closest to the code the docs are, the less attention they receive - since higher level documentation is more likely to be consumed by people outside of the team.
With a README, I need to:
* remember to read it
* trust that it will have the information
* trust that the information is up-to-date
* finally, figure out paths to scripts, arguments and/or copy-paste commands
I think people like using makefile as a simple task runner because it's pretty much ubiquitous and also a kind of auto-descriptive standard. Interactive shells usually do autocompletion on makefile targets so it's easy to see what you can run on a project (more so on old or foreign projects)
This makefile does look simple to me, although it is not easy; but TFA never claimed it was supposed to be "easy".
The shell you mentioned is not in any way "simpler" nor even "easier". The same thing can be done with bash substitutions and loops (all supported by zsh), and someone would argue that it'd be simpler by virtue of not suffering e.g gnu vs bsd vs posix sed nor needing xargs; also, pipefail and such.
Also it doesn't do "the same thing": you have to be at a specific pwd and not in any subdir + you can't do a subset (e.g "make git")
Note I'm not saying it's better or worse.
I really like the article as it showcased a few advanced make features in a concrete and limited use case (symlinks). The result is simple to use and maintain.
I suppose I'm biased. I'm used metaprogramming it by now.
I'm very prone to being entranced by the eerily lisp-like nature of GNU Make. Got side tracked in one of my projects trying to recreate GNU autoconf inside it. That was the day I finally understood what autoconf was even doing.
> And if you introduce a new dotfile to the repo, you have to update the Makefile too.
Not at all. The rules are generic. I can give make any path inside my home directory and it will try to match it against an equivalent file in the repository.
$ make /home/matheus/.vimrc
ln -snf /home/matheus/.files/~/.vimrc /home/matheus/.vimrc
I only need to update the makefile if I want easy to use phony targets. These phony targets in turn simply depend on the paths to the real files which activate the generic rules I described in the article.
It looks complicated because I used functions to compute all these paths from the items in the repository. Here's what the final result looks like:
I could have used any of those paths and it would have worked. The phony targets are nice but not strictly needed.
The bulk of the makefile is dealing with environment variables such as XDG_*_HOME and GNUPGHOME variables which affect where the links are supposed to end up.
Adding to the sh implementation, `find -L "$HOME" -maxdepth 1 -type l -exec rm {} +` will clean up dead symlinks in your home directory, e.g., if a dotfile is deleted because it's not needed anymore.
reply