Ble.sh: AUR package

[huresche]

Could the project be packaged for the Arch User Repository? A potential PKGBUILD could be:

pkgname='ble.sh-git'
_pkgname='ble.sh'
pkgver=1
pkgrel=1
pkgdesc="Command line editor for bash with syntax highlighting, autosuggestions, abbreviations, enhanced vi mode and more"
arch=('x86_64')
url="https://github.com/akinomyoga/ble.sh"
license=('custom:BSD 3-clause')
depends=()
makedepends=('git')
install=ble.install
source=("git+$url" "git+https://github.com/akinomyoga/blesh-contrib")
md5sums=('SKIP' 'SKIP')

prepare() {
    cd "${srcdir}/${_pkgname}"
    git submodule update --init --recursive
}

pkgver() {
    cd "${srcdir}/${_pkgname}"
    printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

package() {
    cd "${_pkgname}"
    make DESTDIR="$pkgdir/" PREFIX=/usr/ install
    install -Dm644 ./README.md "${pkgdir}/usr/share/doc/${_pkgname}/README"
    install -Dm644 ./README-ja_JP.md "${pkgdir}/usr/share/doc/${_pkgname}/README-ja_JP"
    install -Dm644 ./LICENSE.md "${pkgdir}/usr/share/licenses/${_pkgname}/LICENSE"
    install -Dm644 ./CONTRIBUTING.md "${pkgdir}/usr/share/doc/${_pkgname}/CONTRIBUTING"
    install -Dm644 ./note.txt "${pkgdir}/usr/share/doc/${_pkgname}/note.txt"
}

And a file ble.install:

post_install() {
    printf '\033[0;1;36mTo start using ble.sh, you can run \033[35m"source /usr/share/blesh/ble.sh"\n\033[0m'
    printf '\033[1;36mTo load ble.sh by default in interactive sessions reliably,\n\033[0m'
    printf '\033[1;36mYou can add this line at the top of your .bashrc:\n\033[0m'
    printf '\033[1;35m[[ $- == *i* ]] && source /usr/share/blesh/ble.sh --noattach\n\033[0m'
    printf '\033[1;36mAnd this line at the end of your .bashrc:\n\033[0m'
    printf '\033[1;35m[[ ${BLE_VERSION-} ]] && ble-attach\n\033[0m'
    printf '\033[1;36mDocumentation available at: \033[33m"https://github.com/akinomyoga/ble.sh/wiki\n\033[0m'
}

[akinomyoga]

Thank you for the suggestion! May I confirm that you are willing to become a (long-term) maintainer of the package? Or are you suggesting that I maintain a package in AUR?

[akinomyoga]

It seems there is already someone maintaining the package in AUR.

• AUR (en) - blesh-git (devel)
• AUR (en) - blesh (stable)

[huresche]

Oh I didn't realize that since it was submitted just a few weeks ago, no problem then!

[akinomyoga]

@oc1024 Oh, OK. It's you, the one maintaining the AUR packages. I remember you because we have just communicated in #97 a week ago :) Maybe you have some comments.

@huresche If you have any suggestion to the current PKGBUILD / blesh.install, maybe you can discuss it here. The current package contents are

PKGBUILD

# Maintainer: capezotte (******** ob ********)

pkgname=blesh-git
_pkgname=ble.sh
pkgdesc="A replacement for bash's line editor with advanced features"
pkgver=r1486.0506df2
pkgrel=1
license=(BSD)
url='https://github.com/akinomyoga/ble.sh'
depends=(bash)
makedepends=(bash awk make)
arch=(any)
source=('git+https://github.com/akinomyoga/ble.sh.git')
md5sums=('SKIP')
install=blesh.install

pkgver() {
  cd "$_pkgname"
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

prepare() {
  cd "$_pkgname"
  git submodule init
}

package() {
  cd "$_pkgname"
  make install DESTDIR="$pkgdir" PREFIX=/usr
}

blesh.install

post_install() {
        echo '==> Remember to enable ble.sh in your .bashrc'
        echo '==> (add the following line):'
        echo '[[ $- == *i* ]] && . /usr/share/blesh/ble.sh'
}

---

Comparing two versions,

• We may add blesh-contrib in source?
• We may prefix the version name in pkgver. I'm not good at the package version convention in AUR, but according to VCS package guidelines - ArchWiki, it seems we should include it. How about

pkgver() {
  cd "$_pkgname"
  printf "%s.r%s.%s" \
    "$(sed -n 's/-/_/g;s/^FULLVER[[:space:]]*:=[[:space:]]*//p' GNUmakefile)" \
    "$(git rev-list --count HEAD)" \
    "$(git rev-parse --short HEAD)"
}

• I think I need to include README, LICENSE, CONTRIBUTING in the process of make install. I'll do that after the discussion.
• For the instruction in post_install, I think the one by @huresche is better than the one by @oc1024.
• I think ble-update doesn't work in this case. Maybe I can add some code to instead call some package manager when ble.sh is installed by some package systems. Or, maybe I think I should add a way to update ble.sh without entering a ble.sh session. What do you think?

[oc1024]

Currently making some changes to the PKGBUILD to align with these suggestions. What i've got so far:

PKGBUILD

# Maintainer: capezotte ([...])
# Contributor: Seto (Github: huresche)
# Contributor: Koichi Murase (Github: akinomyoga)

pkgname=blesh-git
_pkgname=ble.sh
pkgdesc="A replacement for bash's line editor with advanced features"
pkgver=0.4.0_devel3.r1507.750ca38
pkgrel=1
license=(BSD)
url='https://github.com/akinomyoga/ble.sh'
depends=(bash)
makedepends=(bash awk make git)
arch=(any)
source=("git+$url" "git+${url/.sh/sh-contrib}")
md5sums=('SKIP' 'SKIP')
install=blesh.install

pkgver() {
    cd "$_pkgname"
    printf "%s.r%s.%s" \
        "$(sed -n 's/-/_/g;s/^FULLVER[[:space:]]*:=[[:space:]]*//p' GNUmakefile)" \
        "$(git rev-list --count HEAD)" \
        "$(git rev-parse --short HEAD)"
}

prepare() {
    cd "$_pkgname"
    git submodule update --init --recursive
}

package() {
    cd "$_pkgname"
    make install DESTDIR="$pkgdir" PREFIX=/usr
}

blesh.install

post_install() {
    printf '\033[0;1;36m==> To start using ble.sh, you can run \033[35m"source /usr/share/blesh/ble.sh"\n\033[0m'
    printf '\033[1;36m==> To load ble.sh by default in interactive sessions reliably,\n\033[0m'
    printf '\033[1;36m==> Add these lines at the top of your .bashrc:\n\033[0m'
    printf '\033[1;35m[[ $- == *i* ]] && source /usr/share/blesh/ble.sh --noattach\n\033[0m'
    printf '\033[1;35m[[ ${BLE_VERSION-} ]] && ble-attach\n\033[0m'
    printf '\033[1;36m==> Documentation available at: \033[33mhttps://github.com/akinomyoga/ble.sh/wiki\n\033[0m'
}

I think I need to include README, LICENSE, CONTRIBUTING in the process of make install. I'll do that after the discussion.

So, I don't need add these to the package function, correct?

I think ble-update doesn't work in this case. Maybe I can add some code to instead call some package manager when ble.sh is installed by some package systems.

Given the AUR build process is basically git clone https://aur.archlinux.org/package.git && cd package && makepkg -fsi, I think this could easily fit, with two caveats:

• should cd into a user-writable directory for building the package (many AUR helpers use .cache)
• the function would grow in size if there is demand to support more distributions.
• I'm a third-party (and so would be many maintainers for ble.sh packages).

[akinomyoga]

Thank you for the quick work!

I think I need to include README, LICENSE, CONTRIBUTING in the process of make install. I'll do that after the discussion.

So, I don't need add these to the package function, correct?

Correct.

Given the AUR build process is basically git clone https://aur.archlinux.org/package.git && cd package && makepkg -fsi, I think this could easily fit, with two caveats:

• should cd into a user-writable directory for building the package (many AUR helpers use .cache)

I think that is the problem. Currently, one needs to call ble-update in the session with sudo privilege to finally write to /usr/share/*. But if we can identify the package system, I think I can take care of them.

• the function would grow in size if there is demand to support more distributions.

I don't care the size of the function as ble.sh is already a very large script.

I think if we will add a specialized updating code for each package system, we need to identify the package system that was used in installing the currently-used ble.sh. For that purpose, I think I need to add a Makefile variable PACKAGE_TYPE or something. Then we can write

package() {
    cd "$_pkgname"
    make install DESTDIR="$pkgdir" PREFIX=/usr PACKAGE_TYPE=AUR
}

Or is there any other way to detect the package system in the installing process?

• I'm a third-party (and so would be many maintainers for ble.sh packages).

May I put in README the link to the pages of the AUR packages so that other people know that there are already existing packages on AUR?

[oc1024]

Or is there any other way to detect the package system in the installing process?

{ type -P pacman && type -P makepkg; } &>/dev/null and equivalents in other distributions came to mind, but I think a variable would ultimately be more reliable.

This would also allow official distribution maintainers to specify a "Notify us if the package is out-of-date" quote-unquote "package type".

Come to think of it, it could source a script supplied by the maintainer if it can't write to the */share/blesh directory (for example, the one-liner in my comment, or package-manager update && package-manager install ble.sh for official packages.

May I put in README the link to the pages of the AUR packages so that other people know that there are already existing packages on AUR?

Sure.

[akinomyoga]

This would also allow official distribution maintainers to specify a "Notify us if the package is out-of-date" quote-unquote "package type".

Maybe I don't correctly get the meaning. What are you specifically thinking about? For example, adding a message provided by the package maintainer in the output of bash ble.sh --help or bash ble.sh --version?

Come to think of it, it could source a script supplied by the maintainer if it can't write to the */share/blesh directory (for example, the one-liner in my comment, or package-manager update && package-manager install ble.sh for official packages.

Ah, that is a good idea!!

I have locally implemented that idea (pushed a stub commit 6caf353 to stub-update branch). The current behavior is something like this: If the maintainer put an additional file /usr/share/blesh/lib/_package.sh, ble.sh sources that file in the initialization process. This script file can be written like

# lib/_package.sh

_ble_base_package_type=AUR

function ble/base/package:AUR/update {
  update-the-package-in-a-proper-way
  return 0
}

If the function ble/base/package:"$_ble_base_package_type"/update is detected when ble-update is called, ble-update just calls the function. If the exit status of the function is 125, ble-update attempts the default updating procedure. Otherwise, ble-update exits with the exit status of ble/base/package:.../update.

In the stub commit 6caf353, I also supported bash ble.sh --update to enable updating ble.sh without entering the ble.sh session. I also added codes to automatically switch to sudo bash ble.sh --update or sudo make install when the target repository or the install directory is not writable.

May I put in README the link to the pages of the AUR packages so that other people know that there are already existing packages on AUR?

Sure.

Thank you. Can I include your GitHub account name @oc1024 as a maintainer?

[oc1024]

Maybe I don't correctly get the meaning. What are you specifically thinking about?

If you were to be _the_ one maintaing variations of ble-update (and package maintainers would come and make PRs to add support for their distribution), I'd propose a package type "NOTIFYUS"/"OTHER" in case they haven't had the time to contact you to add the needed code for updating within ble.sh.

stub-update branch

Currently experimenting with a PKGBUILD for this.

Question: Are we supposed to call ble-reload from within the update function?
Both a no-op consisting of return 0, and my actual update function (that calls a lot of programs and ends with return "$?") don't trigger a reload (even when the last command exits successfully).

Thank you. Can I include your GitHub account name @oc1024 as a maintainer?

I mean, I only wrote a shell script that installs ble.sh for Arch Linux users and reported a bug. It'd be an honor, but I'm definitively not on the same league as people who have contributed performance improvements or (actual code for) bugfixes.

[akinomyoga]

If you were to be _the_ one maintaing variations of ble-update (and package maintainers would come and make PRs to add support for their distribution), I'd propose a package type "NOTIFYUS"/"OTHER" in case they haven't had the time to contact you to add the needed code for updating within ble.sh.

Oh, I see. Thank you for the clarification. I think now I should discard the idea of PACKAGE_TYPE in Makefile because now, as your suggestion, we can load lib/_package.sh so that package maintainers can freely add custom updating code without asking me.

stub-update branch

Currently experimenting with a PKGBUILD for this.

Question: Are we supposed to call ble-reload from within the update function?
Both a no-op consisting of return 0, and my actual update function (that calls a lot of programs and ends with return "$?") don't trigger a reload (even when the last command exits successfully).

OK, that is a good point. Thank you. I was naively thinking that one can implement everything in the custom function, but it is more useful to automatically reload ble.sh by the caller side (ble-update). I added a fix 9f1a2f9
[ Edit: ble/base/package:.../update can now return the exit status 0 when the update has been successfully done, 6 when the installed ble.sh was already up to date, 125 when it requires the default updating sequence implemented in ble-update, or other values when the update has failed. ]

Thank you. Can I include your GitHub account name @oc1024 as a maintainer?

I mean, I only wrote a shell script that installs ble.sh for Arch Linux users and reported a bug. It'd be an honor, but I'm definitively not on the same league as people who have contributed performance improvements or (actual code for) bugfixes.

Sorry for my confusing writing. I'm just thinking of adding the name next to the link to AUR. Actually, I have already included your account name in the stub-update (this line). If there is any problem, I will remove it before I push it to the master.

Anyway, as I'm not a regular Arch user, so maybe, if needed, I will ask for your help when I receive some reports from the users who installed ble.sh through AUR. Of course, you don't have to respond to them if you are busy or would be no more interested in ble.sh, but if you could help me in such cases, it would be important future contributions.

[akinomyoga]

Sorry there was a trivial mistake in the stub-update. I have updated it b17b20f.

[oc1024]

Funny, I was about to comment about a Syntax error near unexpected token } as you posted that comment.

Sorry for my confusing writing. I'm just thinking of adding the name next to the link to AUR. Actually, I have already included your account name in the stub-update (this line). If there is any problem, I will remove it before I push it to the master.
[...]
Anyway, as I'm not a regular Arch user, so maybe, if needed, I will ask for your help when I receive some reports from the users who installed ble.sh through AUR.

All right.

I think now I should discard the idea of PACKAGE_TYPE in Makefile because now, as your suggestion, we can load lib/_package.sh so that package maintainers can freely add custom updating code without asking me.

Agreed.

---

Final question: does ble.sh require GNU awk at runtime, or can it run with POSIX awk after it's built? The current stable AUR package fetches the pre-built tarball from the Releases section and copies it to /usr/share, and currently lists plain awk as a dependency.

[akinomyoga]

OK! Thank you!

Final question: does ble.sh require GNU awk at runtime, or can it run with POSIX awk after it's built?

It doesn't require GNU awk on the runtime. It just requires gawk in compiling time. It's tested with gawk, mawk, and nawk (and also Solaris XPG4 awk which is a buggy implementation of POSIX awk...). Actually, if ble.sh detects nawk (which is faster than gawk), ble.sh currently prefers to use nawk over gawk. So it's fine not to include gawk in dependencies.

[oc1024]

Seem the update part is (almost?) done. I'll update the blesh-git package when stub-update is merged.

[akinomyoga]

OK! Thank you! I squashed and merged it into the master 0bc2660!

[akinomyoga]

@oc1024 @huresche If there is no further discussions, can I close this issue?

By the way, I suggest changing the variables PRE_VERSION and POST_VERSION to local variables (See the attached patch 1 below).

• 0001-blesh-update.sh-make-the-variables-PRE-POST-_VERSION.patch

Maybe you can also consider the other changes in patch 2 although they are just cosmetic ones that don't change any behavior. (1) \s is not in POSIX, but GNU-sed extension. But, I think this is not a problem because sed is GNU sed in Arch Linux. (2) The variable names can be actually directly written in arithmetic expressions such as ((helper_exit != 0)).

• 0002-blesh-update.sh-add-cosmetic-changes.patch

[huresche]

Hello, sorry for not following up. Regarding the current _package.sh, we may add aurman to the loop, and in case the AUR helper is 'aura', the command should be -Ax for synchronizing AUR packages and showing progress bars; and for those with multiple helpers we may prompt them for confirmation, maybe something like this:

    #Check for common AUR helpers
    for helper in yay paru pacaur pikaur pakku aura yaourt aurman; do
    type -P &>/dev/null "$helper" && {
        echo "Found helper: $helper"
        read -p "Syncronize with $helper? (Y|N) " ANS
        case "$ANS" in
            (''|y|Y) 
                case "$helper" in 
                    (aura) exec "$helper" -Ax $PKGNAME;;
                    (*) exec "$helper" -S "$PKGNAME";;
                esac ;;
            (n|N) echo -e "Searching for another AUR helper...\n";;
        esac
    }
    done

One question, so if the package was build from the PKGBUILD and since upgrading would be delegated to the AUR helper, the _ble_base_repository variable would not longer be relevant right? I'm asking since I noticed that with the 'yay' helper that directory 'src' wouldn't exist in ~/.cache/yay/blesh-git/src/ble.sh (not the case with some other helpers); but it wouldn't conflict with anything right?

Otherwise, the PKGBUILD builds fine (although I haven't tried upgrading yet) and the patches are fine too

[akinomyoga]

Hello, sorry for not following up. Regarding the current _package.sh, we may add aurman to the loop, and in case the AUR helper is 'aura', the command should be -Ax for synchronizing AUR packages and showing progress bars;

Thank you for the suggestion. Let's add aura.

and for those with multiple helpers we may prompt them for confirmation, maybe something like this:

Nice idea! Furthermore, how about first making a list of available AUR helpers and then letting the user select from the list? I haven't tested it but something like [Edit: updated for trizen and fixed for aura after [#108 (comment from @huresche)](https://github.com/akinomyoga/ble.sh/issues/108#issuecomment-845611512)]

(
  # Check for common AUR helpers
  local -a available=()
  for helper in yay paru pacaur pikaur pakku aura yaourt aurman trizen; do
    ble/bin#has "$helper" && ble/array#push available "$helper"
  done

  if ((${#available[@]})); then
    ble/array#push available makepkg
    local PS3='Which AUR helper do you use? '
    select helper in "${available[@]}"; do
      case ${helper:=$REPLY} in
      (yay | paru | pacaur | pikaur | pakku | yaourt | aurman | trizen)
        ble/util/print >&2 "Selected helper: $helper"
        exec "$helper" -S "$PKGNAME"
        break ;;
      (aura)
        exec "$helper" -Ax "$PKGNAME"
        break ;;
      (makepkg)
        exit 1 ;;
      esac
    done
    # Did not exec into a helper
    ble/util/print >&2 'AUR helper failed.'
    exit 1
  else
    ble/util/print >&2 'AUR helper not found.'
    exit 1
  fi
)

One question, so if the package was build from the PKGBUILD and since upgrading would be delegated to the AUR helper, the _ble_base_repository variable would not longer be relevant right?

Right.

I'm asking since I noticed that with the 'yay' helper that directory 'src' wouldn't exist in ~/.cache/yay/blesh-git/src/ble.sh (not the case with some other helpers); but it wouldn't conflict with anything right?

Right. This variable is used when there is no custom updater from _package.sh or when _package.sh requested ble.sh's default updater (by returning 125). In that case, ble.sh uses the directory only when the directory remains. If it doesn't exist anymore, it just tries to newly clone the repository into the current ble.sh's location (i.e., the installed path $_ble_base) from GitHub.

[huresche]

I tested it and builds fine! One more helper that I forgot is 'trizen':

...
 for helper in yay paru pacaur pikaur pakku aura yaourt aurman trizen; do
    ble/bin#has "$helper" && ble/array#push available "$helper"
  done
...

And the one with -Ax is 'aura'

...
case ${helper:=$REPLY} in
(yay | paru | pacaur | pkaur | pakku | aurman | yaourt | trizen)
    ble/util/print >&2 "Selected helper: $helper"
    exec "$helper" -S "$PKGNAME"
    break ;;
(aura)
    exec sudo "$helper" -Ax "$PKGNAME"
    break ;;
(makepkg)
    exit 1 ;;
esac
...

And that should be it

[akinomyoga]

Thank you! I have updated the code in my previous comment.

[akinomyoga]

the _ble_base_repository variable would not longer be relevant right? I'm asking since I noticed that with the 'yay' helper that directory 'src' wouldn't exist in ~/.cache/yay/blesh-git/src/ble.sh (not the case with some other helpers); but it wouldn't conflict with anything right?

It's just a naive idea, but maybe it is in principle possible to abuse _ble_base_repository in order to detect which AUR helper was previously used in installing or updating ble.sh.

[huresche]

Actually they should all have a directory with their names where they clone packages in subdirectories, I tried with different helpers and these are the values:
~/.cache/paru/clone/blesh-git/
~/.cache/yay/blesh-git/
~/.config/trizen/sources/blesh-git/
~/.cache/pikaur/build/blesh-git/
/var/cache/aura/vcs/blesh-git/blesh-git/
/tmp/pakku-_${USER}_/blesh-git/
So yeah, maybe something like [[ "$_ble_base_repository" == *"$helper"* ]] && "$helper" -S "$PKGNAME" could be better, or at least to find a default helper to do the upgrade.
Also this reminded me that 'aura' actually has to be run as root, so we shall prefix "sudo" there

[oc1024]

Here's how blesh-update.sh is looking so far.

I had earlier some code that checked the length of an array generated by mapfile -t helpers < <(type -P yay paru trizen ...), and only asked for a selection if more than one was found, but I guess @akinomyoga's solution is better since it always gives makepkg as an option (I think "built-in" fits better, though).

I fixed the local part (thanks for pointing it out) and made most of the cosmetic changes in patch 2 (except for [ → [[, since [ has a cleaner trace when set -x is active).

@huresche If I'm not asking too much, can you see the exit codes of AUR helpers when you say "No" to the installation of the built package? I'm trying to find an "unused" exit code specifically for triggering the built-in helper.

EDIT: just paid more attention to the output and ble/util/print doesn't join arguments like echo does.

#!/bin/bash
# Maintainer: capezotte
# Contributor: Seto (huresche at github)
# Contributor: Koichi Murase (akinomyoga at Github)

_ble_base_package_type=AUR

function ble/base/package:AUR/version_check {
     LC_ALL=C pacman -Qi blesh-git | sed -n 's/^Version[[:space:]]*:[[:space:]]*//p'
}

function ble/base/package:AUR/update {
    local PKGNAME="blesh-git"
    local PRE_VERSION POST_VERSION
    PRE_VERSION="$(ble/base/package:AUR/version_check)"
    # Try to use an AUR helper
    local helper_exit
    (
        # Check for common AUR helpers
        local -a available=()
        for helper in yay paru pacaur pikaur pakku aura yaourt aurman trizen; do
            ble/bin#has "$helper" && ble/array#push available "$helper"
        done

        if ((${#available[@]})); then
            ble/array#push available built-in
            local PS3='Which AUR helper do you use? '
            select helper in "${available[@]}"; do
                case ${helper:=$REPLY} in
                (yay|paru|pacaur|pikaur|pakku|yaourt|aurman|trizen)
                    ble/util/print "Selected helper: $helper"
                    exec "$helper" -S "$PKGNAME"
                    break ;;
                (aura)
                    exec sudo "$helper" -Ax "$PKGNAME"
                    break ;;
                (built-in)
                    ble/util/print 'Using built-in AUR helper.'
                    exit 3 ;;
                esac
            done
            # Did not exec into a helper
            ble/util/print >&2 'AUR helper failed.'
            exit 1
        else
            ble/util/print >&2 'AUR helper not found, using built-in.'
            exit 3
        fi
    )
    helper_exit="$?"

    # Hope this exit code isn't used by "No" in some AUR helper
    local makepkg_exit
    if ((helper_exit == 3)); then
        # Try to build from scratch
        (
            ble/util/print >&2 'AUR helper failed or not found.'
            LOCALR="$HOME/.cache/blesh-update"
            ble/util/print "Trying set up a build environment at $LOCALR"
            AURREPO="https://aur.archlinux.org/${PKGNAME}.git"

            set -ex
            [[ -w "${LOCALR%/*}" ]]
            mkdir -p "$LOCALR" && cd "$LOCALR"
            git clone "$AURREPO" || [ "$(cd "$PKGNAME" && git remote get-url origin)" = "$AURREPO" ]
            cd "$PKGNAME"
            git pull
            exec makepkg -fsi
        )
        makepkg_exit="$?"
    else
        makepkg_exit="$helper_exit"
    fi

    POST_VERSION="$(ble/base/package:AUR/version_check)"

    # TODO: make AUR helpers not build already up-to-date packages:
    # (could be used to check for makepkg (1) exit code 13)
    # [ "$makepkg_exit" -eq 13 ] && return 6
    if ((makepkg_exit==0)); then
        [ "$PRE_VERSION" = "$POST_VERSION" ] && return 6
        return 0
    fi
    # Just return 1 if we reached this point
    return 1
}

[akinomyoga]

Thank you for your work!

since [ has a cleaner trace when set -x is active

Oh, I see. I didn't know that. Thank you.

EDIT: just paid more attention to the output and ble/util/print doesn't join arguments like echo does.

Ah, yes. Initially, ble/util/print had joined the arguments, but I changed it to only use the first argument after I noticed that the previous implementation causes a problem when the user sets IFS to a custom value. I also think it is a good practice to join the arguments on the caller side.

---

 #!/bin/bash
 # Maintainer: capezotte
-# Contributor: Seto (huresche at github)
-# Contributor: Koichi Murase (akinomyoga at Github)
+# Contributor: Seto (huresche at GitHub)
+# Contributor: Koichi Murase (akinomyoga at GitHub)

This is a minor point, but I noticed a variation of github vs Github. How about unifying them to GitHub (made H uppercase)?

@@ -54,16 +54,15 @@ function ble/base/package:AUR/update {
   if ((helper_exit == 3)); then
     # Try to build from scratch
     (
-      ble/util/print >&2 'AUR helper failed or not found.'
-      LOCALR="$HOME/.cache/blesh-update"
+      LOCALR="$HOME/.cache/blesh/package"
       ble/util/print 'Trying set up a build environment at' "$LOCALR"
       AURREPO="https://aur.archlinux.org/${PKGNAME}.git"

We have already output the "failed" or "not found" message so we can now omit the message here. Also, what would you think about moving the directory into $HOME/.cache/blesh? Actually, ble.sh already uses the cache directory $HOME/.cache/blesh when a certain condition is met, so I think it is useful to put everything related to ble.sh together in a single directory.

       set -ex
       [[ -w "${LOCALR%/*}" ]]
-      mkdir -p "$LOCALR" && cd "$LOCALR"
-      git clone "$AURREPO" || [ "$(cd "$PKGNAME" && git remote get-url origin)" = "$AURREPO" ]
-      cd "$PKGNAME"
+      mkdir -p "$LOCALR" && builtin cd "$LOCALR"
+      git clone "$AURREPO" || [ "$(builtin cd "$PKGNAME" && git remote get-url origin)" = "$AURREPO" ]
+      builtin cd "$PKGNAME"
       git pull
       exec makepkg -fsi
     )

Can you replace cd with builtin cd? It is fairly common to replace cd with an alias or a function for interactive uses, which will mess up the set -x outputs.

---

So yeah, maybe something like [[ "$_ble_base_repository" == *"$helper"* ]] && "$helper" -S "$PKGNAME" could be better, or at least to find a default helper to do the upgrade.

I tried to implement it. I initially thought about using the detected default helper when the user just presses Enter with an empty string, but it turned out that select doesn't accept an empty string as user input.

• user input - bash: choose default from case when enter is pressed in a "select" prompt - Stack Overflow
• Bash select built-in defaults

I played around and decided to interpret d as the default helper. I have also added an option x for canceling the update.

@@ -18,14 +18,29 @@ function ble/base/package:AUR/update {
   (
     # Check for common AUR helpers
     local -a available=()
+    local default_helper=
     for helper in yay paru pacaur pikaur pakku aura yaourt aurman trizen; do
-      ble/bin#has "$helper" && ble/array#push available "$helper"
+      ble/bin#has "$helper" || continue
+      ble/array#push available "$helper"
+      [[ ! $default_helper && $_ble_base_repository == */"$helper"* ]] || default_helper=$helper
     done

     if ((${#available[@]})); then
       ble/array#push available built-in
-      local PS3='Which AUR helper do you use? '
+      if [[ $default_helper ]]; then
+        # Bring the default to the beginning of the list
+        ble/array#remove available "$default_helper"
+        ble/array#unshift available "$default_helper"
+      fi
+      local PS3="Which AUR helper do you use [${default_helper:+d: $default_helper (default), }x: cancel]? "
       select helper in "${available[@]}"; do
+        case $REPLY in
+        (d|default)
+          REPLY=$default_helper ;;
+        (x|exit|cancel)
+          ble/util/print >&2 'Canceled by the user.'
+          exit 1 ;;
+        esac
+
         case ${helper:=$REPLY} in
         (yay|paru|pacaur|pikaur|pakku|yaourt|aurman|trizen)
           ble/util/print >&2 "Selected helper: $helper"

[oc1024]

This is a minor point, but I noticed a variation of github vs Github. How about unifying them to GitHub (made H uppercase)?

Alright, also standardized the PKGBUILD on that.

[[ ! $default_helper && $_ble_base_repository == */"$helper"* ]] || default_helper=$helper

I think you meant, && default_helper? At least, I'm getting unexpected results with it (for example, my $_ble_base_directory doesn't have the name of any helpers, yet I'm getting one, while && yields the expected behavior.

builtin cd ; + LOCALR="$HOME/.cache/blesh/package"

Also implemented.

I noticed picking aura as an option would not show the Selected helper message, so I've made it (and any other root-needing AUR helper) a case with fall-through.

#!/bin/bash
# Maintainer: capezotte
# Contributor: Seto (huresche at GitHub)
# Contributor: Koichi Murase (akinomyoga at GitHub)

_ble_base_package_type=AUR

function ble/base/package:AUR/version_check {
     LC_ALL=C pacman -Qi blesh-git | sed -n 's/^Version[[:space:]]*:[[:space:]]*//p'
}

function ble/base/package:AUR/update {
    local PKGNAME="blesh-git"
    local PRE_VERSION POST_VERSION NEEDS_ROOT
    PRE_VERSION="$(ble/base/package:AUR/version_check)"
    # Try to use an AUR helper
    local helper_exit
    (
        # Check for common AUR helpers
        local -a available=()
        for helper in yay paru pacaur pikaur pakku aura yaourt aurman trizen; do
            ble/bin#has "$helper" || continue
            ble/array#push available "$helper"
            [[ ! $default_helper && $_ble_base_repository == */"$helper"* ]] && default_helper=$helper
        done

        if ((${#available[@]})); then
            ble/array#push available built-in
            if [[ $default_helper ]]; then
                # Bring the default to the beginning of the list
                ble/array#remove available "$default_helper"
                ble/array#unshift available "$default_helper"
            fi
            local PS3="Which AUR helper do you use? [${default_helper:+d: $default_helper (default), }x: cancel]? "
            select helper in "${available[@]}"; do
                case $REPLY in
                ([dD]|default)
                    REPLY=$default_helper ;;
                ([xX]|exit|[cC]|cancel)
                    ble/util/print >&2 'Canceled by the user.'
                    exit 1 ;;
                esac
                case ${helper:=$REPLY} in
                (aura)
                    NEEDS_ROOT=1 ;&
                (aura|yay|paru|pacaur|pikaur|pakku|yaourt|aurman|trizen)
                    ble/util/print "Selected helper: $helper"
                    exec ${NEEDS_ROOT+sudo} "$helper" -S "$PKGNAME"
                    break ;;
                (built-in)
                    ble/util/print 'Using built-in AUR helper.'
                    exit 3 ;;
                esac
            done
            # Did not exec into a helper
            ble/util/print >&2 'AUR helper failed.'
            exit 1
        else
            ble/util/print >&2 'AUR helper not found, using built-in.'
            exit 3
        fi
    )
    helper_exit="$?"

    # Hope this exit code isn't used by "No" in some AUR helper
    local makepkg_exit
    if ((helper_exit == 3)); then
        # Try to build from scratch
        (
            LOCALR="$HOME/.cache/blesh/package"
            ble/util/print "Trying set up a build environment at $LOCALR"
            AURREPO="https://aur.archlinux.org/${PKGNAME}.git"

            set -ex
            [[ -w "${LOCALR%/*}" ]]
            mkdir -p "$LOCALR" && builtin cd "$LOCALR"
            git clone "$AURREPO" || [ "$(cd "$PKGNAME" && git remote get-url origin)" = "$AURREPO" ]
            builtin cd "$PKGNAME"
            git pull
            exec makepkg -fsi
        )
        makepkg_exit="$?"
    else
        makepkg_exit="$helper_exit"
    fi

    POST_VERSION="$(ble/base/package:AUR/version_check)"

    # TODO: make AUR helpers not build already up-to-date packages:
    # (could be used to check for makepkg (1) exit code 13)
    # [ "$makepkg_exit" -eq 13 ] && return 6
    if ((makepkg_exit==0)); then
        [ "$PRE_VERSION" = "$POST_VERSION" ] && return 6
        return 0
    fi
    # Just return 1 if we reached this point
    return 1
}

Possible version using a single case statement? (was thinking of using [xX]*|?[xX]*|[cC]* in the last pattern, but that'd be very harsh on possible typos).

select helper in "${available[@]}"; do
    # Check if default was set 
    [[ $REPLY = [dD]* ]] && : ${helper:=$default_helper} || : ${helper:=$REPLY}
    case $helper in
    (aura)
        NEEDS_ROOT=1 ;&
    (yay|paru|pacaur|pikaur|pakku|yaourt|aurman|trizen)
        ble/util/print "Selected helper: $helper"
        exec ${NEEDS_ROOT+sudo} "$helper" -S "$PKGNAME"
        break ;;
    (built-in)
        ble/util/print 'Using built-in AUR helper.'
        exit 3 ;;
    ([xX]|[cC]|exit|cancel)
        ble/util/print >&2 'Canceled by the user.'
        exit 1 ;;
    esac
done

[akinomyoga]

Thank you for the updates!

[[ ! $default_helper && $_ble_base_repository == */"$helper"* ]] || default_helper=$helper

I think you meant, && default_helper? At least, I'm getting unexpected results with it (for example, my $_ble_base_directory doesn't have the name of any helpers, yet I'm getting one, while && yields the expected behavior.

Oh, you're right! Thank you!

I noticed picking aura as an option would not show the Selected helper message, so I've made it (and any other root-needing AUR helper) a case with fall-through.

Actually, ble.sh supports bash-3.0+ where ;& isn't supported. (This is one of the reason why I define a function ble/array#push instead of directly using arr+=(elements).) It is optional whether the AUR package supports lower version of Bash, but if it is not too hard, could you take care of the lower versions? Also, according to @huresche, the install command of aura isn't aura -S "$PKGNAME" but aura -Ax "$PKGNAME".

---

- local PRE_VERSION POST_VERSION NEEDS_ROOT
+ local PRE_VERSION POST_VERSION NEEDS_ROOT=

It is better to explicitly initialize NEEDS_ROOT with an empty value. When shopt -s localvar_inherit is set by a user, local NEEDS_ROOT will pick up the value of NEEDS_ROOT defined outside the function so isn't ensured to be an empty string.

Edit: Please also initialize default_helper with an empty string for the same reason.

Possible version using a single case statement?

You can choose either one as you like!

select helper in "${available[@]}"; do
  # Check if default was set 
  [[ $REPLY = [dD]* ]] && : ${helper:=$default_helper} || : ${helper:=$REPLY}

If you use the above line, could you quote the arguments of : builtin as : "${helper:=...}"? This is because they are subject to the pathname expansions and will fail when shopt -s failglob is set by a user and REPLY contains one of []*? (or \ in Bash 5.0). I once have shot myself in the foot for this one. Anyway, it is good to make it a rule to always quote the arguments of normal commands (i.e., except for [[ ... ]]).

Edit: Or, you can actually write like

```bash
[[ ${helper:=$REPLY} == [dD]* ]] && helper=$default_helper
````

(was thinking of using [xX]*|?[xX]*|[cC]* in the last pattern, but that'd be very harsh on possible typos).

Could you explicitly check that $REPLY is [dD] or default? I personally would like to reject other strings, such as dnf (Fedora/RHEL/CentOS package manager) or dddd (random strings), which are likely to be the user's mistakes or typos as you mentioned.

[oc1024]

Initialize default_helper and NEEDS_ROOT with an empty string

Done.

[[ ${helper:=$REPLY} == [dD]* ]] && helper=$default_helper

Wouldn't this also affect some possible AUR helper named david (for instance) if we were to add it in the future?
Either way, Here's what I came up with (while also not accepting any other words like dnf):

local PS3="Which AUR helper to use? [${default_helper:+d: $default_helper (default), }x: cancel]? "
NEEDS_ROOT=''; OPERATION='S';
select helper in "${available[@]}"; do
    # Check if default was set 
    [[ ${helper:=$REPLY} = [dD] || $REPLY = default ]] && helper="$default_helper"
    # Special case: Aura
    [[ $helper = aura ]] && { NEEDS_ROOT=1; OPERATION='Ax'; }
    case $helper in
    (aura|yay|paru|pacaur|pikaur|pakku|yaourt|aurman|trizen)
            ble/util/print "Selected helper: $helper"
            exec ${NEEDS_ROOT:+sudo} "$helper" "-$OPERATION" "$PKGNAME"
            break ;;
    (built-in)
            ble/util/print 'Using built-in AUR helper.'
            exit 3 ;;
    ([xX]|exit|[cC]|cancel)
            ble/util/print >&2 'Canceled by the user.'
            exit 1 ;;
    esac
done

Someone naming their helper d or default is way less likely, and even if they do, their uncreative naming deserves to be punished.

This is one of the reason why I define a function ble/array#push instead of directly using arr+=(elements)

I never noticed that (it's one of these moments you realize you're quite spoiled by features of a new revision of the language). The recent macOS preconv issue also gave a glimpse on how challenging multiplatform shell scripting can be.

[akinomyoga]

Thank you again! Now everything looks fine.

Wouldn't this also affect some possible AUR helper named david (for instance) if we were to add it in the future?
Either way, Here's what I came up with (while also not accepting any other words like dnf):

Yeah, so it is fine to not accepting other words starting from [dDxXcC].

Someone naming their helper d or default is way less likely, ~and even if they do, their uncreative naming deserves to be punished~.

haha... I'd think it's rather creative if someones named their helper as d or default. But I remembered that there was a (system-)configuration command named defaults in Mac OS X (not sure if it is still in macOS)...

This is one of the reason why I define a function ble/array#push instead of directly using arr+=(elements)

I never noticed that (it's one of these moments you realize you're quite spoiled by features of a new revision of the language). The recent macOS preconv issue also gave a glimpse on how challenging multiplatform shell scripting can be.

Yeah, I learned in maintaining ble.sh that, even for POSIX utilities (in particular awk's in different operating systems), we cannot always expect the standard behavior. Nevertheless, I can test operating systems that provide free versions. The real challenge is to support non-free proprietary operating systems that I don't have access to, including macOS, AIX, HP-UX, etc.

Another challenge is, as you have already seen in my comments, the combination of shopt settings. I sometimes receive a problem report caused by a specific combination of shopt settings, but I cannot test ble.sh under all of the 2^N combinations of the shopt settings. I just need to understand the effect of each shopt setting and be careful in writing the code.

[oc1024]

One last thing: I noticed ble-reloads aren't being done even when the function returns 0.

Looking at the output of set -x; ble-update, it has:

++++ POST_VERSION=0.4.0_devel3.r1521.560160b-1
++++ (( makepkg_exit==0 ))
++++ return 0
++++ local ext=0
++++ (( ext==125 ))
++++ ble-update/.reload 0
++++ local ext=1
++++ [[ 1 -eq 0 ]]
++++ [[ 1 -eq 6 ]]
++++ (( ext==6 ))
++++ return 1
++++ return 1

I think this might be the culprit:

function ble-update/.reload {
  local ext=$?

https://github.com/akinomyoga/ble.sh/blob/master/ble.pp#L1002

I believe you meant local ext="$1" (since you give the exit code of the "delegate" function as the first positional parameter). I think $? is getting "contaminated" with the exit code of ((ext==125)).

[akinomyoga]

I believe you meant local ext="$1" (since you give the exit code of the "delegate" function as the first positional parameter). I think $? is getting "contaminated" with the exit code of ((ext==125)).

Ah, Thanks. I pushed a commit 9372670!

[huresche]

@huresche If I'm not asking too much, can you see the exit codes of AUR helpers when you say "No" to the installation of the built package? I'm trying to find an "unused" exit code specifically for triggering the built-in helper.

Do you mean the exit code after someone selects a helper, but then selects "no" or "abort" when confirming the installation/build? For the yay, paru, pikaur, pakku and aura helpers, that exit code is 1, trizen does not prompt you for such confirmation; and if you manually cancel with Ctrl-C it's also exit code 1.