Close all file descriptors in bash
Clash Royale CLAN TAG#URR8PPP
Is there a way to close all the open file descriptors, without having an explicit list of them beforehand?
bash shell file-descriptors
add a comment |
Is there a way to close all the open file descriptors, without having an explicit list of them beforehand?
bash shell file-descriptors
4
All of which file descriptors? Every process has some open.
– Warren Young
Apr 6 '14 at 17:54
add a comment |
Is there a way to close all the open file descriptors, without having an explicit list of them beforehand?
bash shell file-descriptors
Is there a way to close all the open file descriptors, without having an explicit list of them beforehand?
bash shell file-descriptors
bash shell file-descriptors
edited Apr 6 '14 at 22:58
Gilles
527k12710561580
527k12710561580
asked Apr 6 '14 at 17:48
Lorenzo Pistone
3181315
3181315
4
All of which file descriptors? Every process has some open.
– Warren Young
Apr 6 '14 at 17:54
add a comment |
4
All of which file descriptors? Every process has some open.
– Warren Young
Apr 6 '14 at 17:54
4
4
All of which file descriptors? Every process has some open.
– Warren Young
Apr 6 '14 at 17:54
All of which file descriptors? Every process has some open.
– Warren Young
Apr 6 '14 at 17:54
add a comment |
5 Answers
5
active
oldest
votes
To answer literally, to close all open file descriptors for bash
:
for fd in $(ls /proc/$$/fd); do
eval "exec $fd>&-"
done
However this really isn't a good idea since it will close the basic file descriptors the shell needs for input and output. If you do this, none of the programs you run will have their output displayed on the terminal (unless they write to the tty
device directly). If fact in my tests closing stdin
(exec 0>&-
) just causes an interactive shell to exit.
What you may actually be looking to do is rather to close all file descriptors that are not part of the shell's basic operation. These are 0 for stdin
, 1 for stdout
and 2 for stderr
. On top of this some shells also seem to have other file descriptors open by default. In bash
, for example, you have 255 (also for terminal I/O) and in dash
I have 10, which points to /dev/tty
rather than the specific tty
/pts
device the terminal is using. To close everything apart from 0, 1, 2 and 255 in bash
:
for fd in $(ls /proc/$$/fd); do
case "$fd" in
0|1|2|255)
;;
*)
eval "exec $fd>&-"
;;
esac
done
Note also that eval
is required when redirecting the file descriptor contained in a variable, if not bash
will expand the variable but consider it part of the command (in this case it would try to exec
the command 0
or 1
or whichever file descriptor you are trying to close).
NOTE: Also using a glob instead of ls
(eg /proc/$$/fd/*
) seems to open an extra file descriptor for the glob, so ls
seems the best solution here.
Update
For further information on the portability of /proc/$$/fd
, please see Portability of file descriptor links. If /proc/$$/fd
is unavailable, then a drop in replacement for the $(ls /proc/$$/fd)
, using lsof
(if that is available) would be $(lsof -p $$ -Ff | grep f[0-9] | cut -c 2-)
.
/proc
is only available under Linux.
– chepner
Apr 7 '14 at 19:30
4
@chepner you would be right if you said that/proc/PID/fd
is not very portable. But saying that/proc
is only available under Linux is not a correct statement.
– Graeme
Apr 7 '14 at 19:35
Some websites use the<&-
form, is it any different/needed?
– Lorenzo Pistone
Apr 7 '14 at 21:56
@LorenzoPistone, the direction makes no difference when closing a descriptor, so either form can be used.
– Graeme
Apr 7 '14 at 22:03
add a comment |
In recent versions of Bash (4.1 and onward, year 2009 and later) you can specify the file descriptor to close using a shell variable:
for fd in $(ls /proc/$$/fd/); do
[ $fd -gt 2 ] && exec fd<&-
done
The feature had been in Korn shell already (since 1993?) but apparently took some time to make its way into Bash.
add a comment |
Clear all file descriptors except i/o/e of the current shell, but also excludes the ones provided as arguments
clear_fds() 255)
;;
*)
eval "exec $fd>&-"
;;
esac
fi
done
add a comment |
No. The kernel can close only one FD at a time, and bash does not have "group commands" for FDs.
for fd in $(ls -1 /proc/27343/fd); do echo exec "$fd>&-"; done
Remove the echo
after testing.
If this is not for the shell itself but for a command to be run then you can use nohup
.
2
The file descriptor used by>&-
cannot be a parameter; the redirection is parsed prior to parameter expansion.
– chepner
Apr 7 '14 at 19:35
add a comment |
Another way without "eval" at all, is to use the form:
$ exec var_a>> file.txt
$ echo $var_a
10
$ ls -l /proc/self/fd/10
l-wx------ 1 0 0 64 Dec 11 18:32 /proc/self/fd/10 -> /run/user/0/tmp/file.txt
$ echo "aaaaa" >&$var_a
$ cat file.txt
aaaaa
$ exec var_a>&-
$ ls /proc/self/fd/10
ls: cannot access '/proc/self/fd/10': No such file or directory
But this doesn't close all file descriptors.
– G-Man
Dec 11 at 18:04
Indeed. You'll have to exec in a loop like explained in the previous replies... It was just to point the fact that "eval" is not mandatory here and that we can keep the same logic to close it than to open it... Man pages are really not clear about this...
– David DG
Dec 11 at 18:11
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
);
);
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f123413%2fclose-all-file-descriptors-in-bash%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
To answer literally, to close all open file descriptors for bash
:
for fd in $(ls /proc/$$/fd); do
eval "exec $fd>&-"
done
However this really isn't a good idea since it will close the basic file descriptors the shell needs for input and output. If you do this, none of the programs you run will have their output displayed on the terminal (unless they write to the tty
device directly). If fact in my tests closing stdin
(exec 0>&-
) just causes an interactive shell to exit.
What you may actually be looking to do is rather to close all file descriptors that are not part of the shell's basic operation. These are 0 for stdin
, 1 for stdout
and 2 for stderr
. On top of this some shells also seem to have other file descriptors open by default. In bash
, for example, you have 255 (also for terminal I/O) and in dash
I have 10, which points to /dev/tty
rather than the specific tty
/pts
device the terminal is using. To close everything apart from 0, 1, 2 and 255 in bash
:
for fd in $(ls /proc/$$/fd); do
case "$fd" in
0|1|2|255)
;;
*)
eval "exec $fd>&-"
;;
esac
done
Note also that eval
is required when redirecting the file descriptor contained in a variable, if not bash
will expand the variable but consider it part of the command (in this case it would try to exec
the command 0
or 1
or whichever file descriptor you are trying to close).
NOTE: Also using a glob instead of ls
(eg /proc/$$/fd/*
) seems to open an extra file descriptor for the glob, so ls
seems the best solution here.
Update
For further information on the portability of /proc/$$/fd
, please see Portability of file descriptor links. If /proc/$$/fd
is unavailable, then a drop in replacement for the $(ls /proc/$$/fd)
, using lsof
(if that is available) would be $(lsof -p $$ -Ff | grep f[0-9] | cut -c 2-)
.
/proc
is only available under Linux.
– chepner
Apr 7 '14 at 19:30
4
@chepner you would be right if you said that/proc/PID/fd
is not very portable. But saying that/proc
is only available under Linux is not a correct statement.
– Graeme
Apr 7 '14 at 19:35
Some websites use the<&-
form, is it any different/needed?
– Lorenzo Pistone
Apr 7 '14 at 21:56
@LorenzoPistone, the direction makes no difference when closing a descriptor, so either form can be used.
– Graeme
Apr 7 '14 at 22:03
add a comment |
To answer literally, to close all open file descriptors for bash
:
for fd in $(ls /proc/$$/fd); do
eval "exec $fd>&-"
done
However this really isn't a good idea since it will close the basic file descriptors the shell needs for input and output. If you do this, none of the programs you run will have their output displayed on the terminal (unless they write to the tty
device directly). If fact in my tests closing stdin
(exec 0>&-
) just causes an interactive shell to exit.
What you may actually be looking to do is rather to close all file descriptors that are not part of the shell's basic operation. These are 0 for stdin
, 1 for stdout
and 2 for stderr
. On top of this some shells also seem to have other file descriptors open by default. In bash
, for example, you have 255 (also for terminal I/O) and in dash
I have 10, which points to /dev/tty
rather than the specific tty
/pts
device the terminal is using. To close everything apart from 0, 1, 2 and 255 in bash
:
for fd in $(ls /proc/$$/fd); do
case "$fd" in
0|1|2|255)
;;
*)
eval "exec $fd>&-"
;;
esac
done
Note also that eval
is required when redirecting the file descriptor contained in a variable, if not bash
will expand the variable but consider it part of the command (in this case it would try to exec
the command 0
or 1
or whichever file descriptor you are trying to close).
NOTE: Also using a glob instead of ls
(eg /proc/$$/fd/*
) seems to open an extra file descriptor for the glob, so ls
seems the best solution here.
Update
For further information on the portability of /proc/$$/fd
, please see Portability of file descriptor links. If /proc/$$/fd
is unavailable, then a drop in replacement for the $(ls /proc/$$/fd)
, using lsof
(if that is available) would be $(lsof -p $$ -Ff | grep f[0-9] | cut -c 2-)
.
/proc
is only available under Linux.
– chepner
Apr 7 '14 at 19:30
4
@chepner you would be right if you said that/proc/PID/fd
is not very portable. But saying that/proc
is only available under Linux is not a correct statement.
– Graeme
Apr 7 '14 at 19:35
Some websites use the<&-
form, is it any different/needed?
– Lorenzo Pistone
Apr 7 '14 at 21:56
@LorenzoPistone, the direction makes no difference when closing a descriptor, so either form can be used.
– Graeme
Apr 7 '14 at 22:03
add a comment |
To answer literally, to close all open file descriptors for bash
:
for fd in $(ls /proc/$$/fd); do
eval "exec $fd>&-"
done
However this really isn't a good idea since it will close the basic file descriptors the shell needs for input and output. If you do this, none of the programs you run will have their output displayed on the terminal (unless they write to the tty
device directly). If fact in my tests closing stdin
(exec 0>&-
) just causes an interactive shell to exit.
What you may actually be looking to do is rather to close all file descriptors that are not part of the shell's basic operation. These are 0 for stdin
, 1 for stdout
and 2 for stderr
. On top of this some shells also seem to have other file descriptors open by default. In bash
, for example, you have 255 (also for terminal I/O) and in dash
I have 10, which points to /dev/tty
rather than the specific tty
/pts
device the terminal is using. To close everything apart from 0, 1, 2 and 255 in bash
:
for fd in $(ls /proc/$$/fd); do
case "$fd" in
0|1|2|255)
;;
*)
eval "exec $fd>&-"
;;
esac
done
Note also that eval
is required when redirecting the file descriptor contained in a variable, if not bash
will expand the variable but consider it part of the command (in this case it would try to exec
the command 0
or 1
or whichever file descriptor you are trying to close).
NOTE: Also using a glob instead of ls
(eg /proc/$$/fd/*
) seems to open an extra file descriptor for the glob, so ls
seems the best solution here.
Update
For further information on the portability of /proc/$$/fd
, please see Portability of file descriptor links. If /proc/$$/fd
is unavailable, then a drop in replacement for the $(ls /proc/$$/fd)
, using lsof
(if that is available) would be $(lsof -p $$ -Ff | grep f[0-9] | cut -c 2-)
.
To answer literally, to close all open file descriptors for bash
:
for fd in $(ls /proc/$$/fd); do
eval "exec $fd>&-"
done
However this really isn't a good idea since it will close the basic file descriptors the shell needs for input and output. If you do this, none of the programs you run will have their output displayed on the terminal (unless they write to the tty
device directly). If fact in my tests closing stdin
(exec 0>&-
) just causes an interactive shell to exit.
What you may actually be looking to do is rather to close all file descriptors that are not part of the shell's basic operation. These are 0 for stdin
, 1 for stdout
and 2 for stderr
. On top of this some shells also seem to have other file descriptors open by default. In bash
, for example, you have 255 (also for terminal I/O) and in dash
I have 10, which points to /dev/tty
rather than the specific tty
/pts
device the terminal is using. To close everything apart from 0, 1, 2 and 255 in bash
:
for fd in $(ls /proc/$$/fd); do
case "$fd" in
0|1|2|255)
;;
*)
eval "exec $fd>&-"
;;
esac
done
Note also that eval
is required when redirecting the file descriptor contained in a variable, if not bash
will expand the variable but consider it part of the command (in this case it would try to exec
the command 0
or 1
or whichever file descriptor you are trying to close).
NOTE: Also using a glob instead of ls
(eg /proc/$$/fd/*
) seems to open an extra file descriptor for the glob, so ls
seems the best solution here.
Update
For further information on the portability of /proc/$$/fd
, please see Portability of file descriptor links. If /proc/$$/fd
is unavailable, then a drop in replacement for the $(ls /proc/$$/fd)
, using lsof
(if that is available) would be $(lsof -p $$ -Ff | grep f[0-9] | cut -c 2-)
.
edited Apr 13 '17 at 12:36
Community♦
1
1
answered Apr 6 '14 at 20:36
Graeme
24.8k46296
24.8k46296
/proc
is only available under Linux.
– chepner
Apr 7 '14 at 19:30
4
@chepner you would be right if you said that/proc/PID/fd
is not very portable. But saying that/proc
is only available under Linux is not a correct statement.
– Graeme
Apr 7 '14 at 19:35
Some websites use the<&-
form, is it any different/needed?
– Lorenzo Pistone
Apr 7 '14 at 21:56
@LorenzoPistone, the direction makes no difference when closing a descriptor, so either form can be used.
– Graeme
Apr 7 '14 at 22:03
add a comment |
/proc
is only available under Linux.
– chepner
Apr 7 '14 at 19:30
4
@chepner you would be right if you said that/proc/PID/fd
is not very portable. But saying that/proc
is only available under Linux is not a correct statement.
– Graeme
Apr 7 '14 at 19:35
Some websites use the<&-
form, is it any different/needed?
– Lorenzo Pistone
Apr 7 '14 at 21:56
@LorenzoPistone, the direction makes no difference when closing a descriptor, so either form can be used.
– Graeme
Apr 7 '14 at 22:03
/proc
is only available under Linux.– chepner
Apr 7 '14 at 19:30
/proc
is only available under Linux.– chepner
Apr 7 '14 at 19:30
4
4
@chepner you would be right if you said that
/proc/PID/fd
is not very portable. But saying that /proc
is only available under Linux is not a correct statement.– Graeme
Apr 7 '14 at 19:35
@chepner you would be right if you said that
/proc/PID/fd
is not very portable. But saying that /proc
is only available under Linux is not a correct statement.– Graeme
Apr 7 '14 at 19:35
Some websites use the
<&-
form, is it any different/needed?– Lorenzo Pistone
Apr 7 '14 at 21:56
Some websites use the
<&-
form, is it any different/needed?– Lorenzo Pistone
Apr 7 '14 at 21:56
@LorenzoPistone, the direction makes no difference when closing a descriptor, so either form can be used.
– Graeme
Apr 7 '14 at 22:03
@LorenzoPistone, the direction makes no difference when closing a descriptor, so either form can be used.
– Graeme
Apr 7 '14 at 22:03
add a comment |
In recent versions of Bash (4.1 and onward, year 2009 and later) you can specify the file descriptor to close using a shell variable:
for fd in $(ls /proc/$$/fd/); do
[ $fd -gt 2 ] && exec fd<&-
done
The feature had been in Korn shell already (since 1993?) but apparently took some time to make its way into Bash.
add a comment |
In recent versions of Bash (4.1 and onward, year 2009 and later) you can specify the file descriptor to close using a shell variable:
for fd in $(ls /proc/$$/fd/); do
[ $fd -gt 2 ] && exec fd<&-
done
The feature had been in Korn shell already (since 1993?) but apparently took some time to make its way into Bash.
add a comment |
In recent versions of Bash (4.1 and onward, year 2009 and later) you can specify the file descriptor to close using a shell variable:
for fd in $(ls /proc/$$/fd/); do
[ $fd -gt 2 ] && exec fd<&-
done
The feature had been in Korn shell already (since 1993?) but apparently took some time to make its way into Bash.
In recent versions of Bash (4.1 and onward, year 2009 and later) you can specify the file descriptor to close using a shell variable:
for fd in $(ls /proc/$$/fd/); do
[ $fd -gt 2 ] && exec fd<&-
done
The feature had been in Korn shell already (since 1993?) but apparently took some time to make its way into Bash.
answered Mar 30 '16 at 22:30
tetsujin
5112
5112
add a comment |
add a comment |
Clear all file descriptors except i/o/e of the current shell, but also excludes the ones provided as arguments
clear_fds() 255)
;;
*)
eval "exec $fd>&-"
;;
esac
fi
done
add a comment |
Clear all file descriptors except i/o/e of the current shell, but also excludes the ones provided as arguments
clear_fds() 255)
;;
*)
eval "exec $fd>&-"
;;
esac
fi
done
add a comment |
Clear all file descriptors except i/o/e of the current shell, but also excludes the ones provided as arguments
clear_fds() 255)
;;
*)
eval "exec $fd>&-"
;;
esac
fi
done
Clear all file descriptors except i/o/e of the current shell, but also excludes the ones provided as arguments
clear_fds() 255)
;;
*)
eval "exec $fd>&-"
;;
esac
fi
done
edited May 24 at 22:02
Joseph Sible
1,171213
1,171213
answered Mar 10 at 10:36
untore
535
535
add a comment |
add a comment |
No. The kernel can close only one FD at a time, and bash does not have "group commands" for FDs.
for fd in $(ls -1 /proc/27343/fd); do echo exec "$fd>&-"; done
Remove the echo
after testing.
If this is not for the shell itself but for a command to be run then you can use nohup
.
2
The file descriptor used by>&-
cannot be a parameter; the redirection is parsed prior to parameter expansion.
– chepner
Apr 7 '14 at 19:35
add a comment |
No. The kernel can close only one FD at a time, and bash does not have "group commands" for FDs.
for fd in $(ls -1 /proc/27343/fd); do echo exec "$fd>&-"; done
Remove the echo
after testing.
If this is not for the shell itself but for a command to be run then you can use nohup
.
2
The file descriptor used by>&-
cannot be a parameter; the redirection is parsed prior to parameter expansion.
– chepner
Apr 7 '14 at 19:35
add a comment |
No. The kernel can close only one FD at a time, and bash does not have "group commands" for FDs.
for fd in $(ls -1 /proc/27343/fd); do echo exec "$fd>&-"; done
Remove the echo
after testing.
If this is not for the shell itself but for a command to be run then you can use nohup
.
No. The kernel can close only one FD at a time, and bash does not have "group commands" for FDs.
for fd in $(ls -1 /proc/27343/fd); do echo exec "$fd>&-"; done
Remove the echo
after testing.
If this is not for the shell itself but for a command to be run then you can use nohup
.
edited Apr 7 '14 at 22:45
answered Apr 6 '14 at 18:51
Hauke Laging
55.6k1285133
55.6k1285133
2
The file descriptor used by>&-
cannot be a parameter; the redirection is parsed prior to parameter expansion.
– chepner
Apr 7 '14 at 19:35
add a comment |
2
The file descriptor used by>&-
cannot be a parameter; the redirection is parsed prior to parameter expansion.
– chepner
Apr 7 '14 at 19:35
2
2
The file descriptor used by
>&-
cannot be a parameter; the redirection is parsed prior to parameter expansion.– chepner
Apr 7 '14 at 19:35
The file descriptor used by
>&-
cannot be a parameter; the redirection is parsed prior to parameter expansion.– chepner
Apr 7 '14 at 19:35
add a comment |
Another way without "eval" at all, is to use the form:
$ exec var_a>> file.txt
$ echo $var_a
10
$ ls -l /proc/self/fd/10
l-wx------ 1 0 0 64 Dec 11 18:32 /proc/self/fd/10 -> /run/user/0/tmp/file.txt
$ echo "aaaaa" >&$var_a
$ cat file.txt
aaaaa
$ exec var_a>&-
$ ls /proc/self/fd/10
ls: cannot access '/proc/self/fd/10': No such file or directory
But this doesn't close all file descriptors.
– G-Man
Dec 11 at 18:04
Indeed. You'll have to exec in a loop like explained in the previous replies... It was just to point the fact that "eval" is not mandatory here and that we can keep the same logic to close it than to open it... Man pages are really not clear about this...
– David DG
Dec 11 at 18:11
add a comment |
Another way without "eval" at all, is to use the form:
$ exec var_a>> file.txt
$ echo $var_a
10
$ ls -l /proc/self/fd/10
l-wx------ 1 0 0 64 Dec 11 18:32 /proc/self/fd/10 -> /run/user/0/tmp/file.txt
$ echo "aaaaa" >&$var_a
$ cat file.txt
aaaaa
$ exec var_a>&-
$ ls /proc/self/fd/10
ls: cannot access '/proc/self/fd/10': No such file or directory
But this doesn't close all file descriptors.
– G-Man
Dec 11 at 18:04
Indeed. You'll have to exec in a loop like explained in the previous replies... It was just to point the fact that "eval" is not mandatory here and that we can keep the same logic to close it than to open it... Man pages are really not clear about this...
– David DG
Dec 11 at 18:11
add a comment |
Another way without "eval" at all, is to use the form:
$ exec var_a>> file.txt
$ echo $var_a
10
$ ls -l /proc/self/fd/10
l-wx------ 1 0 0 64 Dec 11 18:32 /proc/self/fd/10 -> /run/user/0/tmp/file.txt
$ echo "aaaaa" >&$var_a
$ cat file.txt
aaaaa
$ exec var_a>&-
$ ls /proc/self/fd/10
ls: cannot access '/proc/self/fd/10': No such file or directory
Another way without "eval" at all, is to use the form:
$ exec var_a>> file.txt
$ echo $var_a
10
$ ls -l /proc/self/fd/10
l-wx------ 1 0 0 64 Dec 11 18:32 /proc/self/fd/10 -> /run/user/0/tmp/file.txt
$ echo "aaaaa" >&$var_a
$ cat file.txt
aaaaa
$ exec var_a>&-
$ ls /proc/self/fd/10
ls: cannot access '/proc/self/fd/10': No such file or directory
edited Dec 11 at 17:48
answered Dec 11 at 17:40
David DG
12
12
But this doesn't close all file descriptors.
– G-Man
Dec 11 at 18:04
Indeed. You'll have to exec in a loop like explained in the previous replies... It was just to point the fact that "eval" is not mandatory here and that we can keep the same logic to close it than to open it... Man pages are really not clear about this...
– David DG
Dec 11 at 18:11
add a comment |
But this doesn't close all file descriptors.
– G-Man
Dec 11 at 18:04
Indeed. You'll have to exec in a loop like explained in the previous replies... It was just to point the fact that "eval" is not mandatory here and that we can keep the same logic to close it than to open it... Man pages are really not clear about this...
– David DG
Dec 11 at 18:11
But this doesn't close all file descriptors.
– G-Man
Dec 11 at 18:04
But this doesn't close all file descriptors.
– G-Man
Dec 11 at 18:04
Indeed. You'll have to exec in a loop like explained in the previous replies... It was just to point the fact that "eval" is not mandatory here and that we can keep the same logic to close it than to open it... Man pages are really not clear about this...
– David DG
Dec 11 at 18:11
Indeed. You'll have to exec in a loop like explained in the previous replies... It was just to point the fact that "eval" is not mandatory here and that we can keep the same logic to close it than to open it... Man pages are really not clear about this...
– David DG
Dec 11 at 18:11
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f123413%2fclose-all-file-descriptors-in-bash%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
All of which file descriptors? Every process has some open.
– Warren Young
Apr 6 '14 at 17:54