lkml.org 
[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tar] us.kernel.org mirroring inconsistency
Hi Matt.

>>> BEFORE you make wild statements like the following, PLEASE try it
>>> for yourself, before you decide to post your "authoritative"
>>> reponse to this mailing list.

>> I most certainly DID try doing "man tar" and found the very fact I
>> pointed out clearly stated therein. I've just done so again, and I
>> quote from the tar manpage:

> But you didn't try "tar xvv" which if you had (with a recent tar)
> you would have found it worked.

If I could've tried it out, I would've done so, but AS I STATED in my
original email, right at that point, I wasn't able to do so, so was
ONLY able to go by what the manpage said.

For reference, Windows NT (which I was in at the time) is not that
good at running Linux programs like tar, at least not in my personal
experience. However, if you can advise me of a means by which one can
do so, please do...

> Man pages are good for finding new options, or finding out what
> options do, but if someone says "try this, it works" you DON'T say
> "you are wrong, the manpage says so" without trying it for
> yourself.

{Shrug} If somebody says "this should work" (like you did), the only
information one has says the opposite, and one has no direct way to
test it out at the time, is one automatically wrong for saying "Well,
I can't test it out at the moment, but the documentation says it won't
work" (like I did).

> As you are hopefully fully aware, most developers hate writing
> documentation so the docs are usually out of date, so they could
> have added that feature up to 6 months ago, and the manpage
> wouldn't have been updated to reflect it.

> "It's a feature, not a bug"

That's precicely why I added that proviso that I couldn't at that time
test it out, and was only going by the documentation as a result. YOU
are the one who tried to start a flamewar about it, not me...

>> Q> OTHER OPTIONS
>> Q> :
>> Q> -f, --file [HOSTNAME:]F
>> Q> use archive file or device F (default /dev/rmt0)

>> Perhaps you can advise whether that comment is in YOUR tar manpage
>> as well?

> yes it is, but also the statement:

> BUGS
> The GNU folks, in general, abhor man pages, and create
> info documents instead. The maintainer of tar falls into
> this category. This man page is neither complete, nor
> current, and was included in the Debian Linux packaging of
> tar entirely to reduce the frequency with which the lack
> of a man page gets reported as a bug in our defect track
> ing system.

So? How does that make me wrong for stating that I was uncertain as to
the accuracy of your comment, but would check later when I was on a
Linux system???

>> 1. I very rarely say either, and I believe this is only the
>> fifth time in two years that I've done so.

> I disagree with that, I've seen you say that quite a few more
> times, but that is not the issue.. What annoyed me, was that when
> someone, who IMHO has a very good reputation on this list, posted
> an example of "this is an easier way to do X" you shot him down
> without even checking to see whether his command actually worked.

I don't believe I came anywhere near to shooting him down, and if I
did, then I wholeheartedly apologise as such was never my intention.

>> I've posted far more than five emails in that time...

> Unfortunately that is the case.

If you don't want to read them, you don't have to...

>> 2. The evidence indicates that I'm NOT wrong on this occasion as
>> the tar manpage appears to state exactly what I said it does.

> Again, the manpage is NOT a defining standard that the programmers
> have to stick to, like the posix manuals etc, it is just some
> documentation written by someone else to try and help people new to
> the program understand how to use it.

Where did I say otherwise?

> The tar manpage is not unique in that respect, a large proportion
> of our documentation is

> a) not written by the original authors and
> b) out of date and/or incorrect.

Unfortunately all too true...

>>>> but if the tar manpage is any guide,

>> Note that line...

> Yes! A "guide" not a "koran" (no offense intended to any islamic
> readers of this list)

Again, when did I say otherwise?

>> Which is true /dev/rmt0 doesn't exist on my system...

> Nor mine.. But obviously someone has modified tar to default to
> stdin instead.. Not that hard, and as you point out most systems
> don't even have a /dev/rmt0.

> Maybe it's a Debian specific patch to tar. Have you tried it on
> your system yet to see if it actually works?

I've tried it on three of my systems now, and here's the results
thereof...

1. RedHat 4.1 raw installed, it does NOT work.

2. RedHat 4.1 upgraded to 5.1, it does NOT work.

3. RedHat 5.1 raw installed, it works.

Verdict: It's NOT a reliable command...whereas the version I posted IS
a reliable command...

>>> Works fine for me.
>>> Version: 1.12-6

>> In other words, the tar manpage is wrong? Perhaps it should be
>> corrected...

> Yes, it needs a major overhaul. (one of the little side-projects I
> was working on, before I realised that I don't yet know enough
> about tar, nor do I currently have the time to work on it, so I've
> put it on the backburner for the time being, hoping someone else
> would step up and fix it instead)

I can't help there for the simple reason that I don't know tar that
well either, as is probably obvious from the current thread...

>>> That line works too, but requires an extra 3 characters that are
>>> unneeded, at least for recent versions of tar.

>> At least the manpage is right about something then 8-)

> Of course, I believe almost everything in the manpage will work,
> but there are some "hidden" commands that haven't made it into the
> manpages yet.

> Some would call that a bug. I would call it a feature. (Although I
> would call it a bug of the documentation, which in this case even
> the documentation agrees is the case)

I'm in full agreement there...

>> One thing though: If they were to be online for (say) 72 hours
>> non-stop, would anybody complain?

> Nope.

> jupiter:~$ f -m snip
> Login: snip Name: SNIP Computer Service
> Directory: /home/members Shell: /usr/local/bin/staticmenu
> Office: Permanent Connection
> On since Thu Dec 31 06:24 (WST) on ttyFc from 26400
> 2 hours 23 minutes idle
> No mail.
> No Plan.
> jupiter:~$ date
> Fri Jan 8 08:33:41 WST 1999

> This guy's been on for over 194 hours on a standard telephone line.
> We sell it as a permanent connection, but as far as Telstra knows
> it's just a normal phone call.

My reason for asking that is that some of the Cable TV companies in
the UK offer a similar scheme, but they start another charging period
every time midnight passes, so one gets charged the relevant sum for
each day one's call is part of. Nothing to do with the ISP, it's the
telephone service supplier who 'complains', for want of a better word.

> (no, he's not really called snip, but you know, customer privacy
> and all :)

Don't worry, I wouldnae want to know his/her name anyway...

> Anyway, this is getting way off topic for this list, so this will
> be the last post of mine on this issue.

My last public post as well - anything further will be "For your eyes
only"...

Best wishes from Riley.

---
* ftp://ps.cus.umist.ac.uk/pub/rhw/Linux
* http://ps.cus.umist.ac.uk/~rhw/kernel.versions.html


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.076 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site