[ Date Index ][
Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]
On Friday 04 Jul 2003 11:38 pm, Jonathan Melhuish wrote:
> On Friday 04 July 2003 20:52, Neil Williams wrote:
> > On Friday 04 Jul 2003 4:26 pm, Jonathan Melhuish wrote:
> > > On Wednesday 02 July 2003 23:50, Neil Williams wrote:
> You may well be right. It's difficult to find out through trial and error
> as Google doesn't seem to spider my site very regularly. :-( But in case
> it doesn't like the "=", I've added a link to "List all products", which is
> a plain HTML page linking with reasonably plain links to reasonably plain
> HTML product information pages. Can you see any reason why it wouldn't
> index that?
No. I don't understand Google's spider schedule either. It seems to spider the
DCLUG archive very regularly. I updated the GnuPG page on DCLUG and it now
includes my own keyid as a reference in the example code. Entering 28bcb3e3
in Google found the page less than a WEEK after I'd posted it! My CodeHelp
pages seem to have a longer interval. I have found Google to be consistently
faster at indexing my pages compared to the older engines like AltaVista,
Excite, Lycos etc., yet the same pattern is evident - DCLUG pages get indexed
quicker than the codehelp pages. e.g. In Excite, if I enter 28bcb3e3, I only
got the DCLUG hits. In Google, I get the DCLUG and my CodeHelp Key Download
page (as well as lots of pages from the gnupg-users archive too) - both pages
were created within days of each other. I've just tried the Freeserve search
engine - same search, DCLUG shows up but not codehelp. Lycos is the same but
helpfully also offers to sell me 28bcb3e3 via eBay. Doh!
> As I say, I've put an actually-really static page in with links to all of
> the products, and the product information pages appear to be static HTML
> pages anyway.
Maybe it also has something to do with how often the site appears to be
updated. DCLUG obviously wins out there over codehelp because like other
mailing-list archive sites, it is updated daily. That might also explain why
when I use Google to help with list enquiries, I'm often directed to other
archive sites on sourceforge etc.
> > After hearing so many horror stories of e-commerce tools, I won't be
> > looking to gain any experience of them anytime soon!!
>
> I still think it *can* be a better option that re-inventing the wheel
> yourself, but it's tricky to suss out the pros and cons of different
> ecommerce suites without actually using them. And by the time you've
> developed your store, tested it a bit, let your client loose on it,
> accepted some orders... it's too late to switch! :-(
It's always a trade-off. If you write the site yourself then you will use
tools that you know, but probably get caught out with bugs in the code that
other sites have solved a long time ago. Use an all-in tool developed by
someone else then you save time but swap one set of bugs (in an application
you understand) for another set (in a tool that you don't understand). This
is where open source really can win - I enjoy reading the gnupg-users list
because I keep seeing the main developers replying to the list saying "OK,
good idea. It'll be implemented in the next version" or "Thanks for pointing
that out, I'll change it." Developers responding to users in real time and in
real situations is what it's all about. Not all Linux projects are as good
but the best are true role models.
> I should have posted this earlier to save, I didn't think anybody was
> actually going to help me so I didn't bother ;-) I know Perl's probably
> better for pattern-matching etc., but as I was developing a BASH script I
> thought I'd just stick it in there. So I just used 'sed' like this:
>
> find . -type f -name '*' |while read -r AFILE
> do
> sed '/sms.ic\//s///g' "$AFILE" > "$AFILE.stripped";
> cp "$AFILE.stripped" "$AFILE";
> done
OK, but don't forget that bash can use perl directly, so why not make the most
of Perl's superior abilities? Just call the file with the perl interpreter,
as you would on the command line. $ perl <filename> There are also command
line options too, so if the code is brief you don't even need a file.
> Piping the output straight back to the same file seemed to turn them all
> zero-length, I don't quite understand why, but the above seems to work.
You missed an option:
$ info sed.
->Invocation
``-i'[SUFFIX]'
``--in-place[=SUFFIX]''
This option specifies that files are to be edited in-place. GNU
`sed' does this by creating a temporary file and sending output to
this file rather than to the standard output(1).
When the end of the file is reached, the temporary file is renamed
to the output file's original name.
The extension, if supplied, is used to modify the name of the old
file before renaming the temporary file (thereby making a backup
copy(2)) following this rule: if the extension doesn't contain a
`*', then it is appended to the end of the current filename as a
suffix; if the extension does contain one or more `*' characters,
then _each_ asterisk is replaced with the current filename. This
allows you to add a prefix to the backup file, instead of (or in
addition to) a suffix, or even to place backup copies of the
original files into another directory (provided the directory
already exists).
> The only trouble is that I'm not quite sure how to surgically insert this
> into Interchange. I think a more likely solution is that I get this
With the value of the search string components stored in @matches, it can be
output in any format you desire - use a new delimiter for static pages, use
the component to dictate the directory to write the new file into, revert to
the old delimiter for Interchange export, store in a database or flat file
for some other reason, etc. You would just add to the foreach loop to create
a new string containing the components in the original sequence and drop a
new delimiter in:
my $newstring;
foreach $content (@matches) {
$newstring .= $content . "#";
> $c++;
> print "Content $c: $content\n";
> }
newstring would then contain the search string with each / replaced with one #
(There are more efficient ways of doing this using join() but as the loop was
already in the example I chose that way. join() is the opposite of split()
used earlier in the same script.)
> suite available at the time (although I might have been wrong). Certainly
> now something like OSCommerce, which uses PHP, Apache and MySQL rather than
> trying to do it all itself like Interchange, seems like a much better
> solution. I'll have to have a play with it before I can decide, but at
> first glance it looks far more elegant.
100% agree. These three are truly standard bearers. It's even being called the
PAM platform in some circles. Reliability, scalability, performance,
ease-of-use, ease-of-design, flexibility, plentiful error logs and reporting
methods, fully open source components - PAM has everything.
Apache: No-one's going to blame you for choosing Apache over any other web
server.
MySQL: There are other databases out there, but none with the same level of
interoperability with PHP and Perl for the same performance or scalability.
PHP: Not just a HTML engine, excellent MySQL integration, XML parser included,
graphics generation in real time. PHP isn't only for .php files either, I'm
beginning to look at PHP to write programs that operate outside the Apache
environment as well as writing customised modules for PHP to use in Apache.
> Thanks very much for your help!
Don't thank me, thank Linus for making it possible! Would any of this happen
without Linux?
--
Neil Williams
=============
http://www.codehelp.co.uk
http://www.dclug.org.uk
http://www.wewantbroadband.co.uk/
Attachment:
pgp00021.pgp
Description: signature