Tjyylli

COUNT(*) or MAX(id) - which is faster?

Is ipsum/ipsa/ipse a third person pronoun, or can it serve other functions?

Why do UK politicians seemingly ignore opinion polls on Brexit?

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

What do the Banks children have against barley water?

New order #4: World

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

How to deal with fear of taking dependencies

What causes the sudden spool-up sound from an F-16 when enabling afterburner?

Is there a name of the flying bionic bird?

Does a dangling wire really electrocute me if I'm standing in water?

How could a lack of term limits lead to a "dictatorship?"

Is "plugging out" electronic devices an American expression?

What are the advantages and disadvantages of running one shots compared to campaigns?

Why do we use polarized capacitors?

Calculate Levenshtein distance between two strings in Python

Is there a familial term for apples and pears?

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

Typesetting a double Over Dot on top of a symbol

"listening to me about as much as you're listening to this pole here"

Could a US political party gain complete control over the government by removing checks & balances?

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

Email Account under attack (really) - anything I can do?

Could Giant Ground Sloths have been a good pack animal for the ancient Mayans?

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