mvdan.cc/sh/v3 v3.9.0 breaks reading from file redirection
Problem: Running into https://github.com/mvdan/sh/issues/1099, see https://github.com/go-task/task/blob/v3.39.2/go.mod#L26
Request: mvdan/sh should be downgraded to 3.8.0
Example taskfile:
version: "3"
tasks:
embedded-hang:
cmds:
- cmd: |
set -x
while read -r line; do
echo "$line"
done < <(echo "hi file substitution")
echo done
use-script:
cmds:
- cmd: |
cat <<EOF> read.sh
#!/bin/bash
set -x
while read -r line; do
echo "$line"
done < <(echo "hi file substitution")
echo done
EOF
chmod +x read.sh
./read.sh
Hangs when using gosh:
❯ task embedded-hang
task: [embedded-hang] set -x
while read -r line; do
echo "$line"
done < <(echo "hi file substitution")
echo done
+ echo 'hi file substitution'
+ read '-r line'
+ echo 'hi file substitution'
hi file substitution
+ read '-r line'
^Ctask: Signal received: "interrupt"
^Ctask: Signal received: "interrupt"
^Ctask: Signal received for the third time: "interrupt". Forcing shutdown
/private/tmp/task took 4s
Sanity check, writing same script to disk and running it directly works as expected
❯ task use-script
task: [use-script] cat <<EOF> read.sh
#!/bin/bash
set -x
while read -r line; do
echo "$line"
done < <(echo "hi file substitution")
echo done
EOF
chmod +x read.sh
./read.sh
+ read -r line
++ echo 'hi file substitution'
+ echo ''
+ read -r line
+ echo done
done
- Task version: v3.39.2
- Operating system: macos
- Experiments enabled:
A fix for this was just committed to mvdan/sh (see linked issue in upstream). He said he'll cut a new release in the next couple days most likely, so it's probably worth waiting for that release.
I'll update this dependency as soon as it's released.
Looks like 3.10.0 which includes the fix has dropped https://github.com/mvdan/sh/releases/tag/v3.10.0
mvdan/sh has been updated with the latest version, It'll be available in the next release :)
for me with go-task 3.40.1, the problem still exists?
❯ brew install go-task
==> Downloading https://ghcr.io/v2/homebrew/core/go-task/manifests/3.40.1
##################################################################################################################################################### 100.0%
==> Fetching go-task
==> Downloading https://ghcr.io/v2/homebrew/core/go-task/blobs/sha256:11446cbb6f0acb73b7eecac3d19ee4a5fab3cb13f5d2fee8a0f311fa0f0562f9
##################################################################################################################################################### 100.0%
==> Pouring go-task--3.40.1.arm64_sonoma.bottle.tar.gz
==> Caveats
zsh completions have been installed to:
/opt/homebrew/share/zsh/site-functions
==> Summary
🍺 /opt/homebrew/Cellar/go-task/3.40.1: 10 files, 15.3MB
==> Running `brew cleanup go-task`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
on ⎈ admin-tooling-k8s-dev in admin-tooling on gitlab_ssh [!?] took 2s
➜ task --version
Task version: 3.40.1 ()
on ⎈ admin-tooling-k8s-dev in admin-tooling on gitlab_ssh [!?]
➜
on ⎈ admin-tooling-k8s-dev in admin-tooling on gitlab_ssh [!]
➜
on ⎈ admin-tooling-k8s-dev in admin-tooling on gitlab_ssh [!]
➜ ENV=dev task apply-tooling
task: [prepare-k8s] kubectl config use-context admin-tooling-k8s-dev
Switched to context "admin-tooling-k8s-dev".
task: [prepare-k8s-secrets] for secretfile in $(find . -type f -regex '.*.*\/dev\/secrets\/.*\.env' -o -regex '.*.*\/base\/secrets\/.*\.env') ; do
cp $secretfile $secretfile.backup
while read -r line; do eval echo $line; done < $secretfile.backup > $secretfile
done
( hangs .. reading ..)
^Ctask: Signal received: "interrupt"
^Ctask: Signal received: "interrupt"
For me the issue still exists after upgrading to 3.40.1. Rolling back to 3.38.0 everything works fine.
My work around for now to make in work with versions >3.38.0 is using
cat $file | while read -r line; do echo $line; done
instead of
while read -r line; do echo $line; done < $file
I'm confused since it seems to be fixed in the dependency (https://github.com/mvdan/sh/commit/f3c910119774fd545820e7ee14f85677c6ed1a78).
Anyone else still having this issue?