file channels

[Cecil Westerhof]

Just playing with 'file channels'. I wrote the following program:
#!/usr/bin/env tclsh

package require sqlite3

puts "Start: [file channels]"
set fileHndl [open dummy.txt]
puts "Opened file: [file channels]"
sqlite3 db dummy.sqlite
puts "Opened db: [file channels]"
puts "Version db: [db version]"
db close
close ${fileHndl}
puts "End: [file channels]"

This generates the following output:
Start: stdin stdout stderr
Opened file: stdin stdout stderr file3
Opened db: stdin stdout stderr file3
Version db: 3.16.2
End: stdin stdout stderr

After opening a file I see an extra channel as expected. But after
open the sqlite3 database I do not see an extra channel.
Why is this?

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[Rich]

Cecil Westerhof <Ce...@decebal.nl> wrote:
> Just playing with 'file channels'. I wrote the following program:
> #!/usr/bin/env tclsh
>
> package require sqlite3
>
> puts "Start: [file channels]"
> set fileHndl [open dummy.txt]
> puts "Opened file: [file channels]"
> sqlite3 db dummy.sqlite
> puts "Opened db: [file channels]"
> puts "Version db: [db version]"
> db close
> close ${fileHndl}
> puts "End: [file channels]"
>
> This generates the following output:
> Start: stdin stdout stderr
> Opened file: stdin stdout stderr file3
> Opened db: stdin stdout stderr file3
> Version db: 3.16.2
> End: stdin stdout stderr
>
> After opening a file I see an extra channel as expected. But after
> open the sqlite3 database I do not see an extra channel.
> Why is this?

Because the sqlite database is not a Tcl "file channel". The file
access is handled internally by the sqlite3 library, and Tcl interacts
with the Tcl API that sqlite3 exposes, not with the raw underlying
file.

[Robert Heller]

At Sat, 05 May 2018 14:37:54 +0200 Cecil Westerhof <Ce...@decebal.nl> wrote:

>
> Just playing with 'file channels'. I wrote the following program:
> #!/usr/bin/env tclsh
>
> package require sqlite3
>
> puts "Start: [file channels]"
> set fileHndl [open dummy.txt]
> puts "Opened file: [file channels]"
> sqlite3 db dummy.sqlite
> puts "Opened db: [file channels]"
> puts "Version db: [db version]"
> db close
> close ${fileHndl}
> puts "End: [file channels]"
>
> This generates the following output:
> Start: stdin stdout stderr
> Opened file: stdin stdout stderr file3
> Opened db: stdin stdout stderr file3
> Version db: 3.16.2
> End: stdin stdout stderr
>
> After opening a file I see an extra channel as expected. But after
> open the sqlite3 database I do not see an extra channel.
> Why is this?

There is no "Tcl Channel" when the database is opened. The sqlite3 DB library
does that internally. The "file channels" is only going to report (return)
the channels *Tcl* knows about and were opened with the Tcl_Channel API. If a
extension library calls a C library function to open a file (eg open(),
creat(), fopen(), socket(), etc.), *Tcl* doesn't know about it, unless the
extension library is specificly using the Tcl_Channel API and exposing a
channel to Tcl that way.

>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Cecil Westerhof]

That makes sense. Thank you.

[Cecil Westerhof]

Cecil Westerhof <Ce...@decebal.nl> writes:

> Just playing with 'file channels'. I wrote the following program:
> #!/usr/bin/env tclsh
>
> package require sqlite3
>
> puts "Start: [file channels]"
> set fileHndl [open dummy.txt]
> puts "Opened file: [file channels]"
> sqlite3 db dummy.sqlite
> puts "Opened db: [file channels]"
> puts "Version db: [db version]"
> db close
> close ${fileHndl}
> puts "End: [file channels]"
>
> This generates the following output:
> Start: stdin stdout stderr
> Opened file: stdin stdout stderr file3
> Opened db: stdin stdout stderr file3
> Version db: 3.16.2
> End: stdin stdout stderr
>
> After opening a file I see an extra channel as expected. But after
> open the sqlite3 database I do not see an extra channel.
> Why is this?

This problem is solved.

But I saw something else I find interesting.
When the script opens a file it uses file3.
When I open an interactive shell it opens file5. Otherwise it is the
same. What could be the reason for this?

[Robert Heller]

The number at the end is the fd number returned by open() (or creat()).

The most likely reason is somewhere along the line open() or creat() was
called a couple of times, I guessing when running interactively, the tty
channels got re-opened().

Does it really matter? You really should not be depending on partitular fd#s,
although fds 0, 1, and 2 are pretty much given as stdin, stdout, and stderr
for any UNIX / Posix process.

[Rich]

Cecil Westerhof <Ce...@decebal.nl> wrote:
> But I saw something else I find interesting.
> When the script opens a file it uses file3.
> When I open an interactive shell it opens file5. Otherwise it is the
> same. What could be the reason for this?

Don't worry about that.

Treat the strings returned from [open] as opaque identifiers with no
extra meaning and you'll be just fine.

And for stdin/stdout/stderr, use the names stdin, stdout (although this
is the default for puts anyway) and stderr.

[Cecil Westerhof]

No, it does not really matter, but I am just curious. :-D
It is consistent: in the script it is always file3 and interactive it
is always file5.

Maybe interactively there are two hidden files that are open? Because
when I keep opening and closing, I keep getting back file5. So it
looks like file3 and file4 are used for something else.

[Robert Heller]

Probably something to do with ttys (maybe used up with isatty or something).

[Gerald Lester]

I'm betting one was .tclshrc and the other something used by it -- or
maybe both are something referenced by .tclshrc.

From the tclsh man/help page: There is no automatic evaluation of
.tclshrc when the name of a script file is presented on the tclsh
command lin



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

[Robert Heller]

There is also .wishrc...

Maybe a [package require ...] in .tclshrc or .wishrc...

>
> From the tclsh man/help page: There is no automatic evaluation of
> .tclshrc when the name of a script file is presented on the tclsh
> command lin
>
>
>

--

[Donal K. Fellows]

On 05/05/2018 18:19, Cecil Westerhof wrote:
> Maybe interactively there are two hidden files that are open?

There might be, or there might have been at the point when the channel
was opened. It's not something that we provide any mechanism to talk
about meaningfully. (If you're on Linux, you might be able to guess
what's going on from information in /proc, but that's non-portable.)

Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.

[Cecil Westerhof]

"Donal K. Fellows" <donal.k...@manchester.ac.uk> writes:

> On 05/05/2018 18:19, Cecil Westerhof wrote:
>> Maybe interactively there are two hidden files that are open?
>
> There might be, or there might have been at the point when the channel
> was opened. It's not something that we provide any mechanism to talk
> about meaningfully. (If you're on Linux, you might be able to guess
> what's going on from information in /proc, but that's non-portable.)

I am, but for the moment I let it rest. Something to put on the list
of things to do when I am bored. ;-)

[Rich]

Cecil Westerhof <Ce...@decebal.nl> wrote:
> "Donal K. Fellows" <donal.k...@manchester.ac.uk> writes:
>
>> On 05/05/2018 18:19, Cecil Westerhof wrote:
>>> Maybe interactively there are two hidden files that are open?
>>
>> There might be, or there might have been at the point when the channel
>> was opened. It's not something that we provide any mechanism to talk
>> about meaningfully. (If you're on Linux, you might be able to guess
>> what's going on from information in /proc, but that's non-portable.)
>
> I am, but for the moment I let it rest. Something to put on the list
> of things to do when I am bored. ;-)

The two extra fs's are the read and write ends of a pipe that tclsh (or
wish) has open. Beyond that /proc/pid/fd gives no information.

[briang]

That would be the event loop connection in a threaded build of tcl. The pipes are used between the event loop and each interpreter thread. These pipes will not show up in the file channel list since they are internal.

-Brian