Show HN: ppl - The Command Line Address Book | Hacker News Reader

Show HN: ppl - The Command Line Address Book

ppladdressbook.org

106 pointsh2s54 comments

This has been my side project for the last month or so. It's a "scratch your own itch" type of deal, because I wanted a CLI address book and there didn't seem to be one.

I tried really hard to find an existing one, but I'd be interested to hear if I messed up and accidentally reinvented the wheel.

I like it! Can't say I have much use for it, but it's nice.

There's abook[1], but yours seems different in design. (Main difference at a glance: Yours doesn't work on captured interface. So in that sense, yours is more Unixy.) One nice thing about abook is that it integrates nicely with mutt (which I see someone has already asked you about and you're working on).

One thing that might be nice would be an abook to ppl exporter. abook saves its information in a flat file at ~/.abook/addressbook with items like the following:

    # abook addressbook file
    
    [format]
    program=abook
    version=0.5.6
    
    
    [0]
    name=Someone Somewhere
    email=someone.somewhere@gmail.com
    
    [1]
    name=Another Person
    email=another_person@yahoo.com
    nick=Another
    
    [3]
    name=Detailed Somebody
    email=somebody@details.org
    address=2222 Main Street
    city=New Somewhere
    state=NY
    zip=10011
    phone=212-111-1111
    nick=person
    notes=Birthday May 14th

It shouldn't be too hard to convert that, but I'm not sure (yet) about how you're storing information. (You mention vcard, but I'm not familiar with the details of that.)

[1]: http://abook.sourceforge.net/

I entirely concur. abook is great, but I've always wanted something that worked a bit more like this project.

Great work!

You have described exactly the two things about abook that have always put me off using it and drove me to build this. The ncurses UI works well but isn't what I want, and the "Yet Another File Format" addressbook format isn't very interoperable.

You're right that an exporter shouldn't be hard to build. Might get on that once some bugs and other features are out of the way!

One issue that will come up with any exporter: abook can handle multiple entries for each category, and (I think?) ppl can't yet. So, at the moment, I'm not sure there's a way to export without losing some information. Anyhow, I will definitely keep an eye on ppl. Looks like a very good start.

awk script to convert abook to vcf vcard (found with a search, haven't tried it out)

http://blog.karssen.org/2010/05/24/script-that-converts-a-sq...

Looks great!

Reminds me of when I built Logbook - store notes on Gists from CLI. The mindset is amazingly the same :) Though I offloaded most of the CLI processing to Thor, and didn't build Command/CLI abstraction into it.

You might even find it useful: https://github.com/jondot/logbook

Damn, that is kind of spooky actually. I can't keep track of all the similarities... The layout of the project's directory structure, the TravisCI image placement, the README style...

I don't know, all I can say is you have excellent taste! :)

You too! :)

Does it sync with Google contacts/my phone?

No. See https://github.com/h2s/ppl/issues/5

The semantics of contact data exposed via the Contacts API is supposed to be quite close to vcard, which would make pushing data from Google Contacts to your Git vcard repository reasonably easy, but the other way could be hairy.

Thank you for this. abook had something not right about it. This seems to have made contact management in CLI simple an amazing.

Looks very cute, and might be useful (not having to leave the terminal is always good), but I think I speak for many others saying that I don't want to start a new address book from scratch, let alone one that won't sync into my other devices.

So my suggestion for the killer feature here is an ability to sync with some major service provider such as iCloud or Google (preferably both / some standard protocol?). I'd love to help the development of such a feature.

Very cool idea. It would probably be 100x more useful if it was easy to sync with other address books, I think I agree with you there. Perhaps this should be a priority. And any help you can give would be most welcome.

I think the reason I didn't find starting a new address book from scratch to be a problem for my own "itch" is that the previous non-existence of a CLI address book had always prevented me from building up any decent amount of data in any other place!

Cool, I'll open an issue on GitHub and I hope I'll have time to do some research for this over this weekend or the next one.

Nice work.

The page is giving me kind of cognitive dissonance, because it looks very startupy, and I would expect something about pricing, free plans, connection to facebook, or links to Android and iOS app store ... but this is an honest to god, desktop command line application.

Now I'm wondering why didn't I do this... The "address book" app is an equivalent of hello world for me when I'm starting to learn some language. I probably implemented some kind of address book in, like, 9 different languages (the first one in QBasic :)) now? All CLI driven, of course.

I guess I never had enough of contacts to put in there to notice its usefulness. Kind of sad, actually.

Of interest to me: split front-end and back-end, then interface with Contacts.app on Mac via AppleScript, whose dictionary of actions is similar but obtuse to use directly.

Agreed. I'd use this in an instant if it would read from my Mac Address Book which syncs w/ iCloud and all my devices (as well as corporate Exchange server)

Things I like are codename-per-contact and the fact that there's a command line tool supplied with exit codes.

I don't like almost everything else, including the syntax ('ppl phone alice 12345' feels icky and against-the-grain to me), the use of (slow?, and) dependency-heavy git, the redefinition of on-disk format, the lack of formal data-description, the lack of customization for such, trying to do more than one thing well (versioning/diffing/merging/branching = git's job, not yours... keep that out of scope), the lack of meaningful, nontrivial use cases. (What problem does this solve, in the real world, except your itch? If you'd included GPG key, included autopopulation support based on directory lookups or some mature script system, helped people migrate contacts off Gmail and in to private git-based cloud hosting with hooks to preload their FirefoxOS beta with privacy-enhanced contact solution, I would have been more impressed)

Why not do something different like 'ppl alice --phone=12345' (set) and 'ppl alice --phone' or 'ppl phone <alice' or 'ppl -f %phone <alice' (get). In general taking input via pipes is better than adding mandatory arguments.

Better yet, stuff the command line syntax thinking entirely for the moment and focus on JSON. Spec the JSON Schema instead of the interface to it, focusing on data, and how it might differ in different use cases / environments (eg. countries). Some argue that if you get your understanding of the data right, the program is right.

By way of contrast, right now I suspect a lot of the hassle of such a program is going to be things like (0) trying to do too many things, succeeding at none of them (1) yet another definition of what a phone number, address, etc. is that is not going to work for everyone (2) some developer second-guessing what i, the user, want or have to accept in terms of duplicate input, normalization, whitespace significance, etc. (3) non-i18n interface (4) let me smoke my unixpipe, dammit!

I dunno, I'm just playing devil's advocate, but there's probably some value in that rant.

An interface to mutt would be awesome. http://www.mutt.org/doc/manual/manual-4.html#ss4.5

Agreed, and this shouldn't be too difficult to do either. Watch this space: https://github.com/h2s/ppl/tree/mutt

Beat me to it; I was going to suggest exactly that. Keeping everything in one place, accessible via the shell, would be perfect, and this looks less awkward than maintaining a separate aliases file.

It's in! http://ppladdressbook.org/documentation/commands/mutt/

Thanks for the suggestion. The link was helpful because I could tell in moments how easy it would be to get started with this.

Is it me or was that some pretty fast turnaround? Kudos to you, sir.

Like others, I am impressed with this app and the fact it is written for the command line.

As the author is posting here: why using ruby, a language which seems to be missing from many Linux distributions and which needs to be installed. Why not C or Python or Perl? Present everywhere?

I thought about this a bit. I considered using C, but decided against it in the end.

C lost out because I wanted to use this project as an opportunity to try out full-on TDD, and C's automated testing tools seemed like a pain.

I also wanted to build something that I could release relatively quickly to validate the idea. Not to mention my eagerness to be able to use it for my own address book needs. I'm not very experienced with C so it probably would have taken me six months to get to this point instead of one.

As it stands, the main downside has been that I've encountered a lot of Rubygems-related woes resulting from the choice. Some earlier versions of Ruby are still very commonly installed on peoples' computers and don't work with ppl because they lack certain methods. I'd rather that than another five months of the app not even existing.

I wouldn't be averse to a C port, if the stars aligned just right so that it was both necessary and possible. For now I'm hoping Ruby will suffice!

It would probably be much easier to port to Perl or Python than to C. I think both Perl and Python are already installed on enough computers that no-one would have commented on the issue, unlike what happened with Ruby.

To search my adress book without leaving the keyboard I use Alfred app[1] ( on Mac ). It is a god send.

[1]http://www.alfredapp.com/

Nice - and not just for us CLI buffs. This would make a very good backend for a GUI address book application.

it seems like this could be generalised to arbitrary rdf triples in some way and used as an interface to a general graph of information. have you considered something like that? it seems like it would start to get complex when you need to distinguish between nodes with the same name...

For a short while I was using grep and a text file as an address book mostly because like this I could easily add in free form. The reason why I switched to a AddressBook.app and Google Contacts solution is the synchronization.

Very nice. But how would i get my existing contacts into ppl? Typing them all in would be a chore. An import function bout be quite neat to make a transition from other addressbooks feasible.

There seems to be no command for adding the contact's postal address.

Nope, not yet. But it's easy to add and will be in there soon enough. In fact it's already listed in the roadmap at http://ppladdressbook.org/development/roadmap/!

It's in now!

http://ppladdressbook.org/documentation/commands/post/

Anyone facing this issue? "ERROR: While executing gem ... (NoMethodError) undefined method `call' for nil:NilClass"

Nobody's reported this one yet! There's a bug tracker at https://github.com/h2s/ppl/issues/new if you're feeling generous with your time.

I could do with knowing what command you're running, what version of Ruby you're on, and whether you're running it inside an initialized address book repo.

Sorry about the bug by the way :(

Thanks! More than happy to try it out. :) I'll get the details in the bug tracker. Thanks again!

There are some way to access this data with any programming language? like phyton or ruby ? Very interesting..

The unique identifier should be optional (after all, people already have pretty unique-enough identifier).

Maybe too much, but how about a `txt` or `email` command to send short messages to contacts?

I don't get the 'decentralized' part.

Can I do a pull/push-like commands to a different repo from this app?

It uses git, so you can keep your address book on as many different computers as you want and use commands such as "git push" and "git pull" to handle the synchronisation.

There are no built in "ppl push" commands or anything like that at the moment. I was wary of tempting YAGNI and the inner platform effect until some valid use case becomes clear.

Really nice!

I can Create a remote repo on Dropbox and have a cloud based service :)

http://onethingwell.org/post/457674798/a-poor-mans-notationa...

You can do that easily enough with bash :-)

Very nice work, congrats on the release

looks awesome.. which bootstrap theme is this?

The URL of the bootstap CSS file indicates that it is flatstrap: http://littlesparkvt.com/flatstrap/

i did take a look at it, but they look quite different... has he customized flatstrap? or is it some out of the box theme? basically, where did 2.css come from?

Yeah I customised flatstrap (colors and fonts mainly).

2.css is part of the little CSS build process I came up with for this site. There are a bunch of LESS files in a directory (https://github.com/h2s/ppladdressbook.org/tree/master/_style...). Then there's a rake task to build them into {{site.version}}.css. This means I can update the CSS, bump the version number, run jekyll, and push the changes live being certain that there won't be any annoying caching issues stopping people from getting the updated CSS.

nice! n thanks..

very cool thing .. I will start using it

Reply on news.ycombinator.com