Tjyylli

Patience, young "Padovan"

Finding files for which a command fails

If a centaur druid Wild Shapes into a Giant Elk, do their Charge features stack?

Extreme, but not acceptable situation and I can't start the work tomorrow morning

Lied on resume at previous job

Manga about a female worker who got dragged into another world together with this high school girl and she was just told she's not needed anymore

Can a planet have a different gravitational pull depending on its location in orbit around its sun?

Is "plugging out" electronic devices an American expression?

What is the command to reset a PC without deleting any files

Copycat chess is back

How to make payment on the internet without leaving a money trail?

Are objects structures and/or vice versa?

What's the difference between repeating elections every few years and repeating a referendum after a few years?

Why was the "bread communication" in the arena of Catching Fire left out in the movie?

Unbreakable Formation vs. Cry of the Carnarium

When blogging recipes, how can I support both readers who want the narrative/journey and ones who want the printer-friendly recipe?

Need help identifying/translating a plaque in Tangier, Morocco

I see my dog run

Was there ever an axiom rendered a theorem?

What is the meaning of "of trouble" in the following sentence?

Why did the Germans forbid the possession of pet pigeons in Rostov-on-Don in 1941?

How would photo IDs work for shapeshifters?

Are cabin dividers used to "hide" the flex of the airplane?

extract characters between two commas?

File descriptor opened once but closed many times; why the discrepancy?

Run a command multiple times, but load it just onceEstimating compressed file size using a list parameterWhy doesn't num blocks times block size match file size?What exactly determines if a backgrounded job is killed when the shell is exited, or killed?How can I print file names on linux command if know its file descriptor of a file opened by a process?How to count the number of times a file/directory has been opened?why would openat() use file descriptor decremented by 1For what purpose is the '&-' file descriptor used in fish?Why is there a huge discrepancy between file sizes reported by du versus ls?urban legend : why is it better to avoid using file descriptor 5?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}

1

I was trying to use process substitution and come across the following example:

exec 3>&1

tar cf /dev/fd/4 $directory_name 4>&1 >&3 3>&- | bzip2 -c > file.tar.bz2 3>&-

exec 3>&- 

As per my understanding that means the following:

1. Create file descriptor 3 and attach it to stdout.




2. tar will compress files in the directory defined by $directory_name and compressed file is denoted internally by file descriptor 4.




3. File descriptor 4 is attached to stdout.




4. stdout is attached to file descriptor 3 and file descriptor 3 closed.

But again in bzip2 file descriptor is closed again and in final line exec command is also closing descriptor 3. There I am lost, why the same file descriptor is closed 3 times?

linux shell-script redirection file-descriptors

share|improve this question

edited 2 days ago

Kamil Maciorowski

29k156287

asked 2 days ago

Amarjeet SharmaAmarjeet Sharma

133

add a comment | 

1

I was trying to use process substitution and come across the following example:

exec 3>&1

tar cf /dev/fd/4 $directory_name 4>&1 >&3 3>&- | bzip2 -c > file.tar.bz2 3>&-

exec 3>&- 

As per my understanding that means the following:

1. Create file descriptor 3 and attach it to stdout.




2. tar will compress files in the directory defined by $directory_name and compressed file is denoted internally by file descriptor 4.




3. File descriptor 4 is attached to stdout.




4. stdout is attached to file descriptor 3 and file descriptor 3 closed.

But again in bzip2 file descriptor is closed again and in final line exec command is also closing descriptor 3. There I am lost, why the same file descriptor is closed 3 times?

linux shell-script redirection file-descriptors

share|improve this question

edited 2 days ago

Kamil Maciorowski

29k156287

asked 2 days ago

Amarjeet SharmaAmarjeet Sharma

133

add a comment | 

I was trying to use process substitution and come across the following example:

exec 3>&1

tar cf /dev/fd/4 $directory_name 4>&1 >&3 3>&- | bzip2 -c > file.tar.bz2 3>&-

exec 3>&- 

As per my understanding that means the following:

1. Create file descriptor 3 and attach it to stdout.




2. tar will compress files in the directory defined by $directory_name and compressed file is denoted internally by file descriptor 4.




3. File descriptor 4 is attached to stdout.




4. stdout is attached to file descriptor 3 and file descriptor 3 closed.

But again in bzip2 file descriptor is closed again and in final line exec command is also closing descriptor 3. There I am lost, why the same file descriptor is closed 3 times?

linux shell-script redirection file-descriptors

share|improve this question

edited 2 days ago

Kamil Maciorowski

29k156287

asked 2 days ago

Amarjeet SharmaAmarjeet Sharma

133

exec 3>&1

tar cf /dev/fd/4 $directory_name 4>&1 >&3 3>&- | bzip2 -c > file.tar.bz2 3>&-

exec 3>&- 

share|improve this question

edited 2 days ago

Kamil Maciorowski

29k156287

asked 2 days ago

Amarjeet SharmaAmarjeet Sharma

133

share|improve this question

edited 2 days ago

Kamil Maciorowski

29k156287

asked 2 days ago

Amarjeet SharmaAmarjeet Sharma

133

edited 2 days ago

Kamil Maciorowski

29k156287

edited 2 days ago

Kamil Maciorowski

29k156287

asked 2 days ago

Amarjeet SharmaAmarjeet Sharma

133

asked 2 days ago

Amarjeet SharmaAmarjeet Sharma

133

1 Answer
1

active

oldest

votes

0

These are different descriptors. See this good answer. It says:

[A child] inherits a copy of the file descriptor. So closing the descriptor in the child will close it for the child, but not the parent, and vice versa.

In a case like tar cf /dev/fd/4 $directory_name 4>&1 >&3 3>&- redirections are handled by the shell before tar even starts, but the principle is the same: these descriptors are not these of the main shell. When tar starts (strictly: when the copy of the shell eventually execs to tar), its /dev/fd/* links are already prepared and there is no /dev/fd/3.

In the same way bzip2 finds its own descriptors prepared. They may link to the same files as descriptors of some other process do, but they are separate entities.

Keep in mind each process sees its own descriptors in /dev/fd/, it's a useful trick. If you consider /proc/<PID>/fd/ directories, it will become more clear descriptors are per PID.

Finally exec 3>&- closes the descriptor for the main shell. It's yet another separate entity.

share|improve this answer

answered 2 days ago

Kamil MaciorowskiKamil Maciorowski

29k156287

add a comment | 

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1422088%2ffile-descriptor-opened-once-but-closed-many-times-why-the-discrepancy%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

0

These are different descriptors. See this good answer. It says:

[A child] inherits a copy of the file descriptor. So closing the descriptor in the child will close it for the child, but not the parent, and vice versa.

In a case like tar cf /dev/fd/4 $directory_name 4>&1 >&3 3>&- redirections are handled by the shell before tar even starts, but the principle is the same: these descriptors are not these of the main shell. When tar starts (strictly: when the copy of the shell eventually execs to tar), its /dev/fd/* links are already prepared and there is no /dev/fd/3.

In the same way bzip2 finds its own descriptors prepared. They may link to the same files as descriptors of some other process do, but they are separate entities.

Keep in mind each process sees its own descriptors in /dev/fd/, it's a useful trick. If you consider /proc/<PID>/fd/ directories, it will become more clear descriptors are per PID.

Finally exec 3>&- closes the descriptor for the main shell. It's yet another separate entity.

share|improve this answer

answered 2 days ago

Kamil MaciorowskiKamil Maciorowski

29k156287

add a comment | 

0

These are different descriptors. See this good answer. It says:

[A child] inherits a copy of the file descriptor. So closing the descriptor in the child will close it for the child, but not the parent, and vice versa.

In a case like tar cf /dev/fd/4 $directory_name 4>&1 >&3 3>&- redirections are handled by the shell before tar even starts, but the principle is the same: these descriptors are not these of the main shell. When tar starts (strictly: when the copy of the shell eventually execs to tar), its /dev/fd/* links are already prepared and there is no /dev/fd/3.

In the same way bzip2 finds its own descriptors prepared. They may link to the same files as descriptors of some other process do, but they are separate entities.

Keep in mind each process sees its own descriptors in /dev/fd/, it's a useful trick. If you consider /proc/<PID>/fd/ directories, it will become more clear descriptors are per PID.

Finally exec 3>&- closes the descriptor for the main shell. It's yet another separate entity.

share|improve this answer

answered 2 days ago

Kamil MaciorowskiKamil Maciorowski

29k156287

add a comment | 

These are different descriptors. See this good answer. It says:

[A child] inherits a copy of the file descriptor. So closing the descriptor in the child will close it for the child, but not the parent, and vice versa.

In a case like tar cf /dev/fd/4 $directory_name 4>&1 >&3 3>&- redirections are handled by the shell before tar even starts, but the principle is the same: these descriptors are not these of the main shell. When tar starts (strictly: when the copy of the shell eventually execs to tar), its /dev/fd/* links are already prepared and there is no /dev/fd/3.

In the same way bzip2 finds its own descriptors prepared. They may link to the same files as descriptors of some other process do, but they are separate entities.

Keep in mind each process sees its own descriptors in /dev/fd/, it's a useful trick. If you consider /proc/<PID>/fd/ directories, it will become more clear descriptors are per PID.

Finally exec 3>&- closes the descriptor for the main shell. It's yet another separate entity.

share|improve this answer

answered 2 days ago

Kamil MaciorowskiKamil Maciorowski

29k156287

share|improve this answer

answered 2 days ago

Kamil MaciorowskiKamil Maciorowski

29k156287

answered 2 days ago

Kamil MaciorowskiKamil Maciorowski

29k156287

answered 2 days ago

Kamil MaciorowskiKamil Maciorowski

29k156287