Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail From: Linda Walsh Newsgroups: gnu.bash.bug Subject: Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes? Date: Wed, 21 Oct 2015 19:57:22 -0700 Lines: 51 Approved: bug-bash@gnu.org Message-ID: References: <56218DA5.8030501@tlinx.org> <5622CDC8.2030102@case.edu> <5622EB23.6020700@tlinx.org> <20151019122800.GS27325@eeg.ccf.org> <56254945.6020606@tlinx.org> <20151019154705253009402@bob.proulx.com> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1445482655 3924 208.118.235.17 (22 Oct 2015 02:57:35 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org User-Agent: Thunderbird In-Reply-To: <20151019154705253009402@bob.proulx.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 173.164.175.65 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:11737 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.