Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #11737

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

Show all headers | View raw

Bob Proulx wrote:
> Linda Walsh wrote:
> 
> Where does the OS claim it is a file descriptor?
---

1) in the kernel documentation:
file 'devices.txt:
/dev/fd		/proc/self/fd	symbolic	File descriptors

2) ls -Ll shows the type of what the symlink points to:
> ls -Ll /dev/fd/
total 0
crw--w---- 1 law tty      136, 0 Oct 21 19:49 0
crw--w---- 1 law tty      136, 0 Oct 21 19:49 1
crw--w---- 1 law tty      136, 0 Oct 21 19:49 2
---

and 3)

 YOU claim it is a descriptor further down in this note:
>   tmpname=<(sort /dev/null); ls -l "$tmpname"
>     ls: cannot access /dev/fd/63: No such file or directory
> 
> But as soon as the first commend is finished at the ';' then the
> descriptor will be closed and the path will evaporate.  Therefore the
  ^^^^^^^^^^^^^^^^^^^^^^^^^
> path won't exist for the second command.
---
	If you close a file-descriptor to a normal file
it doesn't disappear.  If it was deleted via 'rm' the name disappears
immediately, and the only access to it is through the descriptor.

In this case, closing the descriptor deletes the temporary
name in the process's 'file descriptor' "/fd/".  Normal filenames
are not "auto-deleted" when you close an I/O handle to them.


> But if you use it for the ls command itself then it exists for that
> command.
> 
>   ls -l <(sort /dev/null)
>     lr-x------ 1 rwp rwp 64 Oct 19 15:56 /dev/fd/63 -> pipe:[102059434]
----
	But only as a pointer to something one can do I/O on.
You can't set any file attributes or metadata on "pipe:[xxxx]" 
It's not a real file somewhere.

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes? Linda Walsh <bash@tlinx.org> - 2015-10-21 19:57 -0700

csiph-web