vorakl
Joined 2 years ago
Joined 2 years ago
If a filename begins with a <period> ( '.' ), the <period> shall be explicitly
matched by using a <period> as the first character of the pattern or immediately
following a <slash> character. The leading <period> shall not be matched by:
* The <asterisk> or <question-mark> special characters
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...Interesting fact about the FreeBSD tar's origins:
GNU tar was included as the standard system tar in
FreeBSD beginning with FreeBSD 1.0.
This is a complete re-implementation based
on the libarchive(3) library. It was first released with
FreeBSD 5.4 in May, 2005.
https://man.freebsd.org/cgi/man.cgi?query=tarMy personal journey with FreeBSD began with version 5.3 (the first stable release on the 5th branch) in November 2004. I was completely unaware of such a significant tar change, and apparently I didn't care at the time. However, the entire 5th branch has been so revolutionary compared to the 4th branch that this change is just a drop in the bucket ;)
I'm asking this because I was trying to reproduce the same situation and everything seems to be working fine:
$ tar -C /tmp/root3 -cvf test.tar .
./
./.config/
./.config/test
./.local/
./var/
./var/db/
./var/db/xbps/
or even like this $ tar -cvf test2.tar root3/
root3/
root3/.config/
root3/.config/test
root3/.local/
root3/var/
root3/var/db/
root3/var/db/xbps/
No special options were needed. But, if I do it this way, then, there are definitely missing all dot directories: $ tar -cvf test2.tar root3/*
root3/usr/
root3/usr/bin/
root3/usr/bin/xbps-uunshare
But this problem is not a tar's problem. That's only because "*" mask doesn't match dot files: $ echo root3/*
root3/usr root3/var
For that purpose, you need to clearly add a dot: $ echo root3/.*
root3/.config root3/.local
Thus, the solution might be $ tar -cvf test2.tar root3/.* root3/*
root3/.config/
root3/.config/test
root3/.local/
root3/usr/
root3/usr/bin/
But, I'd rather stick to "-C dir/" option instead of relying on "*" mask in this case.To add absolute paths to an archive, there is "-P" option, and man says it works only for creating archives: "Don't strip leading slashes from filenames when creating archives".
To extract absolute paths from the archive, you need to add the "-C /" option, and although the tool says "tar: Strip leading `/' from member names", it will still extract it in the right place because the paths become relative and -C puts them in the root.
However, if you add "-P" during the extraction (which is not mentioned in man), the "strip leading slashes" information disappears.
So if this message bothers someone, "tar -C / -xPf file.tar" will cleanly extract absolute paths from the archive ;)
This is a really good point! It solves the main problem. I'll add it to the article.
Although that's what, unfortunately, is set by default (at least in GNU tar):
--overwrite-dir (Overwrite metadata of existing directories when extracting (default).)
"Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in."
"Furthermore, on systems that support executable scripts (the "#!" construct), it is recommended that applications using executable scripts install them using getconf PATH to determine the shell pathname and update the "#!" script appropriately as it is being installed (for example, with sed)."
Ref: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...
So, apparently on systems, where sh resides in /bin, "getconf CONF" will return /bin . However, this is not always the case. For example, on my Fedora Linux it is /usr/bin
$ getconf PATH
/usr/bin
$ ls -l /usr/bin/sh
lrwxrwxrwx. 1 root root 4 Jan 2 2023 /usr/bin/sh -> bash
$ ls -l /bin/sh
lrwxrwxrwx. 1 root root 4 Jan 2 2023 /bin/sh -> bash
$ ls -ld /bin
lrwxrwxrwx. 1 root root 7 Aug 9 2022 /bin -> usr/bin"2.4 Other Language-Related Specifications
POSIX.1-2017 is currently specified in terms of the shell command language and ISO C. Bindings to other programming languages are being developed."
I've added a few words and links to other "utilities".
I referred here to the following definition:
"2.4 Other Language-Related Specifications POSIX.1-2017 is currently specified in terms of the shell command language and ISO C. Bindings to other programming languages are being developed."
But, you are definitely right that some of the tools, defined as standard "utilities", such as AWK, also have their own language. Although, it is only defined in the "utilities" section, https://pubs.opengroup.org/onlinepubs/9699919799/utilities/a... However, "sh" is also defined under "utilities", although it has an extensive language specification that is provided as a separate document.