You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found this bin utility useful and wanted to use it inside Dockefiles, which meant that at no point can we drop to a TTY, the simplest way to circumvent user feedback is to allow explicit selection. This PR suggests a minimal addition required to allow for explicit command line selection as well as a use case in the .devcontainer added to the project. It is already being used, the PR is just in case the project maintainer find the added behavior desirable.
Note: The README was not updated, as it currently doesn't explain in detail all the options and switches, this oversight can be remedied on request.
There are 2 minor updates:
Introduction of BIN_EXE_DIR
Previously, the installation/download directory is derived from the PATH, when it's unable to do so, the bin utility
demands user feedback. In some cases it's useful to be able to shortcut this process and directly provide it with the installation directory using
the BIN_EXE_DIR
# install `navi` in a specific designated directory, update the bin configuration in the same directory
$ BIN_EXE_DIR=~/.local/bin bin install github.com/denisidoro/navi
Note: while the original bin utility allows for installation at a specific directory
# Explicit install @ ~/.local/bin
$ bin install github.com/denisidoro/navi ~/.local/bin
The behavior differs. Without BIN_EXE_DIR when the initial config is missing, the user will be requested to provide the installation directory.
Introduction of a command line file option selection (--select | -s )
In some cases the release may contain multiple files and user intervention is required to choose which one to install. The select option was introduced to allow
the user to specify the exact file to install even when it's inside an archive (tar, xz, etc).
SYNTAX:
bin install <URL> [ --select |-s FileName[:ContainedFile] ]
# Install the file yq_linux_amd64
$ bin install github.com/mikefarah/yq --select yq_linux_amd64
# Install broot selecting for the file x86_64-linux that is in the only tar ball existing in the release
$ bin install github.com/Canop/broot --select :x86_64-linux/broot
# Install the file age/age (age inside a directory with the same name) from the only tarball in the release
$ bin install github.com/filosottile/age -s :age/age
# Install btm file from the tarball bottom_x86_64-unknown-linux-gnu.tar.gz (select both the tarball and a file)
$ bin install github.com/ClementTsang/bottom -s bottom_x86_64-unknown-linux-gnu.tar.gz:btm
While it is possible to select partially, IMHO it defeats my original purpose of avoiding any TTY interaction, but why not?!
Does this also store the selection criteria in config.json, so that bin update --all would work without manually selecting the package? If it does, that would be a huge improvement!
I'm currently running a system with an old version of GLIBC which occasionally prevents me from using the gnu binaries (which I prefer over musl if they work). When I first install a package the first time, I first pick gnu, then go with musl if it doesn't work. Later when I run bin update --all, I've already forgotten which variant was the one that works and have to do this again.
@ristomatti Yes, the config.json is storing all required information for bin update --all to work automatically. btw, tagging me would make sure that a notification is sent to my email so I am aware of your query.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I found this
binutility useful and wanted to use it insideDockefiles, which meant that at no point can we drop to a TTY, the simplest way to circumvent user feedback is to allow explicit selection. This PR suggests a minimal addition required to allow for explicit command line selection as well as a use case in the.devcontaineradded to the project. It is already being used, the PR is just in case the project maintainer find the added behavior desirable.Note: The README was not updated, as it currently doesn't explain in detail all the options and switches, this oversight can be remedied on request.
There are 2 minor updates:
Previously, the installation/download directory is derived from the
PATH, when it's unable to do so, thebinutilitydemands user feedback. In some cases it's useful to be able to shortcut this process and directly provide it with the installation directory using
the
BIN_EXE_DIRNote: while the original
binutility allows for installation at a specific directoryThe behavior differs. Without
BIN_EXE_DIRwhen the initial config is missing, the user will be requested to provide the installation directory.In some cases the release may contain multiple files and user intervention is required to choose which one to install. The select option was introduced to allow
the user to specify the exact file to install even when it's inside an archive (tar, xz, etc).
While it is possible to select partially, IMHO it defeats my original purpose of avoiding any TTY interaction, but why not?!