contrib/bootstrap script runs sub programs without a tty/stdin

[coderforlife]

Describe the bug

bootstrap.d scripts that are run by the contrib/bootstrap script have no tty (i.e. the command tty reports not a tty) and no standard input (i.e. using read or select always get no input).

To reproduce

1. Run the commands:

mkdir -p ~/.config/yadm/bootstrap.d
wget -O ~/.config/yadm/bootstrap https://github.com/TheLocehiliosan/yadm/blob/master/contrib/bootstrap/bootstrap-in-dir`
chmod +x ~/.config/yadm/bootstrap
cat >~/.config/yadm/bootstrap.d/00-test.sh <<EOF
#!/usr/bin/env bash
tty
read -p "prompt" var
echo "<$var>"
EOF
chmod +x ~/.config/yadm/bootstrap.d/00-test.sh
yadm bootstrap

2. Prints not a tty then <> without ever getting a value from the user

Lots of similar examples can be created, if doing a loop that validates user's input, it will just go forever. If using select it will give up after a few iterations automatically.

Expected behavior

The commands read and select (and anything reading from stdin) to wait for user input or take whatever user input is given to yadm command. The user-interactiveness is partially expected since when doing yadm clone ... it uses read itself right before running the bootstrap script!

Workarounds and Solutions

Doing exec </dev/tty in the bootstrap.d script gets the stdin back from the terminal, but will lose any redirects the user themselves did.

The real solution is to replace the line:

find "$BOOTSTRAP_D" -type f | sort | while IFS= read -r bootstrap; do

with

readarray -t bootstraps < <(find -L "$BOOTSTRAP_D" -type f | sort)
for bootstrap in "${bootstraps[@]}"; do

which creates the array properly without messing with IFS and having an in-use read while calling other scripts.

Environment

• Operating system: Fedora 34
• Version yadm: 3.1.0
• Version Git: 2.31.1
• Version bash: GNU bash 5.1.0

[github-actions[bot]]

This issue has been labeled as stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been labeled as stale for 7 days with no activity.

[JeffFaer]

It doesn't look like this has been fixed yet. Are you open to accepting a PR for this?

I spent quite a bit of time figuring out what was going on here :(

[TheLocehiliosan]

I spent quite a bit of time figuring out what was going on here :(

Yes, I'll be looking at this PR. Please don't be sad. I just have a lot going on right now. :)

As for this issue being closed, I thought I "saved it" by removing the stale tag and assigning it to myself on Jan 1 2022. But I don't think I realized at the time that the issue had also been closed (not just marked stale).