From: Robert Rothenberg
Date: 15:12 on 20 Feb 2007
Subject: unzip hate
Take the following zip file
$ unzip -l foo
Archive: foo.zip
Length Date Time Name
-------- ---- ---- ----
0 02-20-07 15:05 foo/
0 02-20-07 15:05 foo/file1
0 02-20-07 15:05 foo/bar/
0 02-20-07 15:05 foo/bar/file2
-------- -------
0 4 files
Now try this:
$ unzip -l foo foo/*
Archive: foo.zip
Length Date Time Name
-------- ---- ---- ----
0 02-20-07 15:05 foo/file1
-------- -------
0 1 file
Oh, but what if I also want to list all files below foo? There's no
equivalent -r option for recursive. So I cannot list or extract files in
foo/bar without specifying them manually.
Rob
From: Abigail
Date: 15:37 on 20 Feb 2007
Subject: Re: unzip hate
--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 20, 2007 at 03:12:57PM +0000, Robert Rothenberg wrote:
>=20
> Take the following zip file
>=20
> $ unzip -l foo
> Archive: foo.zip
> Length Date Time Name
> -------- ---- ---- ----
> 0 02-20-07 15:05 foo/
> 0 02-20-07 15:05 foo/file1
> 0 02-20-07 15:05 foo/bar/
> 0 02-20-07 15:05 foo/bar/file2
> -------- -------
> 0 4 files
>=20
>=20
> Now try this:
>=20
> $ unzip -l foo foo/*
> Archive: foo.zip
> Length Date Time Name
> -------- ---- ---- ----
> 0 02-20-07 15:05 foo/file1
> -------- -------
> 0 1 file
>=20
> Oh, but what if I also want to list all files below foo? There's no
> equivalent -r option for recursive. So I cannot list or extract files in
> foo/bar without specifying them manually.
That's not what I get:
$ unzip -l foo.zip=20
Archive: foo.zip
Length Date Time Name
-------- ---- ---- ----
0 02-20-07 16:35 foo/
0 02-20-07 16:35 foo/file1
0 02-20-07 16:35 foo/bar/
0 02-20-07 16:35 foo/bar/file2
-------- -------
0 4 files
$ unzip -l foo.zip foo/*
Archive: foo.zip
Length Date Time Name
-------- ---- ---- ----
0 02-20-07 16:35 foo/
0 02-20-07 16:35 foo/file1
0 02-20-07 16:35 foo/bar/
0 02-20-07 16:35 foo/bar/file2
-------- -------
0 4 files
However:
$ unzip foo
Archive: foo.zip
creating: foo/
extracting: foo/file1 =20
creating: foo/bar/
extracting: foo/bar/file2 =20
$ unzip -l foo.zip foo/*
Archive: foo.zip
Length Date Time Name
-------- ---- ---- ----
0 02-20-07 16:35 foo/file1
-------- -------
0 1 files
Perhaps you suffer from the fact that your shell is expanding the *?
Abigail
--7AUc2qLy4jB3hD7Z
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFF2xWdBOh7Ggo6rasRAiXTAJ9iqIcMSBXED6h9uWB5f3hpzPTsAgCfRBAv
7JVeyCX3QlvgmCktwQLXBsc=
=ueNy
-----END PGP SIGNATURE-----
--7AUc2qLy4jB3hD7Z--
From: Robert Rothenberg Date: 17:02 on 20 Feb 2007 Subject: Shell hate (was Re: unzip hate) On 20/02/07 15:37 Abigail wrote: > Perhaps you suffer from the fact that your shell is expanding the *? You're right. My mistake.
From: Smylers Date: 17:11 on 20 Feb 2007 Subject: Re: Shell hate (was Re: unzip hate) Robert Rothenberg writes: > On 20/02/07 15:37 Abigail wrote: > > > Perhaps you suffer from the fact that your shell is expanding the *? > > You're right. My mistake. A shell which expands a pattern if it can or otherwise (silently) pretends that you quoted it is hateful. Apart from anything else, the silent-pretend-quoting lulls people into a false sense of security, so they end up using it when it does match something. Bash 3 introduced the failglob option $ shopt -s failglob When set it means that a pattern will either be expanded or if nothing matches will give you an error; if you want to treat a pattern as a string you have to quote it. (Don't confuse this with the nullglob option, which (silently) pretends that non-matching patterns never existed, running the command with nothing in the place where you typed the pattern; that's also hateful.) TC Shell had a failglob-equivalent years ago. Bash hatefully took until the relatively recent version 3 to catch up. And, hatefully, it isn't the default (for obvious reasons, I accept, but that doesn't make it not hateful). Smylers
From: Martin Ebourne
Date: 17:27 on 20 Feb 2007
Subject: Re: Shell hate (was Re: unzip hate)
Smylers <Smylers@xxxxxxx.xxx> wrote:
> A shell which expands a pattern if it can or otherwise (silently)
> pretends that you quoted it is hateful.
Ever so.
> Bash 3 introduced the failglob option
Hey, bash wasn't first. :)
> (Don't confuse this with the nullglob option, which (silently) pretends
> that non-matching patterns never existed, running the command with
> nothing in the place where you typed the pattern; that's also hateful.)
That's especially evil. You could be waiting for grep for a very long time. =
:)
failglob can be a real pain in scripts. Zsh works well, you can set =20
failglob then give the glob expression a modifier when required. So =20
you can do
rm -f *.o(N)
and it won't fail on you.
Oh I want to hate GNU find at this point.
find -name '*.bak'
isn't valid on traditional unix find. On GNU it is, it works from cwd =20
instead. Also you can give many roots for it to search from. I don't =20
really hate that but I do hate that it's different from unix find and =20
that it caught me out. Something like
find /path/to/dir/*.bak -mtime 5 | xargs rm -f
broke free on my system when there were no .bak files, and started =20
from / as root. Needless to say the system died sometime after the =20
contents of /lib had been erased. Really I suppose I hate my own =20
stupid script (long since beaten to death) for being stupid and badly =20
written. failglob would have saved me. But still GNU find did a whole =20
lot of what I didn't expect it to do. Hate.
Cheers,
Martin.
From: Smylers Date: 17:38 on 20 Feb 2007 Subject: Re: Shell hate (was Re: unzip hate) Martin Ebourne writes: > Smylers <Smylers@xxxxxxx.xxx> wrote: > > > Bash 3 introduced the failglob option > > Hey, bash wasn't first. :) Erm, yeah ... that's why farther down in my message I explicitly mentioned an example of some other shell that had this feature years ago and state how hateful it is that Bash took until version 3 to introduce this! > find /path/to/dir/*.bak -mtime 5 | xargs rm -f > broke free on my system when there were no .bak files, Ouch. As somebody used to GNU find I keep finding it hateful that find on FreeBSD does this: $ find -type f find: illegal option -- t find: illegal option -- y find: illegal option -- p find: illegal option -- e find: f: No such file or directory But at least that's only a minor irritation and the command-line, rather than most of a hard-disk wiped, so I think you're hate definitely wins! Smylers
From: Peter da Silva Date: 17:19 on 20 Feb 2007 Subject: Re: Shell hate (was Re: unzip hate) How many of the people who think shell wildcard expansion is hateful have spent much time using other people's programs on any OS where the command line is the normal user interface and where wildcard expansion is up to the application writers? God it's hateful. "Oh yeh, that program only does wildcards on the first argument and on the "file=" parameter if you didn't specify a device name." "Oh, sorry, yeh, it doesn't let you wildcard the type. What? It does WHAT? Geeze, why would anyone expect that to work?" "No, that one's a port of a VMS program, and it only does VMS style wildcards." "Oh, yeh, you need to quote the filename to get normal wildcards." "No, don't quote that, it'll try and treat the quotes as part of the file name." "Single quotes only." "Don't quote it, replace the spaces with underscores." "Wildcards on the second file name only work if the first file name has wildcards in it." "Oh, yeh, you need to use UNIX wildcards on all of his programs." "That's not a wildcard, star means 'any host'." "The wildcards are '#' and '%', something to do with the database." "Question mark means the file type is optional." "No, you have to leave the quote off at the end of the line or it won't match anything. Yes, I know they're unbalanced. If you ask me, so was he." "Two stars in a row means a literal star."
From: Martin Ebourne Date: 17:30 on 20 Feb 2007 Subject: Re: Shell hate (was Re: unzip hate) Peter da Silva <peter@xxxxxxx.xxx> wrote: > How many of the people who think shell wildcard expansion is hateful > have spent much time using other people's programs on any OS where > the command line is the normal user interface and where wildcard > expansion is up to the application writers? > > God it's hateful. > > "Oh yeh, that program only does wildcards on the first argument and > on the "file=3D" parameter if you didn't specify a device name." > > "Oh, sorry, yeh, it doesn't let you wildcard the type. What? It does > WHAT? Geeze, why would anyone expect that to work?" > > "No, that one's a port of a VMS program, and it only does VMS style > wildcards." > > "Oh, yeh, you need to quote the filename to get normal wildcards." > > "No, don't quote that, it'll try and treat the quotes as part of the > file name." > > "Single quotes only." > > "Don't quote it, replace the spaces with underscores." > > "Wildcards on the second file name only work if the first file name > has wildcards in it." > > "Oh, yeh, you need to use UNIX wildcards on all of his programs." > > "That's not a wildcard, star means 'any host'." > > "The wildcards are '#' and '%', something to do with the database." > > "Question mark means the file type is optional." > > "No, you have to leave the quote off at the end of the line or it > won't match anything. Yes, I know they're unbalanced. If you ask me, > so was he." > > "Two stars in a row means a literal star." More! More! Go on, more pain! Harder! Ahem Martin.
From: Peter da Silva Date: 17:44 on 20 Feb 2007 Subject: Re: Shell hate (was Re: unzip hate) On Feb 20, 2007, at 11:30 AM, Martin Ebourne wrote: > More! More! Go on, more pain! Harder! OK. I forgot all about escaping quotes. Two sentence summary: "How do you enter E. E. 'Doc' Smith as the title? Do you double the quotes, or use different quotes, or use an escape character, and which escape character does it use? Oh, you put something else in and use the 'quote-replacement' parameter?" Hmm, that doesn't cover "You can't do that" and "Don't worry, it only pays attention to the first and last quote on the line".
From: David Cantrell Date: 23:29 on 20 Feb 2007 Subject: Re: Shell hate (was Re: unzip hate) Peter da Silva wrote: > OK. I forgot all about escaping quotes. > > Two sentence summary: "How do you enter E. E. 'Doc' Smith as the title? Smith, E. E. (Doc) Woo! more special characters to hate!
From: Andrew Black Date: 20:33 on 20 Feb 2007 Subject: Re: Shell hate (was Re: unzip hate) Peter da Silva wrote: > > "No, that one's a port of a VMS program, and it only does VMS style > wildcards." > VMS Perl tries to be helpful and do the shell expansion that you might expect. Usually this is helpful. But if you do perl something.pl "*wildcard*" the quotes get sucked up by DCL so perl gets *wildcard* which it then procedes to glob expand.
From: Peter da Silva Date: 05:15 on 21 Feb 2007 Subject: Re: Shell hate (was Re: unzip hate) On Feb 20, 2007, at 2:33 PM, Andrew Black wrote: > Peter da Silva wrote: >> "No, that one's a port of a VMS program, and it only does VMS style >> wildcards." > VMS Perl tries to be helpful and do the shell expansion that you might > expect. Usually this is helpful. Oh. God. Thank you. You've reminded me of yet another level of hatefulness in systems where applications do wildcarding. Conflicts between application wildcard syntaxes. Damn, I'd almost recycled those neurons.
From: Peter da Silva Date: 16:50 on 20 Feb 2007 Subject: Re: unzip hate > $ unzip -l foo foo/* unzip: No match. What happens with $ unzip -l foo 'foo/*'
Generated at 12:28 on 17 Feb 2008 by mariachi