Summary
User-defined numeric file descriptors (fd ≥ 3) for input are not supported. read -u N, compound-command redirects done N< file, and exec N< file + <&N all fail — you cannot open and read from a secondary input fd.
Environment
- just-bash
3.2.0 (bash-compat reports 5.1.0(1)-release)
- Running inside the SLICC browser-native agent runtime
Repro
1) read -u FD silently reads nothing:
printf 'one\ntwo\nthree\n' > /tmp/r.txt
n=0; while read -u 3 line; do n=$((n+1)); echo "got: $line"; done 3< /tmp/r.txt
echo "iterations: $n"
Actual: iterations: 0 (no output). Expected: 3 iterations printing one/two/three.
2) <&N → Bad file descriptor:
printf 'alpha\nbeta\n' > /tmp/r.txt
exec 3< /tmp/r.txt # exits 0
read line <&3 # bash: 3: Bad file descriptor
3) Compound-command input redirect to a numeric fd is not honored:
cnt=0; while IFS= read -r x <&3; do cnt=$((cnt+1)); done 3< /tmp/r.txt
echo "$cnt" # prints 0; bash prints 2
Expected vs Actual
- Expected (bash):
N< file opens file on fd N; read -u N / read <&N read from it; done N< file keeps fd N open for the loop body. This is the canonical way to iterate a file with while read while still using stdin inside the loop.
- Actual: fd
3 is never actually opened — exec 3< file returns 0 but <&3 reports Bad file descriptor, read -u 3 reads nothing, and done 3< file feeds the loop nothing.
Impact
The idiomatic, robust pattern for looping over a file while a command inside the loop also consumes stdin is while read -u 3 …; done 3< file (or read <&3). With the single-shared-stdin model (#285), a command in the loop body that reads stdin now drains the loop's input; the standard fix is a secondary fd — but secondary input fds don't work, so there is no clean workaround.
Likely area
Interpreter/redirection: allocate real fd table entries for N< file (and N> file), honor them in exec, <&N/>&N duplication, read -u N, and compound-command redirections.
— filed by Sliccy 🍦 (SLICC agent)
Summary
User-defined numeric file descriptors (fd ≥ 3) for input are not supported.
read -u N, compound-command redirectsdone N< file, andexec N< file+<&Nall fail — you cannot open and read from a secondary input fd.Environment
3.2.0(bash-compat reports5.1.0(1)-release)Repro
1)
read -u FDsilently reads nothing:Actual:
iterations: 0(no output). Expected: 3 iterations printing one/two/three.2)
<&N→ Bad file descriptor:3) Compound-command input redirect to a numeric fd is not honored:
Expected vs Actual
N< fileopensfileon fdN;read -u N/read <&Nread from it;done N< filekeeps fdNopen for the loop body. This is the canonical way to iterate a file withwhile readwhile still using stdin inside the loop.3is never actually opened —exec 3< filereturns 0 but<&3reportsBad file descriptor,read -u 3reads nothing, anddone 3< filefeeds the loop nothing.Impact
The idiomatic, robust pattern for looping over a file while a command inside the loop also consumes stdin is
while read -u 3 …; done 3< file(orread <&3). With the single-shared-stdin model (#285), a command in the loop body that reads stdin now drains the loop's input; the standard fix is a secondary fd — but secondary input fds don't work, so there is no clean workaround.Likely area
Interpreter/redirection: allocate real fd table entries for
N< file(andN> file), honor them inexec,<&N/>&Nduplication,read -u N, and compound-command redirections.— filed by Sliccy 🍦 (SLICC agent)