get filename from filehandle

[aotto1968]

Hi,

**file tempfile** create an temporary file and return a RW filehandle
→ good
If I want to use *this* file in an external tool like *less* etc I
need the filename → bad

question:

*how* I get the file-name from an open filehandle?


mfg

[Colin Macleod]

aotto1968 <aott...@t-online.de> wrote in news:td7t56$2q7ac$3@dont-
email.me:

Looking at the documentation for [file tempfile] -
https://www.tcl.tk/man/tcl8.6/TclCmd/file.html#M39 - it appears you need
to request the name when you create it by using the optional nameVar
argument.

There's no way to get it later from the filehandle - bear in mind that
an open file could have multiple names (when there are hard links to it
in the filesystem) or no name at all (when the file has been deleted but
still exists on disk because it is still open).

Colin.

[Schelte]

On 13/08/2022 13:28, Colin Macleod wrote:
> There's no way to get it later from the filehandle - bear in mind that
> an open file could have multiple names (when there are hard links to it
> in the filesystem) or no name at all (when the file has been deleted but
> still exists on disk because it is still open).
>

This is exactly what [file tempfile] (when invoked without a nameVar
argument) does on linux: It opens a file and then immediately deletes
it. Only because Tcl has an open handle to it, it can still be written
and read.

You can witness this as follows:
% set f [file tempfile]
file3
% file link /proc/[pid]/fd/[regsub {^file} $f {}]
/tmp/tcl_HKajFG (deleted)

So there is a platform-specific way to get the file from the file handle
on linux. But it will not help with providing access to the file to an
external tool. For that you will need to pass the varName argument to
[file tempfile].


Schelte.

[Steve Bennett]

Yes, it's a shame that Tcl doesn't support this.
c.f. Jim Tcl

. set f [open /etc/services]
::aio.handle5
. $f filename
/etc/services

[aotto1968]

Hi,

I think this is useful because TCL is a controlled environment this mean
every filehandle was crated by *open* *socket* etc…

→ there should be a general *attribute* function or *$FH attribute* method

example: FH from *open* return: FILE filename open access permission
> attribute $FH
> FILE /my/path/to/File RDWR 0666 → easy to parse

use cases:

1) cleanup temporary files after close socket
2) FH deep in "library"-code write better status/error message because *filename/type/openmode/permissions/* etc is known
3) from *socket* the FH has local and remote hostname and ip-address
4) MOST IMPORTANT no need to manage and track EXTRA variable(s) to store something line *filename* or *ip-address*

mfg

[Christian Werner]

aotto1...@gmail.com schrieb am Samstag, 13. August 2022 um 21:22:26 UTC+2:

> use cases:
>
> 1) cleanup temporary files after close socket
> 2) FH deep in "library"-code write better status/error message because *filename/type/openmode/permissions/* etc is known
> 3) from *socket* the FH has local and remote hostname and ip-address
> 4) MOST IMPORTANT no need to manage and track EXTRA variable(s) to store something line *filename* or *ip-address*

things to be considered indeed, so how about writing a more concise spec (ideally with a PoC implementation) in a TIP?

my 2%,
Christian

[et4]

If you've got the filehandle, then presumably it is from a call you make to [file] or some package that calls file. As a workaround, one could write a wrapper (using rename) for the file command, and then provide the filename arg to file tempfile. Then one might save handle vs. filenames in a global array where the array index is the filehandle.

One might also want to do the same for [close], which could then look up the name via the handle and delete the file as needed.

[Siri Cruise]

In article <td8tle$2t77e$1...@dont-email.me>,

aotto1968 <aott...@t-online.de> wrote:

> I think this is useful because TCL is a controlled environment this mean

> every filehandle was crated by *open* *socket* etcﾉ

>
> → there should be a general *attribute* function or *$FH attribute* method

Every open and socket has to be written by a human who can save
the information in an array.

It's not a useful idea on unices because there is no good way to
derive a directory path from a file designator. The directory
path can be changed and even deleted after an open.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|¥
Discordia: not just a religion but also a parody. This post / ¥
I am an Andrea Chen sockpuppet. insults Islam. Mohammed

[aotto1968]

On 14.08.22 02:36, Siri Cruise wrote:
> In article <td8tle$2t77e$1...@dont-email.me>,
> aotto1968 <aott...@t-online.de> wrote:
>
>> I think this is useful because TCL is a controlled environment this mean
>> every filehandle was crated by *open* *socket* etcﾉ
>>
>> → there should be a general *attribute* function or *$FH attribute* method
>
> Every open and socket has to be written by a human who can save
> the information in an array.
>
> It's not a useful idea on unices because there is no good way to
> derive a directory path from a file designator. The directory
> path can be changed and even deleted after an open.
>

I think the problem is *not* well understood

1. every FH in tcl was opened by TCL
2. TCL also knows *how* the FH was opened and has also the *attribute* data
3. the only problem is that the TCL "Tcl-Obj" technology requires that every
object is *string-able* so the attribute data have to be a dict like struct
with *one* attribute is the original (old) FH.
4. other possible attributes are:

a) HOW was the FH created (OPEN, SOCKET, PIPE etc)
b) depend on a) additional attributes are (temporary, filename, mode, ipaddress, hostname, command etc)

mfg

[aotto1968]

new usage for this feature, right now I have an error like:

error during seek on "stdout": invalid argument
while executing
"chan seek $FH 0"
(procedure "WriteFile" line 5)
invoked from within

this is deep in the library the FH is not seek-able.
The FH is *stdout*, usually the FH is an *open* file but for
debugging it is set to *stdout*.

I read the documentation and there is no info about how to
get the "attribute" *seekable* out of the FH.

now I have to use catch etc to make a "dirty(expensive)" check on *seekable*


mfg

[Rich]

aotto1968 <aott...@t-online.de> wrote:
> I read the documentation and there is no info about how to get the
> "attribute" *seekable* out of the FH.

The documentation provides a to tell if a file handle is seekable:

man n chan:

chan tell channelId
Returns a number giving the current access position within the
underlying data stream for the channel named channelId. This
value returned is a byte offset that can be passed to chan seek
in order to set the channel to a particular position. Note
that this value is in terms of bytes, not characters like chan
read. The value returned is -1 for channels that do not
support seeking.

Last sentence tells you how to detect file handles that do not support
seeking.

[Gerald Lester]

First off, it is a channel handle and not a file handle.

Second off, the "etc" can be a lot more things than you list --
including things that are user added.


--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+