Date: Fri, 09 Jan 2004 14:19:49 -0800 From: Tim Kientzle <kientzle@acm.org> To: Markus Brueffer <brueffer@phoenix-systems.de> Cc: j.el-rayes@daemon.li Subject: Re: tar's unusual argument handling Message-ID: <3FFF2905.8090904@acm.org> In-Reply-To: <200401091407.48104.brueffer@phoenix-systems.de> References: <20040108181346.84AE116A4E0@hub.freebsd.org> <20040109093311.GC311@jenny.daemon.li> <200401091127.18780.RoKlein@roklein.de> <200401091407.48104.brueffer@phoenix-systems.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Markus Brueffer wondered why: tar xvfj file.tar.bz2 is not the same as tar -xvfj file.tar.bz2 > What I'm asking me, is why the "-" makes a difference, though I haven't looked > at the sources, yet. The manpage states, that the "-" is only optional, so > "tar -jxfv" and "tar jxvf" should be equivalent, but obviously they are not. The manpage has not explained the history here. The original tar programs (1970s?) used a very peculiar command line: tar [letter options] [arguments to those options] For example, the 'b' and 'f' options both require arguments, so you would use them as tar xbfv 32 file.tar Note that '32' is the argument to 'b' and 'file.tar' is the argument to 'f'. Also note that there is no '-' here. This is totally different from other Unix programs, of course, so most current tar programs handle the arguments differently depending on whether there is a leading '-'. If there is a leading '-', then it uses common Unix conventions, so that tar -xfj file.tar.bz2 has 'j' as the argument to '-f', but tar xfj file.tar.bz2 considers 'file.tar.bz2' to be the argument to 'f'. To avoid this confusion, always put the 'f' last: tar xjf file.tar.bz2 and tar -xjf file.tar.bz2 really do mean the same thing. It's also worth noting that for many tar programs, the first argument MUST BE the mode argument ('x', 'c', 't', 'r', 'u', and sometimes 'd' or 'A'), that is tar xvjf file.tar.bz2 GOOD but tar jxvf file.tar.bz2 BAD My 'bsdtar' implementation, in particular, requires that the first option be a mode specifier (because it allows it to provide better feedback about nonsense options and handles some odd cases where options don't have quite the same meaning in different modes). Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FFF2905.8090904>