Silent failure on systems with Debian bash completion

[predakanga]

Background: I'm currently working to improve our developer experience by rolling herokuish into a Vagrant image, discovered this issue in the final steps.

Symptoms: When running herokuish procfile start web on a system with Debian's bash completion installed, herokuish exits silently with exit code 1

Trace: trace.txt

Diagnosis:
The problem occurs at procfile-load-profile, during the loading of bash completion. The problem occurs because bash completion and set -e are incompatible, as documented in this debian bug.
Ordinarily the bash completion doesn't run for interactive shells, but it detects interactivity by checking PS1 (i.e. if [ -n "$BASH_VERSION" -a -n "$PS1" -a -z "$BASH_COMPLETION_COMPAT_DIR" ]; then, which is expected behaviour as per bash's documentation), while herokuish sets it's own PS1 unconditionally.

Unfortunately I don't know what the best way to solve this is, otherwise I would provide a PR - does herokuish actually need to set that PS1? Should it only be set immediately prior to procfile-exec?

In the meantime I've modified the interactivity check in my VM, but that's not great long term.

[michaelshobbs]

It is my understanding that herokuish was never intended to be executed via anything other than the Ubuntu-based docker image distributed via Docker Hub here.

@progrium Feel free to chime in. Unless @progrium disagrees, this behavior will probably not change.

[progrium]

I could go either way. Herokuish was definitely made for an appliance container and customized versions of an appliance container, and anything outside of that is definitely questionable in terms of project scope and responsibility. I'm not sure I understand the involvement of set -e, but afaik PS1 doesn't *need* to be set in this way. If there's a minor change that can be done without breaking existing behavior, then I don't see a problem with it. But I'm not sure the majority of us would be committed to helping solve a problem outside the intended use case. That doesn't mean we'd not take a well tested PR with minimal changes to resolve it, though. Perhaps this should be explained in the README.

…

On Tue, Mar 14, 2017 at 10:53 AM, Michael Hobbs ***@***.***> wrote: It is my understanding that herokuish was never intended to be executed via anything other than the Ubuntu-based docker image distributed via Docker Hub here <https://hub.docker.com/r/gliderlabs/herokuish/>. @progrium <https://github.com/progrium> Feel free to chime in. Unless @progrium <https://github.com/progrium> disagrees, this behavior will probably not change. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#239 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAACh_mOp-x7SmzG7UWlVeSV7-xQV3B6ks5rlrfdgaJpZM4Mcncp> .

-- Jeff Lindsay http://progrium.com

[michaelshobbs]

I'm 👍 on a well test PR that solves this. README entry is also fine. @predakanga feel like taking either of those on?

[predakanga]

Certainly, I'll have a look and see what kind of test coverage is needed this afternoon - at a glance I think covering that PS1 is set during execution but not during profile load for all code paths should do the trick.