1 |
b.n. <brullonulla@×××××.com> wrote: |
2 |
|
3 |
> Alexander Skwar ha scritto: |
4 |
>> Stroller <stroller@××××××××××××××××××.uk> wrote: |
5 |
>> |
6 |
>>> On 24 Sep 2007, at 09:30, Alexander Skwar wrote: |
7 |
>>>> ... |
8 |
>>>>> and if p7zip supports pipes, you don't need its support in tar. |
9 |
>>>>> Just pipe |
10 |
>>>>> from/to it. |
11 |
>>>> It does and that's the way it's supposed to be used on unix, according |
12 |
>>>> to its manpage. |
13 |
>>> GNU tar features the -j, -z and -Z options. |
14 |
>> |
15 |
>> Yes, bad, isn't it? These options are not part of the Posix standard. |
16 |
>> It would be good, if these superflous options wouldn't be present at |
17 |
>> all. I say "superflous", as pipes work just fine. |
18 |
> |
19 |
> It's not that an option becomes "bad" just because it's not carved into |
20 |
> the POSIX standard. |
21 |
|
22 |
To a degree, it is. |
23 |
|
24 |
> What's important, I guess, is that tar is |
25 |
> POSIX-compliant, so that if you want, you can build POSIX-compliant |
26 |
> scripts etc. , |
27 |
|
28 |
Depends. On the hand, you're right. But if non-compliant options |
29 |
exist, people tend to use them. That's bad in so far, as they get |
30 |
used to non-standard behaviour. That's especially bad, as standard |
31 |
compliants solution exist. |
32 |
|
33 |
> but I can't see how non-POSIX but handy extensions could |
34 |
> be bad. |
35 |
|
36 |
Let me give you a different example, although it has nothing |
37 |
to do with POSIX. |
38 |
|
39 |
Internet Explorer translates a \ in a URL to /. That's a non |
40 |
standard compliant behaviour. Now, as many people (still *G*) |
41 |
use IE, many people rely on that mis-behaviour of IE and make |
42 |
it hard for non-misbehaving browsers (ie. Mozilla) to display |
43 |
the content. |
44 |
|
45 |
What does this have to do with GNU tar and it adding superflous |
46 |
options? Quite a lot. -j et.al. are non-standard options. If a |
47 |
(badly written) script relies on the presence of -j, this script |
48 |
won't work with a POSIX compliant tar (like star or any Unix |
49 |
tar (eg. Sun, HP, ...)). Is that bad? Yes, it is. It is bad, as |
50 |
there's an easily accessible solution to this problem available: |
51 |
Use pipes! In this case, the solution would be: |
52 |
|
53 |
tar cf - dir | bzip2 > dir.tar.bz2 |
54 |
tar cf - dir | 7z a -si dir.tar.7z |
55 |
|
56 |
Or for decompression: |
57 |
|
58 |
bzcat dir.tar.bz2 | tar xf - |
59 |
7z x -so dir.tar.7z | tar xf - |
60 |
|
61 |
> Maybe it's me not seeing the problem. |
62 |
|
63 |
Yep. |
64 |
|
65 |
> Maybe the POSIX standard |
66 |
> could just be extended as well. :) |
67 |
|
68 |
Equally fine. |
69 |
|
70 |
>>> and it would be nice to see p7zip supported |
71 |
>>> in the same way. |
72 |
>> |
73 |
>> No. |
74 |
> |
75 |
> "No" means nothing. Tell us why. |
76 |
|
77 |
Pipes exist. The current "integration" of 7-zip is fine. There's |
78 |
no need to integrate other compression into tar. Actually, there's |
79 |
no need at all to integrate ANY compression alg. into tar. |
80 |
|
81 |
Furthermore, especially with 7zip, an integration into tar would |
82 |
make the use of 7zip somewhat limited, as all of the additional |
83 |
command line options of 7z would not be accessible anymore. |
84 |
|
85 |
Alexander Skwar |
86 |
|
87 |
-- |
88 |
gentoo-user@g.o mailing list |