Hacker News Reader

Comment by hueving | Hacker News Reader

If you offer a cli with output reasonable to parse as a text stream, assume someone is going to script against it and don't change the args without detecting and warning on the old usage.

View on HN

I agree, but if a script is going to use the CLI then it's the script's responsibility to parse the prompts and not to blindly send strings to the program. `expect` exists since 1990, use it or reinvent it.

Can you go over some good ways to use expect to avoid this type of issue?

You simply use it to wait for the appropriate prompt before sending anything. If the expected prompt never arrives, something is wrong (CLI changed), so abort. The snippet for this particular case could be something like

    set timeout=1
    expect {
      "enter \"p\" for pre-configured paranoia mode"  { puts p\n }
      timeout     abort
      eof         abort
    }

Better yet, don't offer a CLI as the primary interface; provide a reasonable library to use instead.

Though, that only works for the language that you use. Other languages may opt to use the CLI as the API

Thinking a bit about this problem, I'm a bit torn

In one side, a CLI offers a "better" way of using the product (as with a library it's easier to misuse something)

On another, issues like this

(But I guess in this specific case the issue is that encfs is not doing a minimal validity check of the password being provided)

It would be good if CLIs would/could be more consistent, but in the Unix/Gnu options world, probably it won't

> In one side, a CLI offers a "better" way of using the product (as with a library it's easier to misuse something)

A CLI provides a better interactive interface, but a terrible programmatic interface.

Yes, it is awful in the programmatic sense, I don't want to assemble command lines by hand or parse error messages

It is nice in the conceptual sense, because it usually fits the common use cases

A CLI is usable by any language that can fork/exec and read/write IO. A library is more likely to be usable by only one language.

A C library, or a library with a C interface, is usable by any language with an FFI.

That's true in theory, but in practice most Ruby developers don't know how to use C or the FFI well enough to build a library out of a C or C++ library.

It's reasonable to shell out sometimes. It's what Github did when they were first starting. It's what 500px did when they were first starting. Trying to do everything the right way early on is just going to slow you down.

I think with security-related software in particular, the proper answer there is "tough". If you can't figure out how to call a C function, you should probably just not write critical software.

One of the important lessons that the profession has yet to fully internalize is that there is very little software that is NOT security-related.

It's very, very difficult to get product managers to internalize that there are real security restrictions on how they can enable users to make things pretty.

Almost everything is security-related. Almost nobody is willing to work with this.

OTOH, a C library will almost certainly be unsafe and insecure, while POSIX pipes can be secure.

Exactly what I had in mind when I said "or a library with a C interface".

(Someday, I hope we have a better cross-language ABI than C.)

expecially for a tool intended for those use cases as encfs.

its not up to the developer to guess all the wrong ways[1] users are using the software. such changes will be described in the changelog, I expect you read that if you are updating the software.

1. https://xkcd.com/1172/

It's worth noting that what is arguably the largest and most successful software project in history, Microsoft Windows, has succeeded in large part because of an obsession with maintaining backwards compatibility, even with the "wrong" ways of using the software.

AKA the unix philosophy.

Reply on news.ycombinator.com