You can use command lsof to get file descriptors for all running processes, but what I would like to do is to close some of those descriptors without being inside that process. This can be done on Windows, so you can easily unblock some application.
Is there any command or function for that?
In Windows you can use a program to do it because someone wrote a program that inserts a device driver into the running kernel to do it. By the way it can be dangerous to do this, because after you close a handle that a broken application was using, the application doesn't know that the handle was closed, and when the application opens some other unrelated object it doesn't know that the same handle might now refer to some other unrelated object. You really want to kill the broken application as soon as possible.
In Linux surely you can use the same kind of technique. Write a program that inserts a module into the running kernel. Communicate with the module and tell it which handles to close. It will be equally dangerous to do so.
I doubt it. File descriptors are process-local, stdout is 1 to all processes, yet they still reference unique streams of course.
Perhaps more detail would be useful, about the blocking problem you're trying to solve.
I don't think so but lsof gives you the PID of the process that has opened the file, so what you can do is entirely kill the process or at least send a signal to let it exit.
I don't know why you are trying to do this, but you should be able to attach to the process using gdb and then call close() on the fd. Example:
In one shell: cat
In another shell:
$pidof cat
7213
$gdb -p 7213
... lots of output ...
(gdb)
Now you tell gdb to execute close(0):
(gdb) p close(0)
$1 = 0
(gdb) c
Continuing.
Program exited with code 01. (gdb)
In the first shell I get this output:
cat: -: Bad file descriptor
cat: closing standard input: Bad file descriptor
There is much less need to do this on Unix than on Windows.
On Windows, most programs tend to "lock" (actually deny sharing) the files they open, so they cannot be read/written/deleted by another program.
On Unix, most of the time this does not happen. File locking on Unix is mostly advisory, and will only block other locking attempts, not normal read/write/delete operations. You can even remove the current directory of a process.
About the only situation this comes up in normal usage in Unix is when trying to umount a filesystem (any reference at all to the mounted filesystem can block the umount).