[file join] with local network file address

[Ricardo kozmate.net]

Hi group.

There is something in the behaviour of [file join] that I am not
understanding (yes, I read the manual)

I have a script to copy files to a folder in a local network machine,
actually a queue in a printer. The computer running the script is on
Windows 7, TCL is 8.6.3. The printer uses Solaris, but I presume that is
irrelevant as the error is in creating the destination address not in
copying the file.

I created the destination address like this:

> set printer \\\\192.168.1.171\\queue
> file join $printer doc.ps
//192.168.1.171/queue/doc.ps

And that works fine.


Recently I add to use more than one queue, so I chnged it so something as:

> set printer \\\\192.168.1.171
> puts [file join $printer queue doc.ps]
/192.168.1.171/queue/doc.ps

Which is not the intended path, it has a leading '/', not '//' (one not
two /s )


But if I do

> set printer \\\\192.168.1.171\\\\
> puts [file join $printer queue doc.ps]
//192.168.1.171/queue/doc.ps

it works again! So my script works, which is great :-) But I do not like
"magical code", so...


Why does this one work but the preceding one does not?


By the way, note that

> set printer \\\\192.168.1.171\\
> puts [file join $printer queue doc.ps]
/192.168.1.171/queue/doc.ps

also results in a single leading \
which only makes the result all the more mysterious to me.

--
{ricardo from kozmate.net}

[Brad Lanam]

What version of Tcl did you have that problem in?

Someone else (Andy) ran into that recently also.
I consider it a bug.

Reference: (from the wiki): AMG: In Tcl 8.6.8, [file join //a/b] returns //a/b,
but in Tcl 8.7a1, [file join //a/b] returns /a/b. This got me in trouble
because I was trying to work with Windows UNC paths. In the end I just had to
concatenate strings and forgo [file join]. [file nativename] worked right, at
least.

I have created a ticket: https://core.tcl.tk/tcl/tktview/baf43873720f5e92ae1142b1fc8d343b3648b54
for version 8.7

[Robert Heller]

I wonder if the file command is even written to support NETBIOS network
addresses... In that the code is not detecting that you have NETBIOS network
addresses and the places where it works are just cases where you are lucking
out.

You make have to do this differently: maybe use string append logic at the
last minute to pre-pend the NETBIOS network address, like this maybe:

set printer \\\\192.168.1.171
puts "$printer\\[file nativename [fie join queue doc.ps]]"

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

[Brad Lanam]

Sheesh. Unless someone else steps forward to take on this ticket, they
are going to leave the broken code in. I am going to work on writing my
own file join. It is conceivable that users of my software could possibly
use a network path, and I don't want this bug to pop up.

[Brad Lanam]

On Thursday, July 26, 2018 at 4:49:28 PM UTC-7, Ricardo kozmate.net wrote:

So the way file join works is that //myprinter/myqueue is a valid network path,
but just //myprinter by itself is not a valid network path, so the
assumption is that it is a normal path, and the leading // is changed
to a single /.

So any specication of the network path must be of the form
//host/location, and not just //host.

[Ricardo kozmate.net]

Em 27/07/18 02:21, Brad Lanam escreveu:

> What version of Tcl did you have that problem in?

8.6.3 tombert's binaries for Windows (used on windows 7)

I know it is oldish, but at work I do not have internet access nor
coding is my main task (actually coding it is not any of my tasks, but I
still do it, to help in a few repetitive or confusing tasks :-) so I
only update every couple years, or more...

--
{ricardo from kozmate.net}

[Ricardo kozmate.net]

Em 27/07/18 18:59, Brad Lanam escreveu:

> So the way file join works is that //myprinter/myqueue is a valid network path,
> but just //myprinter by itself is not a valid network path, so the
> assumption is that it is a normal path, and the leading // is changed
> to a single /.
>
> So any specication of the network path must be of the form
> //host/location, and not just //host.

Yes, that is my guess too.

The interesting thing to me is that a "void" path, as in

set printer \\\\192.168.1.171\\\\
-> \\192.168.1.171\<zero-length-path-here?!>\

also works. I wouldn't know if it is a bug missing some cases, or luck
(bug?) that some cases work.

I see there is a long discussion on the ticket but I have not read it
all. I think there is not much I can help there.

Thanks

--
{ricardo from kozmate.net}

[Ricardo kozmate.net]

Em 27/07/18 02:38, Robert Heller escreveu:

> set printer \\\\192.168.1.171
> puts "$printer\\[file nativename [fie join queue doc.ps]]"

Interesting. I'll try that this next week if I have the time. At least
it will make the code more robust, not counting on a dubious feature
which may change in the bear future. Thank you

--
{ricardo from kozmate.net}

[Ricardo kozmate.net]

Em 27/07/18 02:38, Robert Heller escreveu:

> At Fri, 27 Jul 2018 00:49:25 +0100 "Ricardo kozmate.net" <ric...@kozmate.net> wrote:
>

>> [...]

>> Recently I add to use more than one queue, so I chnged it so something as:
>>
>> > set printer \\\\192.168.1.171
>> > puts [file join $printer queue doc.ps]
>> /192.168.1.171/queue/doc.ps
>>
>> Which is not the intended path, it has a leading '/', not '//' (one not
>> two /s )

>> [...]

>>
>
> I wonder if the file command is even written to support NETBIOS network

> addresses [...] the places where it works are just cases where you are lucking
> out.
>
> You make have to do [...] like this maybe:

>
> set printer \\\\192.168.1.171
> puts "$printer\\[file nativename [fie join queue doc.ps]]"
>

Done.
Seems to work just fine, and hopefully more robust, not trusting on a
(possibly) lucky feature that might change anytime.
Thank you.

--
{ricardo from kozmate.net}