Hacker News Reader

Comment by gowld | Hacker News Reader

Android CLI can write a tool that wraps android-cli and automatically passes the flag based on an env variable.

How would Google have enough data about a brand new product without collecting that data?

> How would Google have enough data about a brand new product without collecting that data?

They wouldn't. But on the other hand, they probably have a large amount of in-house Android app developers on whom they can conduct such metrics collection. I wouldn't expect outsiders to have vastly different workflows, because when you get out of the happy path with Android all you get is pain.

Outsiders probably do have vastly different workflows. Google internally love to stick Bazel on everything and that's quite different (and overly complicated) compared to the usual Gradle route.

`alias android-cli='android-cli --no-metrics'`

Uh do aliases load in non-interactive shells?

You could export BASH_ENV to have Bash processes source a given file at startup.

Zsh has .zshenv, and Fish just has config.fish for everything with the ability to guard certain things within it to login only or non-interactive only.

Create a wrapping binary instead

    mkdir -p ~/.local/bin
    printf '#!/usr/bin/env sh\nexec android-cli --no-metrics "$@"' > ~/.local/bin/android-cli
    echo 'PATH="$HOME/.local/bin:$PATH"' >> ~/.zshenv

I'm pretty sure this will just call itself in a loop. You need to use the absolute path to the wrapped binary to distinguish it from the wrapper.

Also it's not a binary :-)

Aah! Yes absolutely right! Using `exec command android-cli` would work I believe

Nope. I have this alias (a default on my distribution) and it's no loop:

    alias ls='ls --color=auto'

Creating an alias is not the same as putting an executable in your $PATH.

That's true. So an alias won't do it if you use that tool from a script or something.

Reply on news.ycombinator.com