Linux-Development-Apps Digest #388, Volume #7 Tue, 8 May 01 12:13:29 EDT
Contents:
Re: inode to filename? ("Markku Parviainen")
Re: Adding file extension recursively (Chris)
Re: inode to filename? (Lew Pitcher)
Re: Time to read the Disk (Marty)
Re: Adding file extension recursively (Rolf Magnus)
Re: Adding file extension recursively (Chris)
Re: Time to read the Disk (Kasper Dupont)
Re: Time to read the Disk (Villy Kruse)
Re: Adding file extension recursively (Kaz Kylheku)
Re: How to get a number of processors (Greg Copeland)
Re: inode to filename? (Kaz Kylheku)
Re: premature end of script headers (Kaz Kylheku)
Re: libstdc++ errors when compiling various apps (mozilla, texmacs, ...) (Erik Max
Francis)
Re: Time to read the Disk (Kaz Kylheku)
Re: Adding file extension recursively ("Zoran Cutura")
Re: Time to read the Disk (Kaz Kylheku)
Re: Faster than strstr (David Rubin)
Re: Faster than strstr ("Douglas A. Gwyn")
PostgreSQL_question (Jorge Escalante)
Re: Faster than strstr (Walter Briscoe)
Re: Faster than strstr (Hans-Bernhard Broeker)
Re: Adding file extension recursively ("Nils O. Selåsdal")
Re: Adding file extension recursively (Chris)
Re: how to list files in a directory with C? ("Nils O. Selåsdal")
----------------------------------------------------------------------------
From: "Markku Parviainen" <[EMAIL PROTECTED]>
Subject: Re: inode to filename?
Date: Tue, 8 May 2001 16:18:46 +0300
> I'd assume the reason for not having name information linked to the
> inode is that that'd create yet another place where things must be kept
> synchronised across a filesystem (i.e. when a file is renamed, also the
> name information in the inode should be refreshed). Also, as there can
> be multiple names (hard links) for a given inode, the inode data structure
> would become much more complex.
Hmm, Now I'm really confused.
If I can ask which inode is associated with certain file name, and I'll get
response quickly, there should be some kind of table, which links file names
to inodes, right?
Then why it can't do reverse lookup through the same table instead of
seeking through the whole disk looking for that file name?
And if that table was constructed like:
file1 -> 123
"hard link to file1" -> 123
file2 -> 456
Then it should be no problem to return those two names for #123...
(Or at least first of them)
Err, maybe I should get a book: "Understanding ext2 file system" ... :)
(I wonder if there is one...)
------------------------------
From: Chris <[EMAIL PROTECTED]>
Subject: Re: Adding file extension recursively
Date: Tue, 08 May 2001 14:22:08 +0100
Neoklis wrote:
>
> Hi!
>
> I have a large number of gif's in a number of directories but the file
> names don't have the .gif extension. Is there a Linux command or script
> that can add the file extension recursively? Any hints on how I could
> write a script if I have to?
>
> My thanks in advance!
Look at find(1).
Something like
find . -type f -print | sed 's/^\(.\+\)$/mv \1 \1.gif' | sh
is a way of doing it. Note that this will not work if any
of the files you are renaming contain whitespace. This is
not a fundamental problem; it just requires a
better-written one-liner.
--
Chris Lightfoot -- chris at ex dash parrot dot com -- www.ex-parrot.com/~chris/
You cannot win the game, and you are not allowed to stop playing
(the third law)
------------------------------
From: [EMAIL PROTECTED] (Lew Pitcher)
Subject: Re: inode to filename?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 08 May 2001 13:38:09 GMT
On Tue, 8 May 2001 16:18:46 +0300, "Markku Parviainen"
<[EMAIL PROTECTED]> wrote:
>> I'd assume the reason for not having name information linked to the
>> inode is that that'd create yet another place where things must be kept
>> synchronised across a filesystem (i.e. when a file is renamed, also the
>> name information in the inode should be refreshed). Also, as there can
>> be multiple names (hard links) for a given inode, the inode data structure
>> would become much more complex.
>
>Hmm, Now I'm really confused.
>
>If I can ask which inode is associated with certain file name, and I'll get
>response quickly, there should be some kind of table, which links file names
>to inodes, right?
Right. It's called a directory, and it's a special file.
>Then why it can't do reverse lookup through the same table instead of
>seeking through the whole disk looking for that file name?
There's a many-to-one mapping from directory to inode.
Try this...
touch a.file
ln a.file b.file
ls -li *.file
You'll find that the two files use the same inode
Now, try this
mkdir subdir.for.file
ln b.file subdir.for.file/a.file
ls -li *.file
You'll see that all three files use the same inode
(The inode can be referenced by any file on the physical filesystem,
but cannot be referenced across filesystems.)
Now,
- start with knowing the inode#
- determine which filesystem the inode# resides on
- check *every* directory on that filesystem for *one or more*
files that reference the inode
- report each file found
That's what you have to do to unwind the many-to-one mapping.
>And if that table was constructed like:
> file1 -> 123
> "hard link to file1" -> 123
> file2 -> 456
Sorry, it's
file1 -> 123
file2 -> 123
directory1 -> 456
file4 -> 123
file5 -> 456
>Then it should be no problem to return those two names for #123...
>(Or at least first of them)
No problem, just a simple matter of programming ;-)
(recursive descent through the directory structure, check all files in
all directories, matching against inode#, don't stop until all
directories have been exhaustively checked)
>
>Err, maybe I should get a book: "Understanding ext2 file system" ... :)
>(I wonder if there is one...)
Lew Pitcher, Information Technology Consultant, Toronto Dominion Bank Financial Group
([EMAIL PROTECTED])
(Opinions expressed are my own, not my employer's.)
------------------------------
From: Marty <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system
Subject: Re: Time to read the Disk
Date: Tue, 08 May 2001 21:40:22 +0800
The average seek time is around 4 - 5 ms.
The average rotational latency is 3ms.
Besides, those 20 block requests are seeking to different locations. For each
request, It will seek to a random position and read the disk at a size of
blocksize. The total time taken for 20 requests
for 64KB - 175ms
for 128KB - 330ms
I feel strange because much of the time should be spent on seeking and rotational
latency. Therefore, the difference in blocksize should be account for such large
difference.
Marty.
Kasper Dupont wrote:
> Chan Shing Hong wrote:
> >
> > I test it as follows:
> >
> > Issues 20 block requests randomly where the blocksize is 131072 (128KB) and
> > the time taken is around 330ms.
> > Issues 20 block requests randomly where the blocksize is 65536(64KB) and the
> > time take is just around 175ms.
> >
> > However, I expect the difference should not be so large since the data is
> > sequentially placed.
> >
> > Marty.
>
> That just means that the data transfer rate is approx 8 MB/sec
> and probably the seek time doesn't really affect your result.
> What is the avareage seek time on your disk supposed to be?
>
> --
> Kasper Dupont
------------------------------
From: Rolf Magnus <[EMAIL PROTECTED]>
Subject: Re: Adding file extension recursively
Date: Tue, 8 May 2001 16:01:09 +0200
Chris wrote:
> Look at find(1).
>
> Something like
>
> find . -type f -print | sed 's/^\(.\+\)$/mv \1 \1.gif' | sh
>
> is a way of doing it. Note that this will not work if any
> of the files you are renaming contain whitespace. This is
> not a fundamental problem; it just requires a
> better-written one-liner.
What about:
find . -type f -exec mv \{\} \{\}.gif \;
Note that this will add .gif to the name of every file in the current
directory or a subdirectory of it, regardless of the previous name, so be
careful to not execute it in / or so.
------------------------------
From: Chris <[EMAIL PROTECTED]>
Subject: Re: Adding file extension recursively
Date: Tue, 08 May 2001 15:13:26 +0100
Rolf Magnus wrote:
>
> Chris wrote:
>
> > Look at find(1).
> >
> > Something like
> >
> > find . -type f -print | sed 's/^\(.\+\)$/mv \1 \1.gif' | sh
> >
> > is a way of doing it. Note that this will not work if any
> > of the files you are renaming contain whitespace. This is
> > not a fundamental problem; it just requires a
> > better-written one-liner.
>
> What about:
>
> find . -type f -exec mv \{\} \{\}.gif \;
Very true. I'd forgotten you could use {} multiple times
in the expression ;)
--
Chris Lightfoot -- chris at ex dash parrot dot com -- www.ex-parrot.com/~chris/
Curiosity kills more mice than cats.
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system
Subject: Re: Time to read the Disk
Date: Tue, 08 May 2001 14:25:17 +0000
Marty wrote:
>
> The average seek time is around 4 - 5 ms.
> The average rotational latency is 3ms.
>
> Besides, those 20 block requests are seeking to different locations. For each
> request, It will seek to a random position and read the disk at a size of
> blocksize. The total time taken for 20 requests
> for 64KB - 175ms
> for 128KB - 330ms
>
> I feel strange because much of the time should be spent on seeking and rotational
> latency. Therefore, the difference in blocksize should be account for such large
> difference.
>
> Marty.
>
I suggest you make some more experiments.
Try increasing the number of requests by a
factor 100, that way you will get much more
precise measurements.
Also try more different block sizes from
4 KB to 256 KB. Try to see what happens if
you split your large 128 KB requests into
8 sequential 16 KB requests.
I also suggest you verify what throughput
you can get from sequential reads.
--
Kasper Dupont
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Crossposted-To: comp.os.linux.development.system
Subject: Re: Time to read the Disk
Date: 8 May 2001 14:52:27 GMT
On Tue, 08 May 2001 20:25:11 +0800,
Chan Shing Hong <[EMAIL PROTECTED]> wrote:
>I test it as follows:
>
>Issues 20 block requests randomly where the blocksize is 131072 (128KB) and
>the time taken is around 330ms.
>Issues 20 block requests randomly where the blocksize is 65536(64KB) and the
>time take is just around 175ms.
>
>However, I expect the difference should not be so large since the data is
>sequentially placed.
>
The disk driver software and/or the controller hardware may combine
multiple read requests into one, as long as the requests are for consequtive
disk blocks. Before the disk driver sees your request it is broken up into
page size blocks, so the contigous disk access is what realy matters here.
Villy
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Adding file extension recursively
Reply-To: [EMAIL PROTECTED]
Date: Tue, 08 May 2001 15:12:12 GMT
On Tue, 08 May 2001 14:22:08 +0100, Chris <[EMAIL PROTECTED]> wrote:
>Neoklis wrote:
>>
>> Hi!
>>
>> I have a large number of gif's in a number of directories but the file
>> names don't have the .gif extension. Is there a Linux command or script
>> that can add the file extension recursively? Any hints on how I could
>> write a script if I have to?
>>
>> My thanks in advance!
>
>Look at find(1).
>
>Something like
>
>find . -type f -print | sed 's/^\(.\+\)$/mv \1 \1.gif' | sh
This is one of those situations in which the -exec operator of find is probably
better, rather than so much regular expression processing:
find . <whatever_criteria> -exec mv {} {}.gif \;
------------------------------
Crossposted-To: comp.os.linux.development.system
Subject: Re: How to get a number of processors
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 08 May 2001 10:13:55 -0500
[EMAIL PROTECTED] (Stefaan A Eeckels) writes:
>
> Hitting a raw nerve, eh --I apologize. You indeed spelled out why you needed
> such a function using current technology. I'm merely pointing out that you're
> doing the equivalent of having different file systems on 5.25" and 8" disks,
> as good old Flex did, at the level of processors and scheduling. When you're
I don't really understand what that means.
It's not really a raw nerve. It was just a real world example that I
don't feel a "magic tool" existed to address the issue. I'm really trying to
understand what would of been done differently. In short, without knowing
the number of CPU's, we would of had to do a lot more testing to figure out
how many instances we could actually run. Since we knew we were CPU bound,
we knew it was going to be a 1:1 ratio of instances to processes to get the
job done. The only question was what the minimum number was to still get
the job done within the window. We had it right on the second test run.
> faced with the reality of solving a problem using a particular set of tools,
> you might not think of fixing the tools before tackling the job, but given the
> time and cost overruns you mention, it might not have been a totally useless
> idea to consider upgrading the tools...
>
It was not an option. We were brought in to "do or die" on the project. Another
consulting firm (one of the largest in the world) was not able to finish or make
the project work. Simply put, we had to make it work with what we had because
more money on different tools specific to this project were not coming. I am
one that does believe in the right tool for the job. I have no problem asking
for the right tool. In this case, I'm pretty sure anther tool wouldn't be
coming, however, I'd like to know what the "tool" would be in this case?
You make an _interesting_ argument, however I don't think I buy into it. While
I do offer that my solution was somewhat of a hack, nothing comes into mind that
would really offer an alternate solution. BTW, these were HP 9000 boxen (if
memory serves).
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: inode to filename?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 08 May 2001 15:25:11 GMT
On Tue, 8 May 2001 16:18:46 +0300, Markku Parviainen
<[EMAIL PROTECTED]> wrote:
>If I can ask which inode is associated with certain file name, and I'll get
>response quickly, there should be some kind of table, which links file names
>to inodes, right?
Wrong inference. If you can ask which inode is associated with a file name,
that does not imply there is a table. In fact, there is some other indexing
structure: the filesystem directory tree. You can think of it as a kind of
table, but not one that is represented as a linear array on disk. So scanning
through it causes a lot of drive head movement. There is no reverse
index for efficient lookup.
>Then why it can't do reverse lookup through the same table instead of
>seeking through the whole disk looking for that file name?
It would still be darn inefficient to look through tens of thousands
of entries in a table, even if it were compactly represented on disk.
>And if that table was constructed like:
> file1 -> 123
> "hard link to file1" -> 123
It doesn't quite work this way; both entries are equal. There is no such thing
as a ``hard link to file1''.
> file2 -> 456
>Then it should be no problem to return those two names for #123...
It's not a problem, it's just that there is no interface for doing it, and
there is no need for applications to ever do this mapping.
You can perform such a lookup using the ``debugfs'' interactive tool. This is
useful if you know the inode number of some file (from the output of fsck,
perhaps) and you want to know where it is in the directory structure.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: premature end of script headers
Reply-To: [EMAIL PROTECTED]
Date: Tue, 08 May 2001 15:28:27 GMT
On Tue, 08 May 2001 04:34:25 GMT, Joel Wellington <[EMAIL PROTECTED]> wrote:
>
>I am running a C program from the web and i keep getting the error
>"Premature end of script headers" on a GET of the program. The process
>runs continuously (seen in TOP) and i have to kill it to stop it.
>
>What does this error mean - if i knew i could fix the problem.
Without presenting any of your source code, you will have only slightly
better luck here than, say, if you were to call the Psychic Friends
Network.
My guess is that the program does not properly detect the end of input on
stdin, and gets into an infinite loop. This could happen if, for instance,
it calls getchar() in a loop but doesn't look for EOF.
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Subject: Re: libstdc++ errors when compiling various apps (mozilla, texmacs, ...)
Date: Tue, 08 May 2001 08:26:56 -0700
"_=^> chRØMi$X <^=_" wrote:
> Anyone can give me a hint, a possible solution or a tip?? I hope so,
> since i presume this problem may likely cause problems with other
> packages as well.
We'll need to see what your linking command line looks like. Hint: You
should be running g++.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ I love Mickey Mouse more than any woman I've ever known.
\__/ Walt Disney
Erik Max Francis' bookmarks / http://www.alcyone.com/max/links/
A highly categorized list of Web links.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.system
Subject: Re: Time to read the Disk
Reply-To: [EMAIL PROTECTED]
Date: Tue, 08 May 2001 15:32:14 GMT
On Tue, 08 May 2001 18:12:05 +0800, Chan Shing Hong <[EMAIL PROTECTED]>
wrote:
>I have bind a SCSI disk to a raw device at /dev/raw/raw1
>
>When I try to read 128KB from the disk, I found that the time is about
>the same as TWO reads where each read reads 64KB.
>
>However, I think reading 128KB at a time should be faster than reading
>64KB twice since it may save time on the rotation latency.
Except that modern drives have buffers that store the entire contents of a
cylinder. So the only time rotation latency enters into the equation is when
you move the head from cylinder to cylinder in a linear read of consecutive
blocks. Then latency matters, because depending on where the first block of the
next cylinder starts, it may come under the head in a timely way.
>tell me what's going on? Is the 128KB request broken up into two
>requests???
It's likely broken up into small requests which correspond to the transfer size
between the drive controller and the buffer. Unless you suppose that your
drive has 64 kilobyte sectors. ;)
------------------------------
From: "Zoran Cutura" <[EMAIL PROTECTED]>
Subject: Re: Adding file extension recursively
Date: Tue, 08 May 2001 17:30:58 +0200
Reply-To: [EMAIL PROTECTED]
Once upon a while "Rolf Magnus" <[EMAIL PROTECTED]> wrote:
> Chris wrote:
>
>> Look at find(1).
>>
>> Something like
>>
>> find . -type f -print | sed 's/^\(.\+\)$/mv \1 \1.gif' | sh
>>
>> is a way of doing it. Note that this will not work if any of
>> the files you are renaming contain whitespace. This is not a
>> fundamental problem; it just requires a better-written
>> one-liner.
>
> What about:
>
> find . -type f -exec mv \{\} \{\}.gif \;
>
> Note that this will add .gif to the name of every file in the
> current directory or a subdirectory of it, regardless of the
> previous name, so be careful to not execute it in / or so.
You could concatenate more find commands and filters to get
axactly the files you need. Like if you have a tool that can
tell you wether a file is a gif you could first check with
that tool than check if it doesn't have a .gif extension and
than execute the mv:
find . -type f -exec isgif \{\} \; ! -iname "*.gif" -exec mv \{\} \{\}.gif \;
Still "isgif" remains to be the problem in this script as
I don't know such a tool from the top of my mind. :-)
I just wanted to show how find works.
--
Z ([EMAIL PROTECTED])
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.system
Subject: Re: Time to read the Disk
Reply-To: [EMAIL PROTECTED]
Date: Tue, 08 May 2001 15:33:11 GMT
On 8 May 2001 14:52:27 GMT, Villy Kruse <[EMAIL PROTECTED]>
wrote:
>disk blocks. Before the disk driver sees your request it is broken up into
>page size blocks, so the contigous disk access is what realy matters here.
Note that he said he was using a raw device, not a block device.
------------------------------
Subject: Re: Faster than strstr
From: David Rubin <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 08 May 2001 15:57:12 GMT
DB wrote:
[snip - strstr not fast enough]
> I found strchr() to be the fastest search available on the X86. This
> became the front-end to my new search routine. The result is strchrstr(),
> that uses a fast strchr() to find potential matches, and then does a
> strncmp() on the remainder of the target string.
...or you can try a regex package.
david
--
If 91 were prime, it would be a counterexample to your conjecture.
-- Bruce Wheeler
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
Subject: Re: Faster than strstr
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 08 May 2001 15:58:34 GMT
The speed of a strstr() implementation depends on many factors.
If you need to search for the same pattern repeatedly, splitting
strstr() up into separate initialization and search phases helps.
You might compare your implementation with those in Chapter 2 of
"Software Solutions in C", edited by Dale Schumacher. Its code
was included on a diskette; if you can't find a copy then send
me e-mail at work: [EMAIL PROTECTED]
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
From: Jorge Escalante <[EMAIL PROTECTED]>
Subject: PostgreSQL_question
Date: Mon, 07 May 2001 17:53:57 -0500
This is a multi-part message in MIME format.
==============B2527FEA688F0235D5CC7053
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
==============B2527FEA688F0235D5CC7053
Content-Type: text/plain; charset=us-ascii;
name="PostgreSQL_questions.text"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="PostgreSQL_questions.text"
I just got the book "PostgreSQL Introduction and Concepts" by Bruce Momjian.
The book explains that to create the test database one has to type
the following command at the prompt:
'createdb test'
However, when I do this I get a message that reads:
"Connection to database template1 failed.
FATAL 1: SetUserId: user jorge is not in pg_shadow."
How do I solve this problem? anyone?
==============B2527FEA688F0235D5CC7053==
------------------------------
Subject: Re: Faster than strstr
From: Walter Briscoe <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 08 May 2001 15:59:08 GMT
In article <[EMAIL PROTECTED]> of Mon, 7 May 2001 21:25:09
in comp.lang.c.moderated, DB <[EMAIL PROTECTED]> writes
>My current project for SPI Dynamics made extensive use of the strstr()
>function to detect malicious activity in web server log files. The
>performance of that search routine was quite a bottleneck while LogAlert
>was detecting exploit strings. The strstr() function seemed to be part
>of the problem, I had to find a way to speed things up.
>
>I found strchr() to be the fastest search available on the X86. This
>became the front-end to my new search routine. The result is strchrstr(),
>that uses a fast strchr() to find potential matches, and then does a
>strncmp() on the remainder of the target string.
[snip]
Do you not have access to the source code for strchr and strstr? You may
be able to make a general improvement. If you can't and RHL gives you an
opaque library, you are entitled to report a problem to the supplier.
>TESTING:
>The search space is a 9 Mb text file, searching for a nine character
>target string and looped 255 times. The tests were run on RHL 6.2
>and 7.0. The kernel builds were 2.2.14 and 2.2.16 with glibc versions
>2.1.3 and 2.1.92 respectively.
This looks like a very suitable application for the Boyar-Moore string
searching method. That is a "well known" algorithm which searches a
large string for a fixed short string. It uses the properties of the
short string to optimise the searching of the longer string. It consists
of less than 50 lines of C code and is published. You will find it
fairly easily with Boyar Moore and search. You can whet your appetite
with http://www.cs.utexas.edu/users/best-ideas/string-searching
I have no experience with using this algorithm. It is reported to be
good. From my reading of it, I would expect you to be able to double the
speed of your tests to date (and then some!)
--
Walter Briscoe
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
Subject: Re: Faster than strstr
From: Hans-Bernhard Broeker <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 08 May 2001 15:59:50 GMT
In comp.lang.c.moderated DB <[EMAIL PROTECTED]> wrote:
> I found strchr() to be the fastest search available on the X86. This
> became the front-end to my new search routine. The result is strchrstr(),
> that uses a fast strchr() to find potential matches, and then does a
> strncmp() on the remainder of the target string.
Your "Subject:" line is at least partly misleading. You do not have a
function faster than strstr() --- you have one faster than the
particular implementation of strstr() you're using, on one particular
architecture, for one size range of "needle", and a rather large
"haystack".
Actually, there are algorithms significantly faster than the
standardized strstr() for your particular application profile, and
also faster than yours. Do a literature search on Boyer-Moore
searching, and you'll see.
--
Hans-Bernhard Broeker ([EMAIL PROTECTED])
Even if all the snow were burnt, ashes would remain.
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
Reply-To: "Nils O. Selåsdal" <[EMAIL PROTECTED]>
From: "Nils O. Selåsdal" <[EMAIL PROTECTED]>
Subject: Re: Adding file extension recursively
Date: Tue, 8 May 2001 18:02:04 +0200
"Zoran Cutura" <[EMAIL PROTECTED]> wrote in message
news:9d93cm$6n9$[EMAIL PROTECTED]...
> Once upon a while "Rolf Magnus" <[EMAIL PROTECTED]> wrote:
>
> > Chris wrote:
> >
> >> Look at find(1).
> >>
> >> Something like
> >>
> >> find . -type f -print | sed 's/^\(.\+\)$/mv \1 \1.gif' | sh
> >>
> >> is a way of doing it. Note that this will not work if any of
> >> the files you are renaming contain whitespace. This is not a
> >> fundamental problem; it just requires a better-written
> >> one-liner.
> >
> > What about:
> >
> > find . -type f -exec mv \{\} \{\}.gif \;
> >
> > Note that this will add .gif to the name of every file in the
> > current directory or a subdirectory of it, regardless of the
> > previous name, so be careful to not execute it in / or so.
>
> You could concatenate more find commands and filters to get
> axactly the files you need. Like if you have a tool that can
> tell you wether a file is a gif you could first check with
> that tool than check if it doesn't have a .gif extension and
> than execute the mv:
>
> find . -type f -exec isgif \{\} \; ! -iname "*.gif" -exec mv \{\} \{\}.gif
\;
>
> Still "isgif" remains to be the problem in this script as
[nilsolav@LabSrv nilsolav]$ file
/usr/doc/console-tools-19990829/dvorak/ANSI-dvorak.gif
/usr/doc/console-tools-19990829/dvorak/ANSI-dvorak.gif: GIF image data,
version 89a, 404 x 172,
file {} |grep GIF might be a start ?
------------------------------
From: Chris <[EMAIL PROTECTED]>
Subject: Re: Adding file extension recursively
Date: Tue, 08 May 2001 17:03:18 +0100
Zoran Cutura wrote:
>
> find . -type f -exec isgif \{\} \; ! -iname "*.gif" -exec mv \{\} \{\}.gif \;
>
> Still "isgif" remains to be the problem in this script as
> I don't know such a tool from the top of my mind. :-)
> I just wanted to show how find works.
if [ x`dd if=$1 bs=5 count=1 2> /dev/null` = xGIF89 ] ; then
exit 0
else
exit 1
fi
... but I won't claim that this is the most efficient
implementation.
--
Chris Lightfoot -- chris at ex dash parrot dot com -- www.ex-parrot.com/~chris/
The University of California Department of Statistics...
where mean is normal, and deviation standard
------------------------------
Reply-To: "Nils O. Selåsdal" <[EMAIL PROTECTED]>
From: "Nils O. Selåsdal" <[EMAIL PROTECTED]>
Subject: Re: how to list files in a directory with C?
Date: Tue, 8 May 2001 18:03:47 +0200
"clement" <[EMAIL PROTECTED]> wrote in message
news:9d0meh$b2b$[EMAIL PROTECTED]...
> I want to make list of the files there are in a directory?
> how function can i use with C?
>
> Thanks in advance!
from man scandir
/* print files in current directory in reverse order */
#include <dirent.h>
main(){
struct dirent **namelist;
int n;
n = scandir(".", &namelist, 0, alphasort);
if (n < 0)
perror("scandir");
else
while(n--) printf("%s\n", namelist[n]->d_name);
}
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.apps newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-Apps Digest
******************************
