Linux-Development-Apps Digest #390, Volume #7 Wed, 9 May 01 01:13:09 EDT
Contents:
Re: Linux Perl Client -> MSSQL Server 2000; Can be possible? ("Kawai,Takanori")
Re: inode to filename? ("Markku Parviainen")
Re: inode to filename? ([EMAIL PROTECTED])
5th Annual Linux Showcase & Conference: Call for Papers (Tiffany Peoples)
Re: Faster than strstr (Kevin Ashley)
Re: inode to filename? (Sam Shah)
Re: Faster than strstr ("Kevin D. Quitt")
Re: Faster than strstr ("Kevin D. Quitt")
Re: Faster than strstr ("Edward Rosten")
Re: Faster than strstr ("Edward Rosten")
Re: Faster than strstr ("Douglas A. Gwyn")
Re: Adding default libraries to every link (Kaz Kylheku)
Re: how to have owner, size, and group of a file? (Kaz Kylheku)
Re: PostgreSQL_question (Carlos Moreno)
Re: Adding default libraries to every link (John Hasler)
Re: Faster than strstr (Chris Kern)
Re: Faster than strstr (Ben Pfaff)
----------------------------------------------------------------------------
From: "Kawai,Takanori" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.modules,comp.databases,comp.databases.ms-sqlserver
Subject: Re: Linux Perl Client -> MSSQL Server 2000; Can be possible?
Date: Wed, 9 May 2001 07:28:37 +0900
"Jose Gilberto Torres" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi to everyone in cyberspace!,
> I don't know the appropriate newgroup to ask this question so please
> don't attack me for it :-) !! I have be searching all over the 'net
> to find a way to get a Linux (or Solaris) perl client script to access
> data from a MSSQL Server 2000 server. So far I found the OpenLink
> driver but on my box it continues to seg fault on me when I try to
> access these drivers. I was wondering if anyone had successfully able
> to do get perl and mssql to talk to each other. So far it does not seem
> to be possible. I hope I am wrong? Help? Thanks!!!!!!
Hi.
These pages may be a help for you.
DBI
http://dbi.symbolstone.org/index.html
esp. "Mailing List"
Connecting UNIX and Microsoft Access / SQLServer Tutorial
http://tlowery.hypermart.net/perl_dbi_dbd_faq.html
FreeTDS
http://www.freetds.org/
FreeTDS FAQ - 3.4 Which Perl library should I use?
http://www.freetds.org/faq.html#34
==============================================
Kawai, Takanori(Hippo2000)
Mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
http://member.nifty.ne.jp/hippo2000
==============================================
------------------------------
From: "Markku Parviainen" <[EMAIL PROTECTED]>
Subject: Re: inode to filename?
Date: Wed, 9 May 2001 01:48:31 +0300
Ok, thanks. I think I got it.
I just didn't understand (/remember the existence of) the concept
'directory' in this context earlier.
I mean I thought the situation as there were only one directory (and so one
big table), where it would look for inodes, but there are plenty of them, of
course.
But I can see the light again now! :)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: inode to filename?
Date: Tue, 08 May 2001 23:28:07 GMT
"Markku Parviainen" <[EMAIL PROTECTED]> writes:
> Ok, thanks. I think I got it.
> I just didn't understand (/remember the existence of) the concept
> 'directory' in this context earlier.
> I mean I thought the situation as there were only one directory (and
> so one big table), where it would look for inodes, but there are
> plenty of them, of course.
> But I can see the light again now! :)
It might have seemed natural for there to be some sort of "reverse
lookup;" whether fortunately or unfortunately, the only way to look up
a filename is to search _all_ the filenames in the potentially many
directories out there.
The fact that an inode can be attached to multiple filenames (e.g. -
with hard links) makes it a bit nonsensical to think that there is a
single valid name to attach to the inode.
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://vip.hex.net/~cbbrowne/resume.html
Would-be National Mottos:
Poland: "We probably would have had a happier history if we were
between Canada and Mexico, not Germany and Russia."
------------------------------
From: Tiffany Peoples <[EMAIL PROTECTED]>
Subject: 5th Annual Linux Showcase & Conference: Call for Papers
Date: Tue, 08 May 2001 16:37:22 -0700
5th Annual Linux Showcase & Conference (ALS 2001)
November 6-10, 2001
Oakland, CA USA
http://www.linuxshowcase.org
Sponsored by USENIX and the Atlanta Linux Showcase, Inc., in cooperation
with Linux International
Now in its fifth year, the Annual Linux Showcase & Conference
http://www.linuxshowcase.org continues its remarkable development as the
premier technical Linux conference, attracting talks by experts on
everything from kernel internals to Internet services, panels discussing
the state of the Kernel, Linux in the real world, xfree86, and more.
And this year, ALS breaks with tradition by moving out of Atlanta to the
SF Bay Area!
The ALS 2001 Program Committee invites you to contribute your ideas,
proposals, and papers for tutorials, invited talks, refereed technical
papers, and work-in-progress reports. We welcome submissions that
address any and all issues relating to Linux and the Open Source world.
The Call for Papers with submission guidelines and suggested topics is
now available at http://www.linuxshowcase.org
Submissions are due June 5, 2001
The first XFree86 Technical Conference will run concurrently with ALS on
November 7 & 8. If you are a developer building applications and systems
using XFree86, plan to submit a paper or attend this event. For more
information check: http://www.usenix.org/events/xfree86/
Please join us and participate in the premier technical conference for
Linux enthusiasts and professionals! We look forward to seeing you in
Oakland in November 2001!
===============================================================
5th Annual Linux Showcase & Conference (ALS 2001) is sponsored by
USENIX, the Advanced Computing Systems Association, and the Atlanta
Linux Showcase, in cooperation with Linux International.
===============================================================
------------------------------
Subject: Re: Faster than strstr
From: Kevin Ashley <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 08 May 2001 23:38:29 GMT
DB wrote:
>
> 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.
There are much more optimal ways to search for a target string in
a body of text. For a review of some of them, see an article in the
journal "Software Practice and Experience" from some considerable
number of years ago (can't recall, except I know it must be pre-1985.)
My recollection was that the best general algorithm was not dissimilar
to yours (use strchr, then do some matching) but with some critical
differences. Primarily, it depended on knowledge of likely letter frequencies
in the searched text. A full explanation is off-topic for almost all the
groups you posted to (IMHO), but you basically search first for the letter
in the target which is least likely to occur. You also construct a jump
table which tells you, having examined a particular letter, how many tests
you can skip. E.g. you are searching for "easy". You start by looking
at the 4th letter of the sample text and see if it is "y". If it isn't,
but is (say) an "m", you can skip the next three letters and examine
position 8 to see if it is "y". And so on.
Better algorithms exist for more tightly-defined problem spaces, but this
is easy to implement and provably fast. It has the advantage that search
speed increases as the length of the target string increases. (OK, that's
sometimes an advantage and sometimes not so good.)
Kevin Ashley
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Sam Shah)
Subject: Re: inode to filename?
Date: Tue, 8 May 2001 19:37:35 -0400
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?
A directory is just a file (with some directory bits flagged in its
inode) containing a list of (file name,inode) pairs. This involves a
linear search to find a file's inode in a directory [1].
You'd have to search the entire inode's filesystem for the inode
because the (file name, inode) pair is only stored in the directory
containing the file. There may be more than one file name associated
with an inode because of hard-links.
> 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 isn't a single table, tree, or other data structure that
encompasses the entire file system because of reliability issues.
Imagine there was a single-sector failure on this meta data: a large
portion of the directory structure and its accompanying inode pointers
may be lost.
> 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)
A special ``hard-link'' flag does not exist. An inode's basic
structure is:
File mode Flags that store file type,
read/write/execute permissions (usually 16-bits)
Link count Number of directory references to this inode
Owner ID
Group ID
File Size
File Addresses 39 bytes of address information
Last Accessed
Last Modified
Inode Modified
When a file is hard-linked, its link count is incremented and
conversely when it's unlinked, its link count is decremented. When the
inode's link count goes to 0, its disk blocks can be added to the free
block bit table (or free block list) and the inode reused.
[1] Performance is not impacted as most directories contain few files
(people usually don't like it when ``ls'' scrolls a page) and this
data structure can easily be cached. A second reason for this
structure is that it is very space efficient.
------------------------------
Subject: Re: Faster than strstr
From: "Kevin D. Quitt" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 08 May 2001 23:38:48 GMT
On 08 May 2001 15:59:08 GMT, Walter Briscoe <[EMAIL PROTECTED]>
wrote:
>http://www.cs.utexas.edu/users/best-ideas/string-searching
That link's dead. Try
http://www-igm.univ-mlv.fr/~lecroq/string/node14.html
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91351-4454 96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
Subject: Re: Faster than strstr
From: "Kevin D. Quitt" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 08 May 2001 23:39:25 GMT
FWIW, the name you've chosen for your function is reserved.
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91351-4454 96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
Subject: Re: Faster than strstr
From: "Edward Rosten" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 08 May 2001 23:42:21 GMT
In article <[EMAIL PROTECTED]>, "David Rubin"
<[EMAIL PROTECTED]> wrote:
> 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.
Surely, regex, which is more complex than strstr will be slower?
-Ed
--
You can't go wrong with psycho-rats.
u 9 8 e j r (at) e c s . o x . a c . u k
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
Subject: Re: Faster than strstr
From: "Edward Rosten" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 08 May 2001 23:42:49 GMT
> with http://www.cs.utexas.edu/users/best-ideas/string-searching I have
This URL 404's. Do you have another?
cheers
-Ed
--
You can't go wrong with psycho-rats.
u 9 8 e j r (at) e c s . o x . a c . u k
--
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 23:43:06 GMT
Walter Briscoe wrote:
> This looks like a very suitable application for the Boyar-Moore string
> searching method. ...
> 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!)
Yes, Boyer-Moore tends to be best for the "average" string search
application; double the naive approach's speed is about right.
If one is searching for multiple occurrences of the same string,
the pattern set-up phase can be amortized over several searches.
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Adding default libraries to every link
Reply-To: [EMAIL PROTECTED]
Date: Wed, 09 May 2001 01:36:26 GMT
On Tue, 08 May 2001 19:30:04 GMT, Norm Dresner <[EMAIL PROTECTED]> wrote:
>Kaz Kylheku <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> On Mon, 07 May 2001 23:51:10 GMT, Norm Dresner <[EMAIL PROTECTED]>
>wrote:
>> >Sure. As they say, "Been there, done that." I was hoping for something
>> >with the utter simplicity of the VMX approach, where
>> > cc -o b b.c
>> >would search through several "local" libraries without "manual
>> >intervention".
>>
>> What does that do? Just look in some bunch of libraryes for symbols or
>objects
>> that satisfy unresolved references in b? Shouldn't b.c kind of know what
>> library it wants and be accompanied with some kind of build system?
>>
>> Why don't we treat headers that way too:
>>
>> /* start of file, no #include's */
>> struct foo x; /* Just find this in some ``local'' header */
>>
>> And of course, the user should just have to type
>>
>> cc
>>
>> and it will find some "local" program to build. ;)
>
>Did you erase every script file from your system because you can just type
>it all in again and again and again.
>
>Have you deleted all aliases from your system too. And links?
I simply don't see the big inconvenience in actually declaring to your tools
what objects and libraries your program is made up of.
I also don't understand how you inferred that I want to type this information
from scratch each time I want to rebuild the program.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: how to have owner, size, and group of a file?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 09 May 2001 01:42:10 GMT
On Tue, 8 May 2001 12:00:37 +0200, clement <[EMAIL PROTECTED]> wrote:
>I want to have the owner, the size, and the group of a file?
>how function can i use with C?
Use the stat() function if you know the path name of the file.
If, in the case that the file is actually a symbolic link, and you want to
examine the properties of the link itself rather than the file it points to,
use lstat().
If you have an open descriptor, you can use fstat() on it.
This is all in the stat man page.
------------------------------
From: Carlos Moreno <[EMAIL PROTECTED]>
Subject: Re: PostgreSQL_question
Date: Tue, 08 May 2001 23:23:11 -0400
Jorge Escalante wrote:
>
> It worked, I could use the command 'su postgres'. Now, it is asking me for the
> password, and I don't have a clue what it is!
Normally, the user postgres does not have a password, so only the root
user can su to that user (user root doesn't need to provide a password
to su to any user). Well, at least that's the setup on RedHat... I
presume that Debian does the same thing.
If you don't have root access, then you'll have to ask the administrator
to do it for you (loging in as user postgres and creating the db users
that you need, or set up the privileges). If your administrator doesn't
like you, then I'm affraid you're out of luck! :-)
HTH,
Carlos
--
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Subject: Re: Adding default libraries to every link
Date: Wed, 9 May 2001 02:31:48 GMT
Norm Dresner writes:
> I was hoping for something with the utter simplicity of the VMX approach,
> where
> cc -o b b.c
> would search through several "local" libraries without "manual
> intervention".
I prefer the utter simplicity of the UNIX approach, where simply typing
'make' takes care of everything without "manual intervention".
--
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin
------------------------------
Subject: Re: Faster than strstr
From: [EMAIL PROTECTED] (Chris Kern)
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 09 May 2001 04:15:34 GMT
On 08 May 2001 23:42:21 GMT, "Edward Rosten" <[EMAIL PROTECTED]> posted the
following:
>In article <[EMAIL PROTECTED]>, "David Rubin"
><[EMAIL PROTECTED]> wrote:
>
>> 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.
>
>Surely, regex, which is more complex than strstr will be slower?
It would depend on the algorithm used, wouldn't it? I can imagine a
brute-force string matching algorithm going slower than a regexp
package which uses a better algorithm.
-Chris
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
Subject: Re: Faster than strstr
From: Ben Pfaff <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c.moderated,comp.lang.c
Date: 09 May 2001 04:15:43 GMT
"Edward Rosten" <[EMAIL PROTECTED]> writes:
> Surely, regex, which is more complex than strstr will be slower?
A Pentium III is more complex than an 8086, but which is slower?
--
"When in doubt, treat ``feature'' as a pejorative.
(Think of a hundred-bladed Swiss army knife.)"
--Kernighan and Plauger, _Software Tools_
--
comp.lang.c.moderated - moderation address: [EMAIL PROTECTED]
------------------------------
** 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
******************************
