My, what an astonishingly unwise directory name. Who in their right
mind would go out of their way do to such a thing?
> The only forbidden byte in a file path is 0 (and 47 ('/' in
> ASCII) is the path component separator).

Well then, as someone else said, they deserve to get incorrect answers
for this meaningless exercise.

Re: what command to show number of folders

Dave Hinz writes:
>> The only forbidden byte in a file path is 0 (and 47 ('/' in
>> ASCII) is the path component separator).
>Well then, as someone else said, they deserve to get incorrect answers
>for this meaningless exercise.

*shrug* It's not their fault that a) management asked for some
silly information and b) their users are evil.

In which case, the managers won't (a) know, (b) understand, or (c) care
that the count is off by a few because someone created a strange
directory name.

Re: what command to show number of folders

2006-01-24, 20:37(+00), Dave Hinz:
> On Tue, 24 Jan 2006 20:21:07 +0000, Stephane CHAZELAS wrote:
>> 2006-01-24, 19:28(+00), Dave Hinz:
>
>>> Can you give an example of a "multiline file path" please? I'm not
>>> aware of such a thing.
>
>> mkdir 'My Holiday Pictures
>> July 2005'
>
> My, what an astonishingly unwise directory name. Who in their right
> mind would go out of their way do to such a thing?

One never knows, maybe people who don't know it may break poorly
written scripts . See how many people started writing
filenames with spaces when Microsoft removed their 8.3 filename
limitations.

There should be a couple of those on most machines I've used,
left after some tests for some scripts I wrote.

There are the cases of filenames created after someone
inadvertently copy pasted a mail message at a shell prompt.

If I paste:
> That's interesting
> You're sure?

at a shell prompt, it will run the "sure?" command with its
output redirected to a file called "Thats interesting\nYoure"

--
Stéphane

Re: what command to show number of folders

Probably better done by using a backslash to quote the NL.
> > My, what an astonishingly unwise directory name. Who in their right
> > mind would go out of their way do to such a thing?
>
> One never knows, maybe people who don't know it may break poorly
> written scripts . See how many people started writing
> filenames with spaces when Microsoft removed their 8.3 filename
> limitations.

Which doesn't answer the question about who's in their right
mind andwho isn't. I've had to deal with Mac and PC folks
using PCNFS and such to share NFS. There's quite a mess
trying to writes scripts that do the right thing to files with any
of the types of quote characters. It's bad enough dealing with
spaces and tabs, but ticks or newlines will break nearly any
automation.
> There should be a couple of those on most machines I've used,
> left after some tests for some scripts I wrote.
>
> There are the cases of filenames created after someone
> inadvertently copy pasted a mail message at a shell prompt.
>
> If I paste:
>
> > That's interesting
> > You're sure?
>
> at a shell prompt, it will run the "sure?" command with its
> output redirected to a file called "Thats interesting\nYoure"

And then you'd need some amount of savvy to know how to delete
it with "rm -i T*" or whatever. Sure. I've found plenty of sysadmins
who don't bother deleting files that have backspaces or escape
sequences or whatever in their names because so little is gained
for the effort. Shrug.

It still doesn't make it worth the effort to fix the find|wc command
to returns an exactly correct number. For an exactly correct
number you'll want a process that detects various types of
inaccessable directories. Maybe you've unlinked a directory
tree and haven't run fsck yet. Maybe you mounted a filesystem
over a non-empty directory tree (I rather like a tiny /usr on some
systems). There are several ways that find won't work. Another
post mentioned fsdb or similar filesystem dumping tools for that.

Re: what command to show number of folders

Dave Hinz writes:
>>>Well then, as someone else said, they deserve to get incorrect answers
>>>for this meaningless exercise.
>> *shrug* It's not their fault that a) management asked for some
>> silly information and b) their users are evil.
>In which case, the managers won't (a) know, (b) understand, or (c) care
>that the count is off by a few because someone created a strange
>directory name.

*shrug* Accuracy is always a nice thing, regardless. It seems
like the original grep-based solution should be a nice thing to keep in my
script toolbox.

Many users, most commonly by accident, manage to create quite
interesting names for files and directories - including newlines,
blanks, tabs, control characters, names starting with . or -, shell
metacharacters, directory hierarchies so deep rm -rf fails to remove
them (at least on some platforms), and other 'exciting' stuff.

Re: what command to show number of folders

Dave Hinz wrote:
> On Tue, 24 Jan 2006 15:45:02 +0000, Tony wrote:
>
>>Hi !
>>
>>Can anyone tell me what command line syntax I would type to find out how
>>many directories are in my system.
>
>
> That's kind of a meaningless thing to want to do, but I'd look at the
> 'find' command and the 'wc' command.
>
> Is this just personal curiousity, or what's the goal here?
>
I have some backup software on my system that is giving errors. Tech
support for the backup software have asked the question and I didn't
know how to produce the answer.

Not as long as your shell is Bourne like, or you want to include
a backslash.
>> > My, what an astonishingly unwise directory name. Who in their right
>> > mind would go out of their way do to such a thing?
>>
>> One never knows, maybe people who don't know it may break poorly
>> written scripts . See how many people started writing
>> filenames with spaces when Microsoft removed their 8.3 filename
>> limitations.
>
> Which doesn't answer the question about who's in their right
> mind andwho isn't. I've had to deal with Mac and PC folks
> using PCNFS and such to share NFS. There's quite a mess
> trying to writes scripts that do the right thing to files with any
> of the types of quote characters. It's bad enough dealing with
> spaces and tabs, but ticks or newlines will break nearly any
> automation.

There's no reason why ticks should. It's true that newlines are
a big problem. The system can cope with them but the user space
applications often don't.
>> There should be a couple of those on most machines I've used,
>> left after some tests for some scripts I wrote.
>>
>> There are the cases of filenames created after someone
>> inadvertently copy pasted a mail message at a shell prompt.
>>
>> If I paste:
>>
>> > That's interesting
>> > You're sure?
>>
>> at a shell prompt, it will run the "sure?" command with its
>> output redirected to a file called "Thats interesting\nYoure"
>
> And then you'd need some amount of savvy to know how to delete
> it with "rm -i T*" or whatever.

???

With a proper shell, you type rm T, which the shell should
expand properly. Here with zsh, it does:

$ rm Thats\ interesting'
'\>\ Youre

And if I start with rm "T

$ rm "Thats interesting
> Youre"

[...]
> It still doesn't make it worth the effort to fix the find|wc command
> to returns an exactly correct number. For an exactly correct
> number you'll want a process that detects various types of
> inaccessable directories. Maybe you've unlinked a directory
> tree and haven't run fsck yet. Maybe you mounted a filesystem
> over a non-empty directory tree (I rather like a tiny /usr on some
> systems). There are several ways that find won't work. Another
> post mentioned fsdb or similar filesystem dumping tools for that.

But what you are talking about are pathological cases, for which
one can't do anything about. The UNIX API allows any user to
create a filename with a newline, it's not supposed to allow a
user to corrupt a filesystem.

If find doesn't work because root doesn't have read access on a
NFS shared filesystem (though find will report it) or because
the file system is corrupted... then no other user space command
will be able to read those directories either. So find will give
the number of directories that can possibly be given.

debugfs will give a different answer, but that answer will not
necessarily be more useful.

In any case, counting the multiline paths several time is a flaw
in the script that calls find, not in find nor the filesystem.