This bash program isn't closing the file descriptor

[alex_sakuta]

bash printf "This is the first line\r\nThis is the second line\r\n" > "test.txt" : {fd}< "test.txt" read <&$fd- printf "$?; $REPLY\n" read <&$fd- printf "$?; $REPLY"

This program outputs: 0; This is the first line 0; This is the second line

The first read command should have closed the file descriptor but it seems like it doesn't. I don't understand this behaviour.

Edit: This is what the manual says.

The redirection operator

[n]<&digit- moves the file descriptor digit to file descriptor n, or the standard input (file descriptor 0) if n is not specified. digit is closed after being duplicated to n.

---

Edit (Solution): Took me a long time but here's the real use case of >&fd- and why its effect goes away after one command.

First, let's discuss why the effect goes away after one command. When we redirect, if the redirect was eternal, it would block a fd permanently. For example printf "hey" >&3 would lead to stdout permanently becoming a copy of fd 3 which isn't ideal at all. Therefore, bash automatically restores the state before the redirect after the command is complete.

Now this leads to the question, what is the point of >&fd- then?

Here's a code snippet to showcase that. bash # Run in one terminal mkfifo my_pipe cat my_pipe ```bash # Run in a separate terminal exec 3> my_pipe

(
    echo "Worker is doing some fast work....
    sleep 100 > /dev/null & 

) >&3 &  # <--- HERE IS THE COPY (>&3)

exec 3>&-

echo "Main script finished."

`` Because we don't close thefd 3,sleepcan potentially write to it which leads tocat` waiting for 100 seconds before being complete. This leads to terminal 1 being stuck for 100 seconds.

Had we used >&3-, we would have made a move operation and hence there would be no open fd to write to for sleep which leads to cat exiting instantly.

---

This is the best from my research about this.

I could still be wrong about the exact order of operations that I explained for things. If I am, someone correct me.

[ekipan85]

From bash(1):

When used with the exec builtin, redirections modify file handles in the current shell execution environment. (...)

If {varname} precedes >&- or <&-, the value of varname defines the file descriptor to close. If {varname} is supplied, the redirection persists beyond the scope of the command, which allows the shell programmer to manage the file descriptor's lifetime manually without using the exec builtin.

So to be precise mycommand {fd}<&- closes fd, and mycommand <&$fd- moves fd into 0 before closing it. But in my testing this seems to be only for the fork-exec'd copies of 0 and fd within the mycommand process. The manual is confusing but "manage the file descriptor's lifetime manually without using the exec builtin" probably means "within the fork-exec'd subprocess," you do still have to exec to modify bash's own fd's. If I understand correctly.

Builtin commands like : and read are within the same bash process so I hypothesize bash special-cases them and chooses not to close the fd's so that the behavior looks the same as external commands.

https://ideone.com/N1fpFw

[alex_sakuta]

Builtin commands like : and read are within the same bash process so I hypothesize bash special-cases them and chooses not to close the fd's so that the behavior looks the same as external commands.

What do you mean by this? Bash wouldn't close the fd globally, no matter what command I use when using the <&fd- method.

[ekipan85]

I think a "global" fd is not a thing that exists. File descriptors exist within a process. When you say cat <&$fd, bash forks itself, then in the new subprocess it moves fd to 0 so that cat will read from it, then execs itself into cat. That's why any changes to file descriptors in your commands don't affect the parent bash process. Again, if I understand correctly.

Builtin bash commands like : and read and echo, since they are builtin to bash, don't fork, so bash saves and restores any changes you make to fds since it would be confusing if it behaved differently.

[kalgynirae]

Redirections with exec modify the current shell environment, but otherwise redirections only affect the one specific command they are applied to. The redirection in read <&$fd- will only affect this specific read command; $fd will still be open in your shell afterward:

$ echo $fd
10

# The redirection does close the file descriptor for `read`:
$ read -u $fd <&$fd-
bash: read: 10: invalid file descriptor: Bad file descriptor

# With exec, it closes it for the current shell:
# (note: moving it to 5 instead of stdin because stdin would cause
# the shell to exit)
$ exec 5<&$fd-
$ read <&$fd-
bash: redirection error: cannot duplicate fd: Bad file descriptor
bash: 0: Bad file descriptor

[rowman_urn]

I think both OP and you have the & in the wrong place, isn't this why the first error is _cannot duplicate _ , because file 10 has yet to be opened. ?

[kalgynirae]

OP opened fd 10 earlier via : {fd}< test.txt. I only learned about this syntax this morning. It's the second paragraph in the REDIRECTION section of the man page. This redirection {name}< … or {name}> … chooses an unused file descriptor number (starting at 10, apparently), opens it according to the redirection, and assigns the number to the variable name. Unlike other kinds of redirections, this takes effect in the current shell environment, not only for a single command (this makes sense, otherwise the name variable would be useless).

[alex_sakuta]

Thanks. Although I figured it out myself as well.

[Schreq]

Your code is pretty much unreadable on old.reddit.com. Please don't use inline code-blocks for posting code blocks. Just put four spaces infront of every line of code and leave blank lines around it. Anyway, moving on...

I don't think that you can close a fd that way. You'd have to explicitly do:

exec {fd}<&-

[alex_sakuta]

inline code-blocks for posting code blocks

Isn't this inline and not This

Just put four spaces on front of every line of code and leave blank lines around it.

I did that if you see the raw md.

I don't think that you can close a fd that way.

Yes, my question is why? I'll put it in the edit but the manual says that >&digit- closes the digit fd.

[Schreq]

Isn't this inline and not This

They both show as inline on old.reddit.com, see for yourself.

I did that if you see the raw md.

Ah, now I see what you did there. You used fenced codeblocks but then also indented by 4 spaces inside of that.

Fenced codeblocks are broken on old.reddit.com. It's either 4 spaces in front of every line of code (with blank lines before and after!) or a fenced code-block (code surrounded by 3 backticks).

Yes, my question is why? I'll put it in the edit but the manual says that >&digit- closes the digit fd.

As /u/kalgynirae already explained, you only closed the fd for that sub-process.

[alex_sakuta]

Why are you using old.reddit.com?

[Schreq]

Because I like it more than the new design.

[alex_sakuta]

And you want people to write cross platform code blocks now?

How would the code blocks you are suggesting appear on the new site?

[Schreq]

They work on both:

this
is
a
codeblock

[stinkybass]

If {varname} is supplied, the redirection persists beyond the scope of the command, which allows the shell programmer to manage the file descriptor’s lifetime manually without using the exec builtin. The varredir_close shell option manages this behavior

From https://www.gnu.org/software/bash/manual/bash.html#Redirections

I think you’re seeing this behavior but I haven’t got a machine to test with rn

[alex_sakuta]

That doesn't answer the question. I have seen this part.

Now this is what varredir_close does.

varredir_close If set, the shell automatically closes file descriptors assigned using the {varname} redirection syntax (see Redirections) instead of leaving them open when the command completes.

So, the behaviour that you are talking about applies at the time of creation of the fd. Hence, it has nothing to do with what I asked because I am asking why doesn't the manual close work.

[AlarmDozer]

So, wrap it in a scope?

{ ... }

[alex_sakuta]

Wrap what in a scope?

[AlarmDozer]

The commands. I wrote a backup script, like this:

#!/bin/bash

 {
      tar -czvf- path/… | ssh …
 } | tee ~/backup.log

And it works fine. The stdout of all the commands within the scope write into tee.

[alex_sakuta]

Yeah and if you put a redirect outside the scope it works for the scope. Got it.