Re: [dev] [sbase][tar] GNU tar support
*** Hadrien Lacour [2020-11-25 19:27]: >The tl;dr is that you either use POSIX ustar with its path length and file size >limits, or use GNU tar when your input doesn't fit; pax was supposed to be the >replacement, but is more or less unused/ignored. In my opinion it is better to improve pax support, than to deal with (agreed) proprietary GNU ones, as it is a long time POSIX standard. FreeBSD's tar, using libarchive, by default makes ustar, and fallbacks to pax if something can not be stored in ustar (sizes, filenames, other metainformation). Moreover, that is much more important comparing to GNU tar: pax is backward compatible with ustar. Every kind of metainformation that can not be explicitly stored in ustar will look like subdirectory with key-value files in pax and can be *extracted* anyway. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
Re: [dev] [sbase][tar] GNU tar support
On Wed, 25 Nov 2020 22:49:32 +0100 Mattias Andrée wrote: Dear Mattias, > Concerning farbfeld, it is quite a different thing to create a new > simpler standard than supporting an already existing but complex > standard. Farbfeld was a good first step in moving towards simpler > image formats, although even if would have got exceptionally good > traction it would take quiet some time before support for older > complex formats could be removed, and in the meantime support for an > additional, but simple, format would be required which would add code > (not complexity) to image format libraries. I think this is forth it > in the long run, and it gave us a good standard format for programs, > that don't need to support user provided files, to use, better than > the netpbm formats. yes, well put! It would be different if I extended the NetPBM format with new things that would be incompatible with all other NetPBM-decoders. Of course I wouldn't be able to do it, but the absolute dominance of GNU tools in the 90's and 2000's has given them this opportunity and they seized it. I sometimes wish I would've started programming in the 90's and been able to influence the ecosystem with suckless software. Imagine musl being published in the 90's; it would've been revolutionary and we wouldn't have to deal with the millions of lines of C-code infested with GNU extensions. With best regards Laslo
Re: [dev] [sbase][tar] GNU tar support
On Wed, 25 Nov 2020 18:32:36 +0100 Thomas Oltmann wrote: Dear Thomas, > > if gnu tar proprietary? > > No. I think Laslo meant 'proprietary' as in 'ad hoc' or 'incompatible' > (with standard implementations). yeah, I used a pretty "drastic" word to describe it. All will agree that GNU-tar is non-standard, and I think in a way also "proprietary", as it only belongs to one implementation. > While I generally agree with Laslo, I'm in favor of supporting *a > select few* of GNU tar's extensions. > Granted, most of them are pretty niche (insane), like support for > files that span over multiple volumes. > But there's at least one useful extension: Long file name support. > That extension is also what Cág's error message "unsupported > tar-filetype L" is about. > I'm pretty confident that, with this extension alone, you would be > able to at least extract most GNU tar archives. > > I could try writing a patch for this, if people are interested. That indeed sounds interesting! With best regards Laslo
Re: [dev] [sbase][tar] GNU tar support
Hi all, Laslo Hunhold wrote: > Dear Cág, > Even if a suckless implementation of GNU tar was possible, would you > really want it to be included? I'd rather like to encourage people to > use standard non-proprietary file formats. Yeah, I think I would. tar(1) is one of those cases where a compromise between being suckless and being usable has to be found. suckless (or was it just you haha) made their own image format, for example, but there is a level of compatibility (i.e. jpg/png converters are bundled). You can say that JavaScript is bad and all but without it you can't browse the web. You can say the same about C++ but a modern Unix desktop can't exist without it. The compatibility article Hadrien linked claims that all examined variants support GNU tar. -- caóc
Re: [dev] [sbase][tar] GNU tar support
> if gnu tar proprietary? No. I think Laslo meant 'proprietary' as in 'ad hoc' or 'incompatible' (with standard implementations). > there's probably no way to implement those GNU-extensions in a good and > suckless way. The FSF has the bad habit for their > standard-implementations that they tend to add everything including the > kitchen sink which might as well be easily handled by other standard > tools (think of "cat -v" for example). While I generally agree with Laslo, I'm in favor of supporting *a select few* of GNU tar's extensions. Granted, most of them are pretty niche (insane), like support for files that span over multiple volumes. But there's at least one useful extension: Long file name support. That extension is also what Cág's error message "unsupported tar-filetype L" is about. I'm pretty confident that, with this extension alone, you would be able to at least extract most GNU tar archives. I could try writing a patch for this, if people are interested. Cheers, Thomas
Re: [dev] [sbase][tar] GNU tar support
On Wed, 25 Nov 2020 16:28:02 -0500 Cág wrote: > Hi all, > > Laslo Hunhold wrote: > > Dear Cág, > > Even if a suckless implementation of GNU tar was possible, would you > > really want it to be included? I'd rather like to encourage people to > > use standard non-proprietary file formats. > > Yeah, I think I would. tar(1) is one of those cases where a compromise > between being suckless and being usable has to be found. suckless (or was > it just you haha) made their own image format, for example, but there is > a level of compatibility (i.e. jpg/png converters are bundled). > > You can say that JavaScript is bad and all but without it you can't browse > the web. You can say the same about C++ but a modern Unix desktop can't > exist without it. > > The compatibility article Hadrien linked claims that all examined variants > support GNU tar. > I'm not sure what special with GNU tar, but the ability to read tar files of all common formats I would say is desirable, however not creating new tar files in those formats. Concerning farbfeld, it is quite a different thing to create a new simpler standard than supporting an already existing but complex standard. Farbfeld was a good first step in moving towards simpler image formats, although even if would have got exceptionally good traction it would take quiet some time before support for older complex formats could be removed, and in the meantime support for an additional, but simple, format would be required which would add code (not complexity) to image format libraries. I think this is forth it in the long run, and it gave us a good standard format for programs, that don't need to support user provided files, to use, better than the netpbm formats.
Re: [dev] [sbase][tar] GNU tar support
if gnu tar proprietary? Nov 25, 2020, 16:49 by d...@frign.de: > On Wed, 25 Nov 2020 07:51:22 -0500 > Cág wrote: > > Dear Cág, > >> A quick question: for "POSIX tar archive (GNU)" files tar prints >> tar: unsupported tar-filetype L >> >> Is GNU tar support out of scope? >> > > there's probably no way to implement those GNU-extensions in a good and > suckless way. The FSF has the bad habit for their > standard-implementations that they tend to add everything including the > kitchen sink which might as well be easily handled by other standard > tools (think of "cat -v" for example). > > Even if a suckless implementation of GNU tar was possible, would you > really want it to be included? I'd rather like to encourage people to > use standard non-proprietary file formats. > > With best regards > > Laslo >
Re: [dev] [sbase][tar] GNU tar support
On Wed, Nov 25, 2020 at 05:49:56PM +0100, Laslo Hunhold wrote: > On Wed, 25 Nov 2020 07:51:22 -0500 > Cág wrote: > > Dear Cág, > > > A quick question: for "POSIX tar archive (GNU)" files tar prints > > tar: unsupported tar-filetype L > > > > Is GNU tar support out of scope? > > there's probably no way to implement those GNU-extensions in a good and > suckless way. The FSF has the bad habit for their > standard-implementations that they tend to add everything including the > kitchen sink which might as well be easily handled by other standard > tools (think of "cat -v" for example). > > Even if a suckless implementation of GNU tar was possible, would you > really want it to be included? I'd rather like to encourage people to > use standard non-proprietary file formats. > > With best regards > > Laslo > This portability report https://mgorny.pl/articles/portability-of-tar-features.html might help a bit. The tl;dr is that you either use POSIX ustar with its path length and file size limits, or use GNU tar when your input doesn't fit; pax was supposed to be the replacement, but is more or less unused/ignored. Regards
Re: [dev] [sbase][tar] GNU tar support
On Wed, 25 Nov 2020 07:51:22 -0500 Cág wrote: Dear Cág, > A quick question: for "POSIX tar archive (GNU)" files tar prints > tar: unsupported tar-filetype L > > Is GNU tar support out of scope? there's probably no way to implement those GNU-extensions in a good and suckless way. The FSF has the bad habit for their standard-implementations that they tend to add everything including the kitchen sink which might as well be easily handled by other standard tools (think of "cat -v" for example). Even if a suckless implementation of GNU tar was possible, would you really want it to be included? I'd rather like to encourage people to use standard non-proprietary file formats. With best regards Laslo
[dev] [sbase][tar] GNU tar support
Hi, A quick question: for "POSIX tar archive (GNU)" files tar prints tar: unsupported tar-filetype L Is GNU tar support out of scope? Cheers -- caóc
