I'm following the manual of tar package to unpack a specific file into a specific directory.

I'm using this command

tar::untar $fid -file $path -dir $targetdir -chan

The manual states:

::tar::untar tarball args

-dir dirName Directory to extract to. Uses pwd if none is specified
-file fileName Only extract the file with this name. The name is matched against the complete path stored in the archive including directories.

The thing is, the file is extracted to a location which is the directory name of the archived file. So the -dir option has no effect.
I'm assuming that the manual is not consistent with the source code.
Is this true or am I wrong?

Thanks
Alexandru

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alexandru <alexandru.dadalau@meshparts.de> wrote:

The thing is, the file is extracted to a location which is the
directory name of the archived file. So the -dir option has no
effect.

I'm assuming that the manual is not consistent with the source code.
Is this true or am I wrong?

You have the source code to the tar module. A little looking into that
file and you can answer your own question about why, with your inputs
[*], the code is not acting in the way you expect based on what the documentation says.



[*] This part is rather important. We could look, but without knowing
what the exact strings were, we might miss the reason why it seems to
be not working as documented for you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alexandru <alexandru.dadalau@meshparts.de> wrote:

Rich schrieb am Dienstag, 25. Oktober 2022 um 14:45:56 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

The thing is, the file is extracted to a location which is the
directory name of the archived file. So the -dir option has no
effect.

I'm assuming that the manual is not consistent with the source code.
Is this true or am I wrong?

You have the source code to the tar module. A little looking into that
file and you can answer your own question about why, with your inputs
[*], the code is not acting in the way you expect based on what the
documentation says.



[*] This part is rather important. We could look, but without knowing
what the exact strings were, we might miss the reason why it seems to
be not working as documented for you.

Thanks. Indeed, I looked now and it seems, that the documentation is promissing somthing that is not implemented in the code. According
to the docs, the -file option can be a full path, not only the "tail"
of the path:

-file fileName Only extract the file with this name. The name is
matched against the complete path stored in the archive including directories.

That's not my reading of the documentation for -file.

The docs state the string given to "-file" is "matched against the full
path" which is stored in the tar file. It is defining how the string
given to -file is used to decide if a tar entry is suitable for
extraction, but not explicitly stating that the -file string should be
a full path itself. Note that it also does not exclude the string
given to -file from being a partial or full path, so at best it is
slightly ambigious as to whether the code was written to provide for
the string given as the -file parameter containing a path and a name simultaneously.

The dir option only states:

-dir dirName Directory to extract to. Uses pwd if none is
specified

So it should work with both full path names and path tails.

I'd say it is ambigious when -file is a full path (from the docs
alone).

In the untar procedure, the row 34 does

set name [file join $dir $name]

So it assumes, that, when dir is specified, the name is only the tail
or at least a relative to dir.

Would you confirm the above?

You are correct as to line 34, but you missed mentioning line 28 which
does:

set name [string trimleft $header(prefix)$header(name) /]

Which, provided name is not a windows path with drive letter, would
convert name into a relative path. Note that 'name' is the name stored
inside the tar header for the file.

I'm betting your tar file contains entries with names that look like
this:

c:/Users/User/dir/dir/file

And so line 28 is not removing leading / characters because of the
stupid windows drive letter leftover from the msdos world.

I will modify the source code and see if I can commit it to the
repository.

Yes, there is a 'bug', in that the code did not consider the possible
full path names that can occur from windows when converting names from
the tar file into relative paths.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich schrieb am Dienstag, 25. Oktober 2022 um 14:45:56 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

The thing is, the file is extracted to a location which is the
directory name of the archived file. So the -dir option has no
effect.

I'm assuming that the manual is not consistent with the source code.
Is this true or am I wrong?

You have the source code to the tar module. A little looking into that
file and you can answer your own question about why, with your inputs
[*], the code is not acting in the way you expect based on what the documentation says.

[*] This part is rather important. We could look, but without knowing
what the exact strings were, we might miss the reason why it seems to
be not working as documented for you.

Thanks. Indeed, I looked now and it seems, that the documentation is promissing somthing that is not implemented in the code.
According to the docs, the -file option can be a full path, not only the "tail" of the path:

-file fileName Only extract the file with this name. The name is matched against the complete path stored in the archive including directories.

The dir option only states:

-dir dirName Directory to extract to. Uses pwd if none is specified

So it should work with both full path names and path tails.

In the untar procedure, the row 34 does

set name [file join $dir $name]

So it assumes, that, when dir is specified, the name is only the tail or at least a relative to dir.

Would you confirm the above?

I will modify the source code and see if I can commit it to the repository.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

About fixing the bug...
I'll nee a function that checks if a file path is absolute or not.
I was thinking something like this below, but not sure if this still works for Linux OS:

proc ::tar::isabsolute {path} {
return [expr {[string match -nocase [file normalize $path] $path]}]
}

Is this platform independent?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Rich schrieb am Dienstag, 25. Oktober 2022 um 16:07:08 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

Rich schrieb am Dienstag, 25. Oktober 2022 um 14:45:56 UTC+2:

Alexandru <alexandr...@meshparts.de> wrote:

The thing is, the file is extracted to a location which is the
directory name of the archived file. So the -dir option has no
effect.

I'm assuming that the manual is not consistent with the source code.
Is this true or am I wrong?

You have the source code to the tar module. A little looking into that
file and you can answer your own question about why, with your inputs
[*], the code is not acting in the way you expect based on what the
documentation says.



[*] This part is rather important. We could look, but without knowing
what the exact strings were, we might miss the reason why it seems to
be not working as documented for you.

Thanks. Indeed, I looked now and it seems, that the documentation is promissing somthing that is not implemented in the code. According
to the docs, the -file option can be a full path, not only the "tail"
of the path:

-file fileName Only extract the file with this name. The name is
matched against the complete path stored in the archive including directories.

That's not my reading of the documentation for -file.

The docs state the string given to "-file" is "matched against the full
path" which is stored in the tar file. It is defining how the string
given to -file is used to decide if a tar entry is suitable for
extraction, but not explicitly stating that the -file string should be
a full path itself. Note that it also does not exclude the string
given to -file from being a partial or full path, so at best it is
slightly ambigious as to whether the code was written to provide for
the string given as the -file parameter containing a path and a name simultaneously.

The dir option only states:

-dir dirName Directory to extract to. Uses pwd if none is
specified

So it should work with both full path names and path tails.

I'd say it is ambigious when -file is a full path (from the docs
alone).

In the untar procedure, the row 34 does

set name [file join $dir $name]

So it assumes, that, when dir is specified, the name is only the tail
or at least a relative to dir.

Would you confirm the above?

You are correct as to line 34, but you missed mentioning line 28 which
does:

set name [string trimleft $header(prefix)$header(name) /]

Which, provided name is not a windows path with drive letter, would
convert name into a relative path. Note that 'name' is the name stored
inside the tar header for the file.

I'm betting your tar file contains entries with names that look like
this:

c:/Users/User/dir/dir/file

And so line 28 is not removing leading / characters because of the
stupid windows drive letter leftover from the msdos world.

I will modify the source code and see if I can commit it to the
repository.

Yes, there is a 'bug', in that the code did not consider the possible
full path names that can occur from windows when converting names from
the tar file into relative paths.

Okay, I will fix the bug (note: without the quoting signs :)

Another thing, about the -prefix option:
-prefix string Normally add will store files under exactly the name specified as argument. Specifying a ?-prefix? causes the string to be prepended to every name.

Looking at the source code, the <prefix> and a slash is prepended to the name! This is clearly not what the manual states.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alexandru,

Use the Tcl command "file pathtype" for this task.

Paul

Am 25.10.2022 um 18:38 schrieb Alexandru:

About fixing the bug...
I'll nee a function that checks if a file path is absolute or not.
I was thinking something like this below, but not sure if this still works for Linux OS:

proc ::tar::isabsolute {path} {
return [expr {[string match -nocase [file normalize $path] $path]}]
}

Is this platform independent?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul Obermeier schrieb am Dienstag, 25. Oktober 2022 um 19:16:14 UTC+2:

Hi Alexandru,

Use the Tcl command "file pathtype" for this task.

Paul
Am 25.10.2022 um 18:38 schrieb Alexandru:

About fixing the bug...
I'll nee a function that checks if a file path is absolute or not.
I was thinking something like this below, but not sure if this still works for Linux OS:

proc ::tar::isabsolute {path} {
return [expr {[string match -nocase [file normalize $path] $path]}]
}

Is this platform independent?

Thanks Paul, completly forgot about that one (I'm actually using it in my code).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I've proposed changes that fix the issue: https://github.com/tcltk/tcllib/compare/master...Meshparts:tcllib:patch-1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)