From: Earle Martin Date: 00:01 on 30 Sep 2005 Subject: du I'd like to see how big all the files/directories starting with a '.' in my home directory are, please. earle@pulsar:~$ du -h \.* 4.0K ./Mail 12K ./.ssh 104K ./photos/test ... Whoa, hold on, "Mail" doesn't begin with a dot. Stop that. Okay, try again. Maybe I need to quote the dot, or something. earle@pulsar:~$ du -h '.'* 4.0K ./Mail 12K ./.ssh 104K ./photos/test ... Okay, that's not it. What does a simple listing do? earle@pulsar:~$ du -h 4.0K ./Mail 12K ./.ssh 1.3M ./photos/test 19M ./photos 12K ./.mozilla/firefox/nx0jka40.slt/chrome ... Well, that's matching... something. I don't understand the sorting order. Out of curiosity, let's see what happens if we throw in a wildcard. earle@pulsar:~$ du -h * 8.0K Calendar 2.5M Desktop 1.6M Incomplete 4.0K Mail 36K accounts ... What the hell? Asterisk isn't matching '.'? Gah. I don't care any more.
From: Dave Vandervies Date: 00:20 on 30 Sep 2005 Subject: Re: du Somebody claiming to be Earle Martin wrote: > > I'd like to see how big all the files/directories starting with a '.' in my > home directory are, please. Keep in mind that "." is a file/directory starting with a '.' in your home directory. If you mean "everything starting with a '.' except . and ..", which I suspect is in fact what you mean, then say that. It's giving you exactly what you asked for. Software that gives me exactly what I asked for is Not Hateful. Well, it probably is for some other reason, but not because it gives me exactly what I asked for. > Out of curiosity, let's see what happens if we throw in a wildcard. > > earle@pulsar:~$ du -h * > 8.0K Calendar > 2.5M Desktop > 1.6M Incomplete > 4.0K Mail > 36K accounts > ... > > What the hell? Asterisk isn't matching '.'? Gah. I don't care any more. Do you really want to see all the stuff that starts with '.' every time you use *? Isn't avoiding that the whole point of the .name convention? dave
From: Earle Martin Date: 19:09 on 30 Sep 2005 Subject: Re: du On Thu, Sep 29, 2005 at 07:20:25PM -0400, Dave Vandervies wrote: > Keep in mind that "." is a file/directory starting with a '.' in your > home directory. Why? What use is it? I never use it. Well, unless you count using it to invoke programs. Is it a symlink? My shell's highlighting doesn't think so; it's in the blue that claims it's a directory. So when I do invoke programs, I have to go through this invisible yes-it's-a-directory-no-it's-a-symlink to do it, which is retarded. No, I can't suggest something better. I reserve the right to call things retarded, KTHX, HAND. And then there's "..", which is more of the same. When I do "cd .." I'm actually changing directory /into/ a directory, which means I should be going /down/ the directory tree. And yet the net effect is that I move up. Call me a stupid-head if you like, but that is not intuitive. On a side note, since both start with a ".", that means they should be hidden. Yet for some reason scads of applications display both "." and ".." in "open file" dialog boxes. What the fuck is the point of giving me something I can double-click on and does nothing at all? > Do you really want to see all the stuff that starts with '.' every time > you use *? Isn't avoiding that the whole point of the .name convention? Yes, I do; I expect * to match everything. I had always been under the impression that the output from 'ls' was not the same as an explicit 'ls *'. Evidently it's not; I can add it, bash, or both to my list of retarded software.
From: Earle Martin Date: 19:16 on 30 Sep 2005 Subject: Re: du On Fri, Sep 30, 2005 at 07:09:48PM +0100, Earle Martin wrote: > > Do you really want to see all the stuff that starts with '.' every time > > you use *? Isn't avoiding that the whole point of the .name convention? > > Yes, I do; I expect * to match everything. Having just read Juerd's mail, I guess I can forget about that. Add that to this "."-in-every-directory business and the conclusion is that I have decided to hate shells and everything to do with them, without exception.
From: demerphq Date: 19:19 on 30 Sep 2005 Subject: Re: du On 9/30/05, Earle Martin <hates-software@xxxxxxxx.xxx> wrote: > On Fri, Sep 30, 2005 at 07:09:48PM +0100, Earle Martin wrote: > > > Do you really want to see all the stuff that starts with '.' every ti= me > > > you use *? Isn't avoiding that the whole point of the .name conventi= on? > > > > Yes, I do; I expect * to match everything. > > Having just read Juerd's mail, I guess I can forget about that. Add that = to > this "."-in-every-directory business and the conclusion is that I have > decided to hate shells and everything to do with them, without exception. > Some shells are pretty nice tho: http://en.wikipedia.org/wiki/Conch_shell :-) -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/"
From: Smylers Date: 00:10 on 01 Oct 2005 Subject: Re: du Earle Martin writes: > On Fri, Sep 30, 2005 at 07:09:48PM +0100, Earle Martin wrote: > > > > Do you really want to see all the stuff that starts with '.' every > > > time you use *? Isn't avoiding that the whole point of the .name > > > convention? > > > > Yes, I do; I expect * to match everything. > > Having just read Juerd's mail, I guess I can forget about that. In 'Bash' you can (apparently -- I haven't tried this) do: $ shopt -s dotglob to get what you want. But if you do that, be careful if you ever let anybody else type commands at your shell prompt! Smylers
From: Abigail Date: 00:26 on 01 Oct 2005 Subject: Re: du --i7PFf0A+xzvFOD9h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 30, 2005 at 11:10:46PM +0000, Smylers wrote: > Earle Martin writes: >=20 > > On Fri, Sep 30, 2005 at 07:09:48PM +0100, Earle Martin wrote: > >=20 > > > > Do you really want to see all the stuff that starts with '.' every > > > > time you use *? Isn't avoiding that the whole point of the .name > > > > convention? > > >=20 > > > Yes, I do; I expect * to match everything. > >=20 > > Having just read Juerd's mail, I guess I can forget about that. >=20 > In 'Bash' you can (apparently -- I haven't tried this) do: >=20 > $ shopt -s dotglob >=20 > to get what you want. But if you do that, be careful if you ever let > anybody else type commands at your shell prompt! Even with dotglob set, '.' and '..' will not be matched by '*'. Abigail --i7PFf0A+xzvFOD9h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDPcmOBOh7Ggo6rasRAoNDAJ9m2mF4XT5fIMht4LdDxWlq4nQWHQCff2kg lQYRLn0RtX1SMGG+6xqEv/4= =ScOo -----END PGP SIGNATURE----- --i7PFf0A+xzvFOD9h--
From: Smylers Date: 09:07 on 01 Oct 2005 Subject: Re: du Abigail writes: > On Fri, Sep 30, 2005 at 11:10:46PM +0000, Smylers wrote: > > > Earle Martin writes: > > > > > On Fri, Sep 30, 2005 at 07:09:48PM +0100, Earle Martin wrote: > > > > > > > > Do you really want to see all the stuff that starts with '.' every > > > > > time you use *? Isn't avoiding that the whole point of the .name > > > > > convention? > > > > > > > > Yes, I do; I expect * to match everything. > > > > > > Having just read Juerd's mail, I guess I can forget about that. > > > > $ shopt -s dotglob > > > > to get what you want. > > Even with dotglob set, '.' and '..' will not be matched by '*'. Which I suspect is what Earle wants. Smylers
From: Luke Kanies
Date: 19:36 on 30 Sep 2005
Subject: Re: du
On Fri, 30 Sep 2005, Earle Martin wrote:
> On Thu, Sep 29, 2005 at 07:20:25PM -0400, Dave Vandervies wrote:
> > Keep in mind that "." is a file/directory starting with a '.' in your
> > home directory.
>
> Why? What use is it? I never use it. Well, unless you count using it to
> invoke programs. Is it a symlink? My shell's highlighting doesn't think so;
> it's in the blue that claims it's a directory. So when I do invoke programs,
> I have to go through this invisible yes-it's-a-directory-no-it's-a-symlink
> to do it, which is retarded. No, I can't suggest something better. I reserve
> the right to call things retarded, KTHX, HAND.
They're hard links (you'll have to look that one up). A little known
aspect of the output of ls -al is that it lists the number of hard links
to a file, and directories (almost) always have >=2, because one is the
hard link from the parent directory to the inode, and the other is the
hard link in the directory to itself. Incidentally, adding a
subdirectory also automatically adds another hardlink to the parent
directory, because of '..'. Go ahead, see for yourself:
luke@culain(0) $ mkdir /tmp/links
luke@culain(0) $ ls -ald /tmp/links
drwxr-xr-x 2 luke luke 48 Sep 30 13:29 /tmp/links
luke@culain(0) $ mkdir /tmp/links/sub
luke@culain(0) $ ls -ald /tmp/links
drwxr-xr-x 3 luke luke 72 Sep 30 13:29 /tmp/links
Notice the '2' in the second column becomes a '3' upon creation of the
subdirectory. That's because the subdir links back to the parent dir.
(Yes, I often ask questions related to this when I am interviewing
sysadmins -- I expect people to actually understand filesystems.)
I use '.' all the time, though, and would often be quite lost without it
(although it could be argued that most of those problems stem from
stupid or unclear tools). For instance:
rsync -a /somedir/. /otherdir/.
If I don't specify the '.', then I might (or might not) get
/otherdir/somedir, which is definitely not what I want. Each tool that
does recursive copies seems to arbitrarily decide whether to create a
new dir or operate in the old dir. I recently had some stupid problems
where I would copy a directory (/etc/apache) somewhere as myself, it
would fail on one directory, so then I would sudo cp it, and it would
get copied into a subdir:
luke@culain(0) $ cp -R /etc/apache2/ /tmp/apache2
cp: cannot access `/etc/apache2/auth': Permission denied
luke@culain(1) $ ls -ald /tmp/apache2/apache2
ls: /tmp/apache2/apache2: No such file or directory
luke@culain(1) $ sudo cp -R /etc/apache2/ /tmp/apache2
luke@culain(0) $ ls -ald /tmp/apache2/apache2
drwxr-xr-x 15 root root 616 Sep 30 13:22 /tmp/apache2/apache2
Yes, that's right, cp behaves completely differently if the directory
you're copying into already exists.
'.' is useful for cases like this, because you can specify exactly what
you want to copy and where:
luke@culain(0) $ cp -R /etc/apache2/ /tmp/apache2
cp: cannot access `/etc/apache2/auth': Permission denied
luke@culain(1) $ ls -ald /tmp/apache2/apache2
ls: /tmp/apache2/apache2: No such file or directory
luke@culain(1) $ sudo cp -R /etc/apache2/. /tmp/apache2/.
luke@culain(0) $ ls -ald /tmp/apache2/apache2
ls: /tmp/apache2/apache2: No such file or directory
> And then there's "..", which is more of the same. When I do "cd .." I'm
> actually changing directory /into/ a directory, which means I should be going
> /down/ the directory tree. And yet the net effect is that I move up. Call me
> a stupid-head if you like, but that is not intuitive.
I'm not in complete disagreement with you, but both the '.' and '..' are
made for the filesystem, not so much for you. Without these hard links,
the system itself could not operate. This is why they're hidden --
they're not something humans are supposed to deal with. Would you have
preferred that they actually be hidden, so that you could not see them?
I wouldn't.
> On a side note, since both start with a ".", that means they should be hidden.
> Yet for some reason scads of applications display both "." and ".." in "open
> file" dialog boxes. What the fuck is the point of giving me something I can
> double-click on and does nothing at all?
Yeah, that's pretty stupid. File dialogs should never show that crap.
> > Do you really want to see all the stuff that starts with '.' every time
> > you use *? Isn't avoiding that the whole point of the .name convention?
>
> Yes, I do; I expect * to match everything. I had always been under the
> impression that the output from 'ls' was not the same as an explicit 'ls *'.
> Evidently it's not; I can add it, bash, or both to my list of retarded
> software.
Well, 'ls -d' is the same as 'ls -d *', but 'ls *' will list
subdirectories, which is quite different. I assume you meant it would
match the same file list, though, which is the case.
'ls -d *' behaves identically to 'ls -d' behaves identically to
'ls -d ./*', and if you want all files then use 'ls -a'. Without '-a',
you won't get dot-files, which makes it behave as though you had matched
'*'.
From: Nicholas Clark Date: 19:51 on 30 Sep 2005 Subject: Re: du On Fri, Sep 30, 2005 at 01:36:05PM -0500, Luke Kanies wrote: > They're hard links (you'll have to look that one up). A little known > aspect of the output of ls -al is that it lists the number of hard links > to a file, and directories (almost) always have >=2, because one is the I realise that this is off topic for hating (and I will be hated by some for this) but when doesn't a directory have a hard link count >= 2? [on a filing system that doesn't cause all directories to report a link count of 1, as I believe is the case for most Unix mounted CDs] .. of / is a link to itself, so it is always >= 2, and that's the obvious one covered. Nicholas Clark
From: Luke Kanies Date: 20:06 on 30 Sep 2005 Subject: Re: du On Fri, 30 Sep 2005, Nicholas Clark wrote: > On Fri, Sep 30, 2005 at 01:36:05PM -0500, Luke Kanies wrote: > > > They're hard links (you'll have to look that one up). A little known > > aspect of the output of ls -al is that it lists the number of hard links > > to a file, and directories (almost) always have >=2, because one is the > > I realise that this is off topic for hating (and I will be hated by some > for this) but when doesn't a directory have a hard link count >= 2? > [on a filing system that doesn't cause all directories to report a link count > of 1, as I believe is the case for most Unix mounted CDs] > > .. of / is a link to itself, so it is always >= 2, and that's the obvious one > covered. Truthfully, I only threw in the 'almost' because I expected that without it someone would pipe that on Plan 9 using filesystem from_mars the poobah special device is basically a directory but only has on hard link.
From: Peter da Silva Date: 22:27 on 30 Sep 2005 Subject: Re: du It's possible that there have been cases where the root directory of a mounted file system could have a broken "..", because namei() special-cases ".." in that case, without it being user-visible.
From: Chet Hosey Date: 14:44 on 01 Oct 2005 Subject: Re: du On Fri, Sep 30, 2005 at 02:06:00PM -0500, Luke Kanies wrote: > On Fri, 30 Sep 2005, Nicholas Clark wrote: > > > On Fri, Sep 30, 2005 at 01:36:05PM -0500, Luke Kanies wrote: > > > > > They're hard links (you'll have to look that one up). A little known > > > aspect of the output of ls -al is that it lists the number of hard links > > > to a file, and directories (almost) always have >=2, because one is the > > > > I realise that this is off topic for hating (and I will be hated by some > > for this) but when doesn't a directory have a hard link count >= 2? > > [on a filing system that doesn't cause all directories to report a link count > > of 1, as I believe is the case for most Unix mounted CDs] > > > > .. of / is a link to itself, so it is always >= 2, and that's the obvious one > > covered. > > Truthfully, I only threw in the 'almost' because I expected that without > it someone would pipe that on Plan 9 using filesystem from_mars the > poobah special device is basically a directory but only has on hard > link. GNU find, -noleaf option: "Do not optimize by assuming that directories contain 2 fewer subdirectories than their hard link count. This option is needed when searching filesystems that do not follow the Unix directory-link convention, such as CD-ROM or MS-DOS filesystems or AFS volume mount points." This assumption lends a little extra speed because we still don't have filesystems which provide fast access to enough metadata that stat(2) doesn't suck horribly. GNU find will assume that once it's hit (nlinks-2) directories, it can stop checking everything else it stumbles across to see whether it's a directory or a file. What's rediculous is that we're so entrenched in UNIX tradition that you have Linux kernel developers refusing to permit non-standard VFS additions which would provide additional benefits to users of a certain developmental filesystem, because it's not UNIX-y enough. They want interface standardization first, but without allowing developers to test different interfaces it's hard to get real-world usage data and the feedback necessary to make a standard useful. Declaring a kernel interface stable without a good bit of end-user hammering makes software suck more, because rather than letting things evolve into usefulness you force software to conform to a prematurely distilled API. Instead, filesystem semantics still suck, and find has to continue to do stupid tricks in order to feel more responsive. Hateful. Also, curse you, Thunderbird, for not being able to show me the proper 80ish-column wrapped version of text so that I can properly block indent the above text rather than enclose it in the somewhat less appropriate double quotation marks. It's downright foolish to support HTML in email anyways, let alone force a mail client to act as a bastardized messaging program and HTML editor. What's next, an image editor? It's garbage like this that makes me wish my wireless connection weren't so flaky. I could then go back to using Mutt, which at least admits that mail software is hateful. Epilogue: Cut and pasted into Mutt, because Firefox isn't configured with all of my mail aliases on this machine, and only this one is subscribed. Left the Thunderbird rant because it's still hateful.
From: Peter da Silva Date: 15:09 on 01 Oct 2005 Subject: Re: du On Oct 1, 2005, at 8:44 AM, Chet Hosey wrote: > What's rediculous is that we're so entrenched in UNIX tradition that > you have Linux kernel developers refusing to permit non-standard VFS > additions which would provide additional benefits to users of a > certain developmental filesystem, because it's not UNIX-y enough. Having experienced some of the horrible results of doing things that aren't "UNIX-y enough", even on ostensibly UNIX-oriented file systems like NFS, I'm inclined to assume that whatever it is you want to do is going to be another source of hate when you get it done. The *only* network file system I've used that gave me proper UNIX semantics on remote file systems was OpenNET on Microsoft Xenix. Oh, the irony. > and find has to continue to do stupid tricks in order to feel more > responsive. Hacks to make up for poor caching algorithms have nothing to do with API semantics.
From: Chet Hosey Date: 00:34 on 02 Oct 2005 Subject: Re: du On Sat, Oct 01, 2005 at 09:09:44AM -0500, Peter da Silva wrote: > On Oct 1, 2005, at 8:44 AM, Chet Hosey wrote: > > What's rediculous is that we're so entrenched in UNIX tradition that > >you have Linux kernel developers refusing to permit non-standard VFS > >additions which would provide additional benefits to users of a > >certain developmental filesystem, because it's not UNIX-y enough. > > Having experienced some of the horrible results of doing things that > aren't "UNIX-y enough", even on ostensibly UNIX-oriented file systems > like NFS, I'm inclined to assume that whatever it is you want to do is > going to be another source of hate when you get it done. > > The *only* network file system I've used that gave me proper UNIX > semantics on remote file systems was OpenNET on Microsoft Xenix. Oh, > the irony. This isn't a network file system -- it's ReiserFS4, which brings its own hatred but attempts to bring things around towards sanity. The attempt is to provide filesystem transactions using a new interface. Some of the kernel people seem to want an API to be developed which could be used across all filesystems, whether they implement transactions or not, while the Reiser folks wants to wait before designing a standardized interface for something that isn't complete yet in their own codebase, let alone usable with other filesystems. > >and find has to continue to do stupid tricks in order to feel more > >responsive. > > Hacks to make up for poor caching algorithms have nothing to do with > API semantics. Not specifically, but when those whose goal is to make filesystems more efficient at common operations (and more featureful/flexible) are sidetracked by the need to develop APIs for functionality that isn't yet fully described it's still a stumbling block. Okay, for some more hate: Since ReiserFS4 tries to merge operations whenever possible to reduce the actual amount of writing required by a flush to disk, and is a data-journalling filesystem which sometimes generates "duplicate" information before freeing old disk contents, it's difficult to predict how much additional space will be required for a flush. ReiserFS 4 reserves some filesystem space for its operational needs to make it impossible to have more data queued to be flushed. This is so the filesystem doesn't promise a write, then find out that it doesn't have the free space to make the transaction. This is a good thing. The problem is that it reserves a fixed percentage of filesystem size. I believe it's 5%. This means that with a 250 GB volume, 12.5 GB will be reserved *just in case* a transaction which requires that much space hits the pipe. How realistic is it that you'll have 12.5 GB of transaction data waiting to be flushed to disk? Let me change the size, let me specify at mount time or creation time or by using twiddly little utilities or by modifying something in /proc, but why oh why does one of the most responsive and interesting filesystems insist on wasting such a large amount of size? Why choose a value which assumes that I might have more RAM than will fit in a typical IA32 motherboard? I know this stuff isn't being swapped out -- it's kernel cache data! The official response thus far is that there are bigger fish to fry (which is true, development is active and improving). The official attempt to make everyone feel better is to say that there's some space efficiency gained by being able to pack small files and tails into chunks. However, that doesn't begin to justify such brain damage. It's enough to make me avoid playing with new filesystems by spending time in the real world. It's made worse by the fact that I like ReiserFS 3 despite its warts, and as a result I have high hopes for the next revision.
From: Peter da Silva Date: 01:31 on 02 Oct 2005 Subject: Re: du > This isn't a network file system -- it's ReiserFS4, which brings its > own hatred but attempts to bring things around towards sanity. That's OK, it's hateful in non-network file systems as well. It's just that network file systems seem to have concentrated the hateful aspects much more effectively than even things like HFS+. > The attempt is to provide filesystem transactions using a new > interface. begin() read(), write(), ... commit()/rollback()? > Some of the kernel people seem to want an API to be developed which > could > be used across all filesystems, whether they implement transactions or > not, while the Reiser folks wants to wait before designing a > standardized > interface for something that isn't complete yet in their own codebase, > let alone usable with other filesystems. I vote for an API that can be implemented on all file systems, but not necessarily efficiently. > The problem is that it reserves a fixed percentage of filesystem size. > I > believe it's 5%. This means that with a 250 GB volume, 12.5 GB will be > reserved *just in case* a transaction which requires that much space > hits the pipe. So? Many existing file systems require a bigger reserve than that. Though it seems more logical, if the API supports transactions, to simply force a rollback() on the application. If the application is using transactions then it has to be able to handle that in any case.
From: Martin Ebourne Date: 10:16 on 02 Oct 2005 Subject: Re: du On Sat, 2005-10-01 at 09:44 -0400, Chet Hosey wrote: > Also, curse you, Thunderbird, for not being able to show me the proper 80ish-column wrapped version of text so that I can properly block indent the above text rather than enclose it in the somewhat less appropriate double quotation marks. It's downright foolish to support HTML in email anyways, let alone force a mail client to act as a bastardized messaging program and HTML editor. What's next, an image editor? Ironically, most of your email wasn't wrapped at all, despite your best efforts! +1 vote for a group hate of unusable email programs. Especially ones that concentrate on anything other than sending text. Cheers, Martin.
From: David Cantrell Date: 16:42 on 03 Oct 2005 Subject: Re: du On Sun, Oct 02, 2005 at 10:16:16AM +0100, Martin Ebourne wrote: > +1 vote for a group hate of unusable email programs. Especially ones > that concentrate on anything other than sending text. They *all* suck. And entertainingly, just like XML and Unicode-handling libraries, they all suck in different ways and are just sufficiently different that your memory isn't transferrable from any one emaily program to another, so you have to RTFbadlywrittenM. Grargh Oh GOOD sigmonster!
From: Dave Vandervies Date: 20:20 on 30 Sep 2005 Subject: Re: du Somebody claiming to be Nicholas Clark wrote: > > On Fri, Sep 30, 2005 at 01:36:05PM -0500, Luke Kanies wrote: > > > They're hard links (you'll have to look that one up). A little known > > aspect of the output of ls -al is that it lists the number of hard links > > to a file, and directories (almost) always have >=2, because one is the > > I realise that this is off topic for hating (and I will be hated by some > for this) but when doesn't a directory have a hard link count >= 2? > [on a filing system that doesn't cause all directories to report a link count > of 1, as I believe is the case for most Unix mounted CDs] > > .. of / is a link to itself, so it is always >= 2, and that's the obvious one > covered. When the last filesystem link to it is gone but it hasn't gone away because some process is still using it: -------- dave@hct-cvs:~ (0) $ mkdir foo dave@hct-cvs:~ (0) $ cd foo dave@hct-cvs:~/foo (0) $ ls -ld . drwxr-xr-x 2 dave users 4096 Sep 30 15:15 ./ dave@hct-cvs:~/foo (0) $ echo 'rmdir foo just happened from ~ in another shell' rmdir foo just happened from ~ in another shell dave@hct-cvs:~/foo (0) $ ls -ld . drwxr-xr-x 0 dave users 0 Sep 30 15:15 ./ dave@hct-cvs:~/foo (0) $ -------- ObHate: Filesystems that can't handle use-counting like this and don't let you do anything with a file or directory that some other process (not easily identified, usually) has open. dave
From: Earle Martin Date: 20:27 on 30 Sep 2005 Subject: Re: du On Fri, Sep 30, 2005 at 01:36:05PM -0500, Luke Kanies wrote: > [ a long and interesting post ] Thank you, that was very helpful.
From: Phil!Gregory Date: 14:50 on 04 Oct 2005 Subject: Re: du * Luke Kanies <luke@xxxxxxx.xxx> [2005-09-30 13:36 -0500]: > I use '.' all the time, though, and would often be quite lost without it > (although it could be argued that most of those problems stem from > stupid or unclear tools). For instance: > > rsync -a /somedir/. /otherdir/. rsync is quite deserving of some hate for its ... interesting syntax choices. I often have to check the man page (which, annoyingly, lists the usage examples *before* the option descriotions) to recall which way it goes. The key item is whether you put a slash at the end of your source directory. Let's say you have /a, /a/b, /a/c, and /x. This: rsync /a /x will create directories /x/a, /x/a/b, and /x/a/c. On the other hand, this: rsync /a/ /x will create directories /x/b and /x/c. Presumably, this is to get around the problem where you want to copy all of the contents of a remote directory, but you can't use globbing, because that's expanded locally, by the shell. Given the whole globbing issue, I happen to think that scp's approach is less hateful; if you pass it globbing characters (quoting them to protect them from your shell), it uses a shell on the other system to expand them remotely. (But, of course, that will probably miss dot files unless you specify them explicitly.)
From: Peter da Silva Date: 15:25 on 04 Oct 2005 Subject: Re: du > Let's say you have /a, /a/b, /a/c, and /x. This: > > rsync /a /x > > will create directories /x/a, /x/a/b, and /x/a/c. On the other hand, > this: > > rsync /a/ /x > > will create directories /x/b and /x/c. Well, yeh, of course it will. Any code that does tree walks is going to behave the same way. rsync /a /x "in "/x", create "a" containing "/a" and everything under it" Creates /x/a, /x/a/b, and /x/a/c. rsync /a/. /x "in "/x", create "." containing "/a/." and everything under it" Creates /x/./b and /x/./c, which is /x/b and /x/c. rsync /a/ /x "in "/x", create "" containing "/a/" and everything under it" Creates /x//b and /x//c, which is /x/b and /x/c. This works because UNIX ignores superfluous path separators, so "//" becomes "/" and the trailing "/" vanishes. > Presumably, this is to get around the problem where you want to copy > all > of the contents of a remote directory, but you can't use globbing, > because > that's expanded locally, by the shell. It's not to "get around" anything. It's just doing *exactly* what you told it to do. rsync is worthy of hate, but not for this.
From: Peter da Silva Date: 22:22 on 30 Sep 2005 Subject: Re: du > Why? What use is it? I never use it. Well, unless you count using it to > invoke programs. Is it a symlink? No, it's a directory. It's not a symlink. It's "the name of the current directory". Having an actual string that's "the name of the current directory" is critical, and having it be a regular directory entry means you *don't* need to come up with a bunch of special case rules in all your programs... I've used systems that fake this stuff, and they're a lot more hateful.
From: A. Pagaltzis Date: 03:06 on 01 Oct 2005 Subject: Re: du * Earle Martin <hates-software@xxxxxxxx.xxx> [2005-09-30 20:10]: > Yet for some reason scads of applications display both "." and > ".." in "open file" dialog boxes. What the fuck is the point of > giving me something I can double-click on and does nothing at > all? Having `.` in a fileselect box is useful as a “refresh button.†Regards,
From: Smylers Date: 09:41 on 01 Oct 2005 Subject: Re: du A. Pagaltzis writes: > * Earle Martin <hates-software@xxxxxxxx.xxx> [2005-09-30 20:10]: > > > Yet for some reason scads of applications display both "." and ".." > > in "open file" dialog boxes. What the fuck is the point of giving me > > something I can double-click on and does nothing at all? > > Having `.` in a fileselect box is useful as a ?refresh button.? That's only useful cos you've been conditioned not to expect dialogue boxes to spot that the directory has changed and to refresh themselves. The fact that you have to tell the computer about something that it has just changed is hateful. The fact that the 'refresh' button is not a button that says "Refresh" on it but instead is an entry in a list of directories to select labelled "." is even more hateful. Smylers
From: Peter da Silva Date: 11:49 on 01 Oct 2005 Subject: Re: du > That's only useful cos you've been conditioned not to expect dialogue > boxes to spot that the directory has changed and to refresh themselves. Having dialog boxes refresh themselves when you don't know the latency or throughput of the channel to the file system is hateful.
From: A. Pagaltzis Date: 12:24 on 01 Oct 2005 Subject: Re: du * Peter da Silva <peter@xxxxxxx.xxx> [2005-10-01 12:50]: > Having dialog boxes refresh themselves when you don't know the > latency or throughput of the channel to the file system is > hateful. Pretending the network is just like a local filesystem is hateful. Cf. the eight fallacies of distributed computing. Regards,
From: A. Pagaltzis Date: 12:35 on 01 Oct 2005 Subject: Re: du * Smylers <Smylers@xxxxxxx.xxx> [2005-10-01 10:45]: > That's only useful cos you've been conditioned not to expect > dialogue boxes to spot that the directory has changed and to > refresh themselves. I was going to mention something about that, but it’s a whole ’nother can of snakes. Almost all filesystem manipulation APIs are hateful. Using strings to identify files is hateful. So hateful. Not having a notification mechanism so the system can tell apps when something relevant has happened is hateful. (Ideally, filesystem objects would be, well, that – objects, where the API would provide the “M†from MVC, and then you could actually write applications that behave sanely without leaking complexity into every damn freaking line of code that somehow deals with the filesystem.) Regards,
From: Peter da Silva Date: 13:17 on 01 Oct 2005 Subject: Re: du > (Ideally, filesystem objects would be, well, that =96 objects, > where the API would provide the =93M=94 from MVC, and then you could > actually write applications that behave sanely without leaking > complexity into every damn freaking line of code that somehow > deals with the filesystem.) Don't make that a *file system*. Make that another kind of datastore. Smart file systems are hateful... even the dumb smart ones we have=20 already.
From: Abigail Date: 00:25 on 30 Sep 2005 Subject: Re: du --Ck22u5fw4m2k6hx2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 30, 2005 at 12:01:11AM +0100, Earle Martin wrote: > I'd like to see how big all the files/directories starting with a '.' in = my > home directory are, please. >=20 > earle@pulsar:~$ du -h \.* > 4.0K ./Mail > 12K ./.ssh > 104K ./photos/test > ... >=20 > Whoa, hold on, "Mail" doesn't begin with a dot. Stop that. Okay, try > again. Maybe I need to quote the dot, or something. Indeed, Mail doesn't start with a dot. But it doesn't list Mail, does it? It lists "./Mail", as it's an entry in ".", which does match ".*". > earle@pulsar:~$ du -h > 4.0K ./Mail > 12K ./.ssh > 1.3M ./photos/test > 19M ./photos > 12K ./.mozilla/firefox/nx0jka40.slt/chrome > ... >=20 > Well, that's matching... something. I don't understand the sorting order. > Out of curiosity, let's see what happens if we throw in a wildcard. Oh, just whatever order readdir is returning. > earle@pulsar:~$ du -h * > 8.0K Calendar > 2.5M Desktop > 1.6M Incomplete > 4.0K Mail > 36K accounts > ... >=20 > What the hell? Asterisk isn't matching '.'? Gah. I don't care any more. Indeed. The shell doesn't expand '*' to something that starts with a leading dot. If it did, dot-files wouldn't be "hidden". Abigail --Ck22u5fw4m2k6hx2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDPHfZBOh7Ggo6rasRArx5AKDFXEwTqpLXWnP78dfh1G7WxF9UCQCgrzWu kioGdBC+69ubCyjhEVi23TE= =pNG9 -----END PGP SIGNATURE----- --Ck22u5fw4m2k6hx2--
From: Michael G Schwern Date: 02:25 on 30 Sep 2005 Subject: Re: du On Fri, Sep 30, 2005 at 01:25:13AM +0200, Abigail wrote: > > earle@pulsar:~$ du -h \.* > > 4.0K ./Mail > > 12K ./.ssh > > 104K ./photos/test > > ... > > > > Whoa, hold on, "Mail" doesn't begin with a dot. Stop that. Okay, try > > again. Maybe I need to quote the dot, or something. > > Indeed, Mail doesn't start with a dot. But it doesn't list Mail, does it? > It lists "./Mail", as it's an entry in ".", which does match ".*". I think that's the hatefulness here. du is "helpfully" prepending ./ to everything in the cwd, unlike pretty much every other program in the universe [1], making life difficult. [1] find comes immediately to mind, but find's interface isn't exactly a ringing endorsement of anything except more hate.
From: A. Pagaltzis
Date: 03:01 on 30 Sep 2005
Subject: Re: du
* Michael G Schwern <schwern@xxxxx.xxx> [2005-09-30 03:30]:
> du is "helpfully" prepending ./ to everything in the cwd,
> unlike pretty much every other program in the universe [1],
> making life difficult.
du is doing nothing of the sort.
du is seeing the following list of arguments (as an example):
. .foo .bar .baz
If it recurses into `.foo`, the output will look something like
this:
.foo/config
.foo/state
.foo/log
So obviously, when it recurses into `.`, the output looks like
./Mail
./.bashrc
./.procmailrc
Regards,
From: Abigail Date: 06:40 on 30 Sep 2005 Subject: Re: du --b6Y3a1uK/7FdRsLm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 29, 2005 at 06:25:25PM -0700, Michael G Schwern wrote: > On Fri, Sep 30, 2005 at 01:25:13AM +0200, Abigail wrote: > > > earle@pulsar:~$ du -h \.* > > > 4.0K ./Mail > > > 12K ./.ssh > > > 104K ./photos/test > > > ... > > >=20 > > > Whoa, hold on, "Mail" doesn't begin with a dot. Stop that. Okay, try > > > again. Maybe I need to quote the dot, or something. > >=20 > > Indeed, Mail doesn't start with a dot. But it doesn't list Mail, does i= t? > > It lists "./Mail", as it's an entry in ".", which does match ".*". >=20 > I think that's the hatefulness here. du is "helpfully" prepending ./ to > everything in the cwd, unlike pretty much every other program in the=20 > universe [1], making life difficult. No. 'du' is "helpfully" prepending directories in front of files if it recurses into directories given on the command line. Since the command line consists of ".*", "." is one directories ".*" expands to. Abigail --b6Y3a1uK/7FdRsLm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDPM/bBOh7Ggo6rasRAr3bAKCT9daZidTRnYdkwKsdCDZknRje5gCfcdUo RepSMg23KGWrWrIarOfS7Uo= =zcJh -----END PGP SIGNATURE----- --b6Y3a1uK/7FdRsLm--
From: Jonathan Trites Date: 10:21 on 30 Sep 2005 Subject: Re: du This reminds me of a saying I once heard: A computer will do exactly what you tell it to do, which is rarely what you want it to do. Stupid computers. You should just know what I want and automatically do it. On 9/30/05, Abigail <abigail@xxxxxxx.xx> wrote: > On Thu, Sep 29, 2005 at 06:25:25PM -0700, Michael G Schwern wrote: > > On Fri, Sep 30, 2005 at 01:25:13AM +0200, Abigail wrote: > > > > earle@pulsar:~$ du -h \.* > > > > 4.0K ./Mail > > > > 12K ./.ssh > > > > 104K ./photos/test > > > > ... > > > > > > > > Whoa, hold on, "Mail" doesn't begin with a dot. Stop that. Okay, tr= y > > > > again. Maybe I need to quote the dot, or something. > > > > > > Indeed, Mail doesn't start with a dot. But it doesn't list Mail, does= it? > > > It lists "./Mail", as it's an entry in ".", which does match ".*". > > > > I think that's the hatefulness here. du is "helpfully" prepending ./ t= o > > everything in the cwd, unlike pretty much every other program in the > > universe [1], making life difficult. > > No. 'du' is "helpfully" prepending directories in front of files if > it recurses into directories given on the command line. Since the command > line consists of ".*", "." is one directories ".*" expands to. > > > > Abigail > > >
From: Martin Ebourne Date: 10:33 on 30 Sep 2005 Subject: Re: du Jonathan Trites <tritesnikov@xxxxx.xxx> wrote: > This reminds me of a saying I once heard: > > A computer will do exactly what you tell it to do, which is rarely > what you want it to do. > > Stupid computers. You should just know what I want and automatically do it. The result of that philosophy is perl 4. It's taken '-w' and 'use strict' to make that into anything resembling a useable language, and as useful as perl is, there's still plenty of hate left. Cheers, Martin.
From: David Cantrell Date: 13:16 on 30 Sep 2005 Subject: Re: du On Thu, Sep 29, 2005 at 06:25:25PM -0700, Michael G Schwern wrote: > On Fri, Sep 30, 2005 at 01:25:13AM +0200, Abigail wrote: > > > earle@pulsar:~$ du -h \.* > > > 4.0K ./Mail > > > 12K ./.ssh > > > 104K ./photos/test > > > Whoa, hold on, "Mail" doesn't begin with a dot. Stop that. Okay, try > > > again. Maybe I need to quote the dot, or something. > > Indeed, Mail doesn't start with a dot. But it doesn't list Mail, does it? > > It lists "./Mail", as it's an entry in ".", which does match ".*". > I think that's the hatefulness here. du is "helpfully" prepending ./ to > everything in the cwd No, it ain't. He told it to report on anything beginning with a dot, of which . is one such directory entry. du by default reports on the directory you tell it to *and everything in it*, hence ./Mail, ./.ssh, and so on. If you just want . then use -s.
From: Earle Martin Date: 19:13 on 30 Sep 2005 Subject: Re: du On Fri, Sep 30, 2005 at 01:25:13AM +0200, Abigail wrote: > Indeed, Mail doesn't start with a dot. But it doesn't list Mail, does it? > It lists "./Mail", as it's an entry in ".", which does match ".*". See other mail regarding the retardedness of this particular convention. > > Well, that's matching... something. I don't understand the sorting order. > > Oh, just whatever order readdir is returning. If it's not alphabetic then it is damn near close to useless.
From: Luke Kanies
Date: 19:39 on 30 Sep 2005
Subject: Re: du
On Fri, 30 Sep 2005, Earle Martin wrote:
> On Fri, Sep 30, 2005 at 01:25:13AM +0200, Abigail wrote:
> >
> > Oh, just whatever order readdir is returning.
>
> If it's not alphabetic then it is damn near close to useless.
Well, it's not done that way for usefulness but for speed. 'find' does
not report files in sorted order, because you might not care if they are
sorted, so sorting them would unnecessarily slow things down.
This is obviously returning the files in the order they were added to
the directory. 'ls' always handily sorts your output (as does the shell
when you use metacharacters), but most tools don't by default. If you
particularly want it sorted, then do so. I have an alias that does just
that for me:
du -dsk * | sudo sort -n
If I weren't willing to wait until all of the output were collected
(which is what happens in this case) I could pretty easily do it this
way:
for dir in *; do # sorts the dirs
du -dsk $dir
done
From: Aaron J. Grier Date: 20:01 on 30 Sep 2005 Subject: Re: du On Fri, Sep 30, 2005 at 01:39:55PM -0500, Luke Kanies wrote: > du -dsk * | sudo sort -n why do you need to sudo to run sort from a pipe? sudo du -dsk * | sort -n I could understand... but there's no reason sort needs to be priviledged, or am I missing something?
From: Luke Kanies Date: 20:07 on 30 Sep 2005 Subject: Re: du On Fri, 30 Sep 2005, Aaron J. Grier wrote: > On Fri, Sep 30, 2005 at 01:39:55PM -0500, Luke Kanies wrote: > > du -dsk * | sudo sort -n > > why do you need to sudo to run sort from a pipe? > > sudo du -dsk * | sort -n > > I could understand... but there's no reason sort needs to be > priviledged, or am I missing something? No, you're not. I'm not actually a sysadmin any more (instead, I'm trying to write software for sysadmins), so I don't use 'du' any more, which means I haven't used that alias in three years. I'm sure it started out with sudo on the right side, but somehow got retardedly on the wrong side. You are correct; the du needs the sudo, and the sort obviously does not.
From: Juerd
Date: 00:26 on 30 Sep 2005
Subject: Re: du
Earle Martin skribis 2005-09-30 0:01 (+0100):
> I'd like to see how big all the files/directories starting with a '.' in my
> home directory are, please.
> [...]
> What the hell? Asterisk isn't matching '.'? Gah. I don't care any more.
Glob patterns are interpolated by the shell, not the "du" program.
Indeed, * is specified to not include dotfiles.
An easy way to find out what is done is to use echo:
echo * # all non-dotfiles
echo .* # all dotfiles
echo \.* # same
echo '.'* # same
Now, if you use .*, the first element is ., the current directory. The
du utility helpfully gives you the du output for the current directory,
which happens to include Mail.
I hope you don't have root access... (rm -r .*)
Juerd
From: Abigail
Date: 00:44 on 30 Sep 2005
Subject: Re: du
--gQt10JDuGyDb0HQ5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Sep 30, 2005 at 01:26:58AM +0200, Juerd wrote:
>=20
> I hope you don't have root access... (rm -r .*)
$ rm -r .*
rm: cannot remove `.' or `..'
rm: cannot remove `.' or `..'
$
Abigail
--gQt10JDuGyDb0HQ5
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFDPHxBBOh7Ggo6rasRAkZGAJ9d186LT1i5zSU2AscFOWFNRHh6bQCgrvUN
hZ/s00MmOT5mXyq8EKT2OkI=
=8pHz
-----END PGP SIGNATURE-----
--gQt10JDuGyDb0HQ5--
From: Juerd Date: 00:55 on 30 Sep 2005 Subject: Re: du Abigail skribis 2005-09-30 1:44 (+0200): > On Fri, Sep 30, 2005 at 01:26:58AM +0200, Juerd wrote: > > I hope you don't have root access... (rm -r .*) > $ rm -r .* > rm: cannot remove `.' or `..' > rm: cannot remove `.' or `..' > $ Not every rm has this check, and I think the illustration is clear enough anyway. Juerd
From: A. Pagaltzis
Date: 00:57 on 30 Sep 2005
Subject: Re: du
* Earle Martin <hates-software@xxxxxxxx.xxx> [2005-09-30 01:05]:
> I'd like to see how big all the files/directories starting with
> a '.' in my home directory are, please.
`.` starts with a `.` so you get a listing for the directories in
`.`.
If you don’t want that, you need to say “all file-/dirnames
starting with . and being at least 2 chars longâ€, which would be
`.?*`.
But that includes `..`, so you need to be more specific still:
“all file-/dirnames starting with . followed by a character
that’s anything but a . and being at least 2 chars longâ€, which
is `.[^.]*`.
Except that is wrong, because a file called `..blah` (unlikely as
it is) would be excluded. So you *really* want to say “all
file-/dirnames that start with a . which have exactly one more
character that must not be a ., as well as all file-/dirnames
that start with . and are at least three characters longâ€, and
that comes out to `.[^.] .??*`.
----
And you seem not to know that it’s not du that does anything with
the wildcard, it’s the shell. Try this:
echo *
Or actually, maybe this:
perl -le'print "@ARGV"' *
and you’ll see that the program never gets to see the wildcard.
Instead it sees the list of filenames that the shell expanded the
wildcard to.
That’s why you sometimes need to quote things. If you want to
output a literal asterisk, you have to write
echo '*'
or
echo \*
because otherwise the shell will gobble up the asterisk and
replace it with a list of filenames.
----
I suppose it’s hateful because the shell-side glob expansion
confuses novices and it’s also hateful because the dotfile
conventions make matching dotfiles properly a lot of work.
But the alternatives are even more hateful, so it’s the (far)
lesser of two evils.
Regards,
From: Anton Berezin Date: 08:57 on 30 Sep 2005 Subject: Re: du On Fri, Sep 30, 2005 at 01:57:20AM +0200, A. Pagaltzis wrote: > I suppose it's hateful because the shell-side glob expansion > confuses novices and it's also hateful because the dotfile > conventions make matching dotfiles properly a lot of work. > > But the alternatives are even more hateful, so it's the (far) > lesser of two evils. The zsh documentation specifies, that No filename generation pattern matches the files `.' or `..'. On the one hand, zsh behavior is less hateful because of that. On the other hand, it is more hateful, since it is not compatible with the rest of the shell world. \Anton.
From: peter (Peter da Silva) Date: 12:45 on 30 Sep 2005 Subject: Re: du > The zsh documentation specifies, that > No filename generation pattern matches the files `.' or `..'. That's not just hateful, that's utterly evil. Not that I really needed another reason to hate zsh, of course. I've got a couple of co-workers who use zsh, and script in it. I don't have zsh on all boxes. I can now almost guarantee that one day when I'm converting one of their zsh scripts to a real shell, I'm going to miss that they depended on this "feature" when generating a list of filenames to delete.
From: =?iso-8859-1?b?U+liYXN0aWVu?= Aperghis-Tramoni Date: 10:06 on 30 Sep 2005 Subject: Re: du Earle Martin <hates-software@xxxxxxxx.xxx> wrote: > I'd like to see how big all the files/directories starting with a '.' in my > home directory are, please. I usually use du -hs .??* in order to list all hidden files except current and parent directories. HTH -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
From: Abigail
Date: 16:03 on 30 Sep 2005
Subject: Re: du
--6nfUOKxk8V1TQsEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Sep 30, 2005 at 11:06:26AM +0200, S?bastien Aperghis-Tramoni wrote:
> Earle Martin <hates-software@xxxxxxxx.xxx> wrote:
>=20
> > I'd like to see how big all the files/directories starting with a '.' i=
n my
> > home directory are, please.
>=20
> I usually use du -hs .??* in order to list all hidden files except
> current and parent directories.
I happen to have a directory .S in my home directory - which would be
missed by .??*.
du -hs .[^.]* ..?*
ought to do the trick.
Abigail
--6nfUOKxk8V1TQsEu
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFDPVOuBOh7Ggo6rasRAnNAAJ9n4TXwHy3hZKC+oyaW/Rk2nQQRmwCdE2+v
2IQYVnegtqumNTGOiPcqD+I=
=D3+q
-----END PGP SIGNATURE-----
--6nfUOKxk8V1TQsEu--
From: Luke Kanies
Date: 16:21 on 30 Sep 2005
Subject: Re: du
On Fri, 30 Sep 2005, Abigail wrote:
> On Fri, Sep 30, 2005 at 11:06:26AM +0200, S?bastien Aperghis-Tramoni wrote:
> >
> > I usually use du -hs .??* in order to list all hidden files except
> > current and parent directories.
>
>
> I happen to have a directory .S in my home directory - which would be
> missed by .??*.
>
> du -hs .[^.]* ..?*
>
> ought to do the trick.
This is exactly why I use the shell for interactive stuff only, and I
rely more on grepping out the info I don't want than on making sure only
it appears in the first place.
Because, of course, the above line will result in crap you don't want if
you don't happen to have directories that match your strings:
$ echo .[^.]* ..?*
.svn ..?*
This is why regular expressions are better than shell metacharacters:
They are actually matching, not expanding. Globbing is great, and is
certainly related to the current twisted but good state of regexes, but
I like to think I've moved on.
du $(ruby -e 'Dir.entries(".").reject { |d|
d =~ /^\.\.?$/
}.each { |d|
puts d
}')
Yes, it's more typing, but that's what aliases and scripts are for, and
I'm guessing some well-applied golf skills could reduce it some (and I
bet you could reduce it a bit in perl or especially awk), but this is
downright clear to me, and provides much more of a guarantee to me that
I get what I want and don't get crap I don't want.
Oh, and I always use '-sk' on those platforms that support it, and I
always cuss like a sailor at those platforms that don't.
From: A. Pagaltzis
Date: 16:42 on 30 Sep 2005
Subject: Re: du
* Luke Kanies <luke@xxxxxxx.xxx> [2005-09-30 17:25]:
> Because, of course, the above line will result in crap you don't want if
> you don't happen to have directories that match your strings:
>
> $ echo .[^.]* ..?*
> .svn ..?*
shopt -s nullglob
At least in a vaguely contemporary bash.
Regards,
From: David King Date: 16:58 on 30 Sep 2005 Subject: RE: du >> Because, of course, the above line will result in crap you >> don't want if you don't happen to have directories that >> match your strings: > shopt -s nullglob > At least in a vaguely contemporary bash. This, of course, results in commands responding as if you typed nothing where a wildcard doesn't match. So ls -l *.o results in a directory listing instead of a slightly more helpful ls: *.o: No such file or directory Or cat *.c|grep func_name waiting on stdin for you. Which is probably worse than the wildcard crap lying around. zsh has a "setopt NOMATCH" which prevents the command from running at all in this case: cat *.c|grep func_name zsh: no matches found: *.c but this has the annoying effect of find src -name *.h never working like you want (since if there are .h files, they are expanded. If there aren't, it refuses to run). And ls *.c *.h *.o fails unless you have all three. And if I knew what was there, I wouldn't be listing for them.
From: Aaron Crane Date: 17:28 on 30 Sep 2005 Subject: Re: du David King writes: > > shopt -s nullglob > > At least in a vaguely contemporary bash. >=20 > This, of course, results in commands responding as if you typed nothing > where a wildcard doesn't match. So=20 > ls -l *.o > results in a directory listing instead of a slightly more helpful > ls: *.o: No such file or directory >=20 > Or > cat *.c|grep func_name > waiting on stdin for you. Which is probably worse than the wildcard crap > lying around. Yes. nullglob is useful in for loops in scripts, but I think harmful everywhere else. [Must... resist... urge... to... mention... UUOC...] > zsh has a "setopt NOMATCH" which prevents the command from running at all= in > this case: > cat *.c|grep func_name > zsh: no matches found: *.c I think that's default behaviour in csh and derivatives (but I've never sullied myself by using such hateful beasts, so I wouldn't know). > but this has the annoying effect of > find src -name *.h > never working like you want Meh. Quote the pattern if you didn't mean it to be a glob. I'd probably use such an option interactively if bash had it. Apart =66rom with "-?", that is. I can barely imagine the degree of pain and suffering that would be caused by the utter hatefulness of "foo -?" not showing me a usage message for foo. > ls *.c *.h *.o > fails unless you have all three. And if I knew what was there, I > wouldn't be listing for them. In this instance, you can do ls *.[cho] instead. Or if the extensions have more than a single character, bash lets you do this: shopt -s extglob # highly recommended anyway ls *.@(c|cc|cpp|h|o) --=20 Aaron Crane
From: A. Pagaltzis Date: 18:37 on 30 Sep 2005 Subject: Re: du * Aaron Crane <hateful@xxxxxxxxxx.xx.xx> [2005-09-30 18:30]: > Or if the extensions have more than a single character, bash > lets you do this: > > shopt -s extglob # highly recommended anyway > ls *.@(c|cc|cpp|h|o) On that tangent, trying to get the !() extended pattern to do what you mean is also hateful (although I understand how to, but the mental gymnastics are still painful). Regards,
From: Peter da Silva Date: 22:17 on 30 Sep 2005 Subject: Re: du Noooo! ANything like "nullglob" is evil. It's a snare on the path to "oh no, I didn't mean to rm -r /".
From: Smylers Date: 00:30 on 01 Oct 2005 Subject: Re: du Aaron Crane writes: > David King writes: > > > > shopt -s nullglob > > > At least in a vaguely contemporary bash. > > > > This, of course, results in commands responding as if you typed nothing > > where a wildcard doesn't match. So > > ls -l *.o > > results in a directory listing instead of a slightly more helpful > > ls: *.o: No such file or directory > > > > Or > > cat *.c|grep func_name > > waiting on stdin for you. Which is probably worse than the wildcard crap > > lying around. > > Yes. nullglob is useful in for loops in scripts, but I think harmful > everywhere else. Even more recently 'Bash' has acquired failglob -- if a glob fails to match anything then the command line is aborted with an error stating as much and no commands are run. This fixes David's concerns above, and you get the error messages from the shell rather than ls or cat or whatever. Actually, failglob is even better than the 'Bash' default of passing the glob to the external program if you consider the pathological case of a glob that doesn't match itself but where there is a file with that glob as its name in the current directory. For example, suppose this directory contents: $ mkdir new $ cd new $ touch aa bb '[ab]*' '[ef]*' Then this glob obviously displays the matching files (the fact that there is also a file of that name doesn't come into play): $ du [ab]* 0 aa 0 bb This glob doesn't match anything so is passed straight through to du, which can't find a file of that name so throws an error: $ du [cd]* du: `[cd]*': No such file or directory This very similar glob also doesn't match anything so is passed through to du, but there happens to be a file of that name so du acts on that file instead of throwing an error, which isn't good: $ du [ef]* 0 [ef]* With nullglob the shell passes nothing at all to du, so du acts as it always does when run with no arguments, which, as David pointed out above, is confusing: $ shopt -s nullglob $ du [ef]* 4 . But with failglob you do get an error message: $ shopt -s failglob $ du [ef]* -bash: no match: [ef]* Smylers
From: Luke Kanies Date: 05:38 on 01 Oct 2005 Subject: Re: du On Fri, 30 Sep 2005, Smylers wrote: > For example, suppose this directory contents: > > $ mkdir new > $ cd new > $ touch aa bb '[ab]*' '[ef]*' I don't know if that's hateful, but I can definitively state that it's evil.
From: Smylers
Date: 09:38 on 01 Oct 2005
Subject: Re: du
Luke Kanies writes:
> On Fri, 30 Sep 2005, Smylers wrote:
>
> > For example, suppose this directory contents:
> >
> > $ mkdir new
> > $ cd new
> > $ touch aa bb '[ab]*' '[ef]*'
>
> I don't know if that's hateful, but I can definitively state that it's
> evil.
Well I did say that it's a pathological case, but it's enough for me to
hate the default 'Bash' behaviour of 'globs are expanded unless they
don't match anything in which case they are passed through unchanged'.
'C Shell' got this right to start with; 'Bash' introduced nullglob in
version 2, which as noted in this thread helps in some situations and
makes others worse, and took until version 3 to come up with failglob.
At least, I believe it was version 3, from reading the changelog when it
came out. I have access to this computer which has failglob:
$ shopt failglob
failglob on
$ ^X^V
GNU bash, version 2.05b.0(1)-release (i386-portbld-freebsd4.10)
And this one which doesn't:
$ shopt failglob
bash: shopt: failglob: invalid shell option name
$ ^X^V
GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu)
I hate that these are apparently the same version number, yet have
different features. bash(1) on both computers ends with:
GNU Bash-2.05b 2002 July 15
I've just diff-ed them. This itself was hateful, cos of spurious
formatting differences in the output, but having search-and-replaced
them out the only differences in the text are:
* The Red Hat one has an --rpm-requires option.
* The FreeBSD one in the 'Pathname Expansion' subsection there is this
summary of failglob between the sentences on nullglob and nocaseglob:
If the failglob option is set, and no matches are found, an error
message is printed and the command is not executed.
And that's it! The FreeBSD bash(1) doesn't even include failglob in the
big list of options under the shopt command! There are an infinite
number of version numbers available -- if you're adding a feature, it's
hateful not to adjust the version number in some way.
Smylers
From: A. Pagaltzis Date: 12:40 on 01 Oct 2005 Subject: Re: du * Smylers <Smylers@xxxxxxx.xxx> [2005-10-01 10:40]: > And that's it! The FreeBSD bash(1) doesn't even include > failglob in the big list of options under the shopt command! > There are an infinite number of version numbers available -- if > you're adding a feature, it's hateful not to adjust the version > number in some way. Probably vendor patches. RedHat has been known to ship *heavily* patched GCCs with features backported from experimental versions. Packaging is hateful. Regards,
From: Luke Kanies
Date: 16:43 on 01 Oct 2005
Subject: Re: du
On Sat, 1 Oct 2005, Smylers wrote:
> Well I did say that it's a pathological case, but it's enough for me to
> hate the default 'Bash' behaviour of 'globs are expanded unless they
> don't match anything in which case they are passed through unchanged'.
For the record, this is the Bourne shell's behaviour, which Bash merely
adopted. 'sh' on my Solaris x86 box (which makes it a real sh, not like
Linux's "Just call me bash" sh) does the pass through:
$ echo zz*
zz*
From: Earle Martin Date: 18:52 on 30 Sep 2005 Subject: Re: du On Fri, Sep 30, 2005, many people replied: > options directory filesystem pattern shell yah yah yah yah yah. So, in summary, it's all a confusing, shitty mess. By the way, STOP FUCKING CC'ING ME ON YOUR REPLIES. THIS IS A MAILING LIST. If you didn't ask your mailer to do it explicitly, then FUCKING FIX IT ALREADY. I love you all. Earle
Generated at 10:26 on 16 Apr 2008 by mariachi