Skrivet detta inlägg mera som en blog för att få med att det kanske är fler än du som har det svårt med Linux.

Själv går jag under kategorin nybörjare. Vilket har resulterat i att detta ”projekt” har tagit all fritid under minst 2 månader.

Nu finns det mycket felstavningar etc som jag ej orkar kolla igenom då projektet havererade på upploppet.

Ni som är intresserad läs igenom då det förhoppningsvis finns något mat nyttigt att ta till sig.

Skriv gärna någon synpunkt/komentar (längst ner på sidan). Alltid roligt med komentarer.

Hårdvara : qnap TS-219P II

Operativ : Debian Squeeze http://www.cyrius.com/debian/kirkwood/qnap/ts-219/install.html

Först skapar vi en användare i linux

adduser dokuwiki

sedan skapar vi användare i samba

smbpasswd -a dokuwiki

sedan lägger vi till användaren www-data (apache körs under den användaren) i gruppen för dokuwiki

enklast är det att editera /etc/group

nano /etc/group
......
crontab:x:102:
ssh:x:103:
Debian-exim:x:104:
mlocate:x:105:
ssl-cert:x:106:
pernils:x:1000:
mysql:x:107:
messagebus:x:108:
sambashare:x:109:
dokuwiki:x:1001:dokuwiki,www-data

sedan ändrar vi ägargruppen på media bibloteket

root@qnap:~# cd /var/www/dokuwiki/data
root@qnap:/var/www/dokuwiki/data# chown www-data:dokuwiki media
root@qnap:/var/www/dokuwiki/data#

Dubbel kolla att det vart rätt

root@qnap:/var/www/dokuwiki/data# ls -l
totalt 68
drwxr-xr-x  2 www-data www-data  4096 28 jan 17.24 attic
drwxr-xr-x 17 www-data www-data  4096 28 jan 17.28 cache
-rw-r--r--  1 www-data www-data  7180 25 jan 14.39 deleted.files
-rw-r--r--  1 www-data www-data     0 25 jan 14.39 _dummy
drwxr-xr-x  2 www-data www-data  4096 28 jan 17.24 index
drwxr-xr-x  2 www-data www-data  4096 28 jan 17.32 locks
drwxrwxr-x  4 www-data dokuwiki  4096 28 jan 17.28 media
drwxr-xr-x  2 www-data www-data  4096 25 jan 14.39 media_attic
drwxr-xr-x  2 www-data www-data  4096 28 jan 16.59 media_meta
drwxr-xr-x  2 www-data www-data  4096 28 jan 16.51 meta
drwxr-xr-x  4 www-data www-data  4096 28 jan 16.44 pages
-rw-r--r--  1 www-data www-data  7917 25 jan 14.39 security.png
-rw-r--r--  1 www-data www-data 12093 25 jan 14.39 security.xcf
drwxr-xr-x  2 www-data www-data  4096 28 jan 17.02 tmp
root@qnap:/var/www/dokuwiki/data#

Nu kan samba användaren (dokuwiki) lägga till filer men inte ta bort filer som lagts till genom Media Manager i dokuwiki.

Men Media Manager i dokuwiki kan ta bort filerna som lagts till av samba användaren.

Om vi nu skulle lägga till samba användaren i gruppen www-data så har vi ett säkerhetsproblem då användaren kan ta bort programfiler ur själva wikin.

Sedan måste vi lägga till själva utdelningen i smb.conf

nano /etc/samba/smb.conf

gör en ny utdelning

[dokuwiki]
    path = /var/www/dokuwiki/data/media
    browseable = yes
    writable = yes
    create mask = 0775
    directory mask = 0775

Nu kan vi komma åt utdelningen ifrån windows \\servernamn_eller_ip_address\dokuwiki

En bra länk att läsa http://lists.debian.org/debian-user/2007/06/msg00382.html

Nästa sak att ordna är att vi vill kunna hantera filer med åäö.

(Om ni nu använder er av SSH via putty kom ihåg att sätta Translation till UTF-8.)

Först måste vi se till att våran server kör rätt locale (sv_SE.UTF-8)

root@qnap:/var/www/dokuwiki/data# env
TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=192.168.1.2 1443 22
SSH_TTY=/dev/pts/0
USER=root
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/var/www/dokuwiki/data
LANG=sv_SE.UTF-8
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=192.168.1.2 1443 192.168.1.12 22
_=/usr/bin/env
OLDPWD=/var/www/dokuwiki/data/media
root@qnap:/var/www/dokuwiki/data#

Om ni inte har det så kör ni komandot

root@qnap:/var/www/dokuwiki/data# dpkg-reconfigure locales

När det är ordnat så gäller det att även ställa in Apache genom att lägga till AddDefaultCharset = UTF-8 i /etc/apache2/sites-available/default

root@qnap:/etc/apache2/sites-available# nano default

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
    
        AddDefaultCharset UTF-8
        .....
        ...

När det är klart så måste vi även installera ett plugin i Dokuwiki så att filer som läggs in med hjälp av Media Manager bibehåller sitt namn.

http://www.dokuwiki.org/plugin:preservefilenames

Nu kan vi lägga in filer med namn som innehåller åäö ifrån Media Manager men tyvär inte ifrån samba share. Likaså är det med stora bokstäver. Finns beskrivit i länken ovan.

Eftersom vi kan lägga in vad som helst ifrån samba share så måste vi ha koll på att filändelsen finns registrerad i filen mime.conf.

/var/www/dokuwiki/conf/mine.conf

http://www.dokuwiki.org/mime

Om ändelsen inte finns registrerad så går det inte att lägga till den filen likaså syns den inte i Media Manager.

För att kunna komma till rätta med det lite enklare än att hela tiden SSH till servern och ändra i mim.conf gör vi så här.

root@qnap:cd /var/www/dokuwiki/data/pages
root@qnap:/var/www/dokuwiki/data/pages# mkdir config
root@qnap:/var/www/dokuwiki/data/pages# cd config
root@qnap:/var/www/dokuwiki/data/pages/config# ln -s /var/www/dokuwiki/conf/mime.conf mime_conf.txt

Kom ihåg nu att du redigerar själva mime.conf så att du inte raderar den. För säkerhetsskull ta en backup.

root@qnap:/var/www/dokuwiki/data/pages/config# cp /var/www/dokuwiki/conf/mime.conf /var/www/dokuwiki/conf/mime.conf.bakup

För att kunna göra interna länkar med åäö (ex. översta sidan så måste vi sätta deaccent till av i inställningar under admin.

Vad som inte funkar är att skapa sidan med åäö direkt i URL:en (ex. 192.168.1.12/dokuwiki/doku.php?id=ööö).

Någon som har en lösning?

Vad som återstår är ett script som lägger in dom filerna som har stora bokstäver samt åäö i rätt format i bibloteket media_meta.

Tyvärr har jag inte ett något sådant men kanske någon som är mera kunnig kanske skulle kunna bistå med det.

En sista sak som inte har med själva dokuwiki och samba är att istället för att använda AllowOverride All som ger en viss prestanda förlust då apache hela tiden skall läsa .htaccess filerna.

utan används istället AllowOverride None och LocalMatch istället för att begränsa åtkomsten.

Min konfiguartion

<VirtualHost *:80>
        ServerAdmin webmaster@localhost

        AddDefaultCharset UTF-8

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

    #  for dokuwiki to not use the AllowOverride All
        <Directory /var/www/dokuwiki>
            order deny,allow
            allow from all
        </Directory>
    # deny sub directorys  data|conf|bin|inc
        <LocationMatch "/dokuwiki/(data|conf|bin|inc)/">
            order allow,deny
            deny from all
            satisfy all
        </LocationMatch>

Iden bakom detta projekt är att kunna importera dokument in i wikin så att dom blir sökbar.

Efter att hitta sidan http://www.dokuwiki.org/tips:doc_to_wiki_syntax?&#dokuwiki__top så började jag nysta i hur man skulle kunna göra.

Sökandet gav ingen lösning på problemet. Det makro som fanns att tillgå gav bara bildreferensen i löpande format [picture1.png] .. [picture2.png] etc. Bilderna i sig själv sparades inte ut.

Om du själv vill testa så har du makrot http://www.ooowiki.de/Writer2DokuWiki

Sedan vad du skall ändra för att få med länken till bilderna http://www.dokuwiki.org/tips:openofficemacro

Klistrar inte in koden på justerat makro då det tar alldeles för stor plats. Men ovanstående länkar borde ge tillräckligt med information.

Tog mig en funderade över om man har många dokument som skall konverteras. Blir lite jobbigt att göra varje fil för sig.

Letade och hittade ett verktyg (makro) som körs i OpenOffice som kan batch köra hela biblotek.

http://oooconv.free.fr/batchconv/batchconv_en.html

Hittade även ett annat bra makrohttp://extensions.services.openoffice.org/project/writertools. writertools kan även exportera direkt till wiki syntax.

OpenOffice i headless mode körs i java och det är ett stort och minneskrävande app. att dra igång.

Eftersom jag har provat alfresco på en lite sämre maskin och då den gick i stå när jag lade upp dokument så började jag kolla efter andra alternativ.

Fastande då istället för själva konverteringen pdf → html → wiki syntax.

Och skall man hård dra det så är pdf att fördra som utgångspunkt för då man kan till exempel ta ritningar som är utskriven som pdf. Dock kommer stordelen av innehållet att bli en bild men själva filnamnet får ju man med i indexeringen.

Så började en lång veckas letande efter lösning på pdf → html.

Hittade ett programpaket kallad pdftohtml http://pdftohtml.sourceforge.net/

Tog ner version 0.39 och skulle kompilera som alltid ges bilden av att det är så härligt. Det vart stopp direkt. Dels hade jag ingen kompilator och inte make scriptet.

apt-get install make g++ gcc

Efter det så haltade kompileringen ändå. Efter mera letande så fanns att det var en anrops procedur som hade ändrat sin syntax.

källa http://sourceforge.net/tracker/?func=detail&aid=2008566&group_id=45839&atid=444240

Vad som sägs är att man skall ändra i HtmlLinks.h

diff ./pdftohtml-0.39/src/HtmlLinks.h.orig
./pdftohtml-0.39/src/HtmlLinks.h
22c22,24
< GBool HtmlLink::isEqualDest(const HtmlLink& x) const;
---
> /* yoyo fix */
> /* GBool HtmlLink::isEqualDest(const HtmlLink& x) const; */
> GBool isEqualDest(const HtmlLink& x) const;

Okej den kompilerade med en massa varningar :pdftohtml.cc:136: warning: deprecated conversion from string constant to ‘char*’

Dessa skulle enligt http://blog.wolffmyren.com/2008/05/02/g-warning-deprecated-conversion-from-string-constant-to-%E2%80%98char%E2%80%99/ inte vara något problem utan bara en varning.

I alla fall dök programmet upp i pdftohtml-0.39/src# men jag sökte andra alternativ på pdftohtml. Hittade till slut att det även fanns med i paketet poppler-utils.

Lite mera info om ämnet http://doc.nuxeo.com/display/KB/Document+preview+is+not+satisfactory

apt-get install poppler-utils

Eftersom jag kör debian så får jag bara version 0.12 (tror det var det) på pdftohtml. Det har med att göra med att den är den enda stabila utgåvan. Den gamla versionen roterar alla bilderna i pdf filen 90 grader av någon anledning. Fine då tar jag och kompilerar den själv då. http://poppler.freedesktop.org/ Tog hem 0.18.3

root@qnap:/var/www/pdf/#wget http://poppler.freedesktop.org/poppler-0.18.3.tar.gz
root@qnap:/var/www/pdf/#tar -xvf oppler-0.18.3.tar.gz
root@qnap:/var/www/pdf/#cd poppler-0.18.3
root@qnap:/var/www/pdf/poppler-0.18.3#./configure
..
..
checking for freetype-config... no
checking which font configuration to use... fontconfig
checking for FONTCONFIG... no
configure: error: in `/var/www/pdf/dd/poppler/poppler-0.18.3':
configure: error: The pkg-config script could not be found or is too old.  Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

Alternatively, you may set the environment variables FONTCONFIG_CFLAGS
and FONTCONFIG_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

To get pkg-config, see <http://pkg-config.freedesktop.org/>.
See `config.log' for more details

Fick installera pkg-config

root@qnap:/var/www/pdf/poppler-0.18.3/#apt-get install pkg-config

Varningar igen angående PKG_CONFIG_PATH och fontconfig… mera sökande gav http://www.linuxquestions.org/questions/linux-software-2/how-to-adjust-pkg_config_path-fontconfig-2-4-0-config-error-490541/

root@qnap:/var/www/pdf/poppler-0.18.3/# locate pkgconfig
/usr/lib/pkgconfig
/usr/share/pkgconfig
/usr/share/pkgconfig/iso-codes.pc
/usr/share/pkgconfig/shared-mime-info.pc
/usr/share/pkgconfig/udev.pc
/usr/share/pkgconfig/usbutils.pc
root@qnap:/var/www/pdf/poppler-0.18.3/# PKG_CONFIG_PATH=/usr/lib/pkgconfig
root@qnap:/var/www/pdf/poppler-0.18.3/# export PKG_CONFIG_PATH

Sedan var det här med fontconfig.

root@qnap:/var/www/pdf/poppler-0.18.3/#apt-get install apt-file
root@qnap:/var/www/pdf/poppler-0.18.3/#apt-file update
...
root@qnap:/var/www/pdf/poppler-0.18.3/#apt-file search fontconfig
...
libfontconfig1-dev: /usr/include/fontconfig/fontconfig.h
libfontconfig1-dev: /usr/lib/libfontconfig.a
libfontconfig1-dev: /usr/lib/libfontconfig.so
libfontconfig1-dev: /usr/lib/pkgconfig/fontconfig.pc

Med apt-file search [lib] så kan man se vilket paket som den ingår i. http://en.wikipedia.org/wiki/Apt-file

root@qnap:/var/www/pdf/poppler-0.18.3/#apt-get install libfontconfig1-dev
..
root@qnap:/var/www/pdf/poppler-0.18.3/./configure
root@qnap:/var/www/pdf/poppler-0.18.3/./make

Ingen pdftohtml hittades i /utils

Letade vidare … http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644447 https://github.com/davvil/Pdf-Presenter-Console

Verkar bara vara version 0.16 som skulle funka med Debian

Gjorde samma procedure med 0.16.7 som resulterade i pdftohtml version 0.16.7. Hm poppler verkar ge pdftohtml samma version som deras stora paket har.

Verifieras också då pdftohtml 0.39 uppdaterades senast 2006-08-03 medans poppler-utils 0.16.7 modifierades senast 2011-05-27. Så här blir det att pröva vilken som funkar bäst. Poppler-utils 0.12.4-1.2 http://packages.debian.org/sv/squeeze/poppler-utils gav roterade bilder ifrån pdf filen även fast den har ändringsdatum 2007-02-10.

Alltså får prova mig fram med pdftohtml 0.39 ifrån http://sourceforge.net/projects/pdftohtml/files/pdftohtml/ eller pdftohtml ifrån poppler-utils 0.16.7.

För att kunna köra med option -c som står för komplex måste jag även installera ghostscript http://en.wikipedia.org/wiki/Ghostscript.

root@qnap:/var/www/pdf/#apt-get install gs

Så var det dags att ta tag i den andra biten nämligen html till wiki syntax.

Med hjälp av det nyupptäckta verktyget apt-file search … och vetskap att paketet skall heta något med wikikonveter ……

root@qnap:/var/www/htmltowiki# apt-file search wikiconverter
libhtml-wikiconverter-dokuwiki-perl: /usr/share/doc/libhtml-wikiconverter-dokuwiki-perl/README
libhtml-wikiconverter-dokuwiki-perl: /usr/share/doc/libhtml-wikiconverter-dokuwiki-perl/buildinfo.gz
libhtml-wikiconverter-dokuwiki-perl: /usr/share/doc/libhtml-wikiconverter-dokuwiki-perl/changelog.Debian.gz
libhtml-wikiconverter-dokuwiki-perl: /usr/share/doc/libhtml-wikiconverter-dokuwiki-perl/changelog.gz
libhtml-wikiconverter-dokuwiki-perl: /usr/share/doc/libhtml-wikiconverter-dokuwiki-perl/copyright
....

Jo det finns ett färdigt paket klart att installera → libhtml-wikiconverter-dokuwiki-perl.

Sökning på nätet gav http://packages.debian.org/sv/lenny/libhtml-wikiconverter-dokuwiki-perl .. version 0.53-1

Enligt http://cpansearch.perl.org/src/DIBERRI/ är senaste versionen 0.68.

Kollar i http://cpansearch.perl.org/src/DIBERRI/HTML-WikiConverter-0.68/Changes om det är mödan värt att köra en manuell installering.

Mycke bugg fix och utökning av funktionalitet gav det senare alternativet.

root@qnap:/var/www/htmltowiki# which perl
/usr/bin/perl

Jo perl verkar finnas installerat.

root@qnap:/var/www/htmltowiki# perl -MCPAN -e 'install HTML::WikiConverter::DokuWiki

Gav efter ett stunds tuggande och varningar …

Test Summary Report
-------------------
t/dokuwiki.t    (Wstat: 512 Tests: 0 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
Files=5, Tests=4,  1 wallclock secs ( 0.19 usr  0.02 sys +  0.69 cusr  0.05 csys =  0.95 CPU)
Result: FAIL
Failed 1/5 test programs. 0/4 subtests failed.
make: *** [test_dynamic] Fel 255
  DIBERRI/HTML-WikiConverter-DokuWiki-0.53.tar.gz
  make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
  reports DIBERRI/HTML-WikiConverter-DokuWiki-0.53.tar.gz
Warning (usually harmless): 'YAML' not installed, will not store persistent state
Running make install
  make test had returned bad status, won't install without force
Could not read '/root/.cpan/build/Params-Validate-1.00-eN4fuJ/META.yml'. Falling back to other methods to determine prerequisites
root@qnap:/var/www/htmltowiki#

Nu sjabblade jag till det då jag sökte om det fanns något htmltowiki

root@qnap:/var/www/htmltowiki# updatedb
root@qnap:/var/www/htmltowiki# locate htmltowiki
/var/www/htmltowiki
root@qnap:/var/www/htmltowiki# 

Och det gjorde det inte då programmet heter html2wiki. Vart i alla fall

root@qnap:/var/www/htmltowiki# apt-get install libhtml-wikiconverter-dokuwiki-perl

Sedan provade jag att köra remove. Hur som haver så åkte det in igen med apt-get install libhtml-wikiconverter-dokuwiki-perl.

Så ingen klarhet om version 0.68 går att installera på debian squeeze troligen inte så kör det färdiga paketet.

Mera om installation av wikiconveter http://www.stercus.com/omniwiki/index.php5?title=HTML2Wiki

Då skall vi sy ihop allt det här då. Tanken är att man skall kunna släppa en pdf i en mapp som sedan behandlas av pdftohtml → (htmlsidan spars i en mapp med samma namn som filen) → html2wiki →wiki syntaxen spar i rätt mapp/namespace under /data/pages samt att länkarna till bilderna ordnas till rätt mapp.

först skissa på strukturen

dokuwiki/data/media--pdf_import
           |               |
           |               |--pdf_file1
           |               |             
           |               |--pdf_file2
           |               |
           |               |--etc ..
           |
           |--pages--dokument--fil1.txt
                 |          |
                 |          |--fil2.txt
                 |          |
                 |          |--etc ... 
                 |
                 |--logg.txt

• pdf_import .. där släpps pdf filen/filerna
• pdf_file1 . biblotek som får namnet av den ”normaliserade” pdf filen. Den ”normaliserade” pdf filen kopieras dit samt pdftohtml data sparas här.
• dokument .. där kommer html2wiki datat sparas i samma namn som pdfilen +.txt
• logg.txt .. där är det tänkt att spara löpande logg text ifrån processen.

För att skriva bash script så kan det vara en fördel att använda sig av en debugger.→ http://bashdb.sourceforge.net/

Om man nu inte vill installera något så finns det också en inbyggd debugger i själva bash. → http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.html. Den inbyggda är enkel att använda. Bara skriva dit set -x där du vill se vad den gör (skriver ut standard output).

root@qnap:/var/www/pdf bash -x script.sh

set -x kan även sättas på när som helst i bash skriptet

# !bin/bash
 
name=test.txt
echo test
  set -x
  echo "${test%%.*}" I have removed the end .txt

Vilken är den bästa editorn? Om man kör ifrån windows (putty.exe) så är nano en bra kandidat. Fördelen med den gentemot mcedit är att man kan bara högerklicka i putty för att klistra in. Det som är markerat i nano är per automatik kopierat. Om man nu använder mc (midnight commander) kan man trycka ctrl+o för att växla ut i terminal läge för att testköra scriptet.

Eftersom dokuwiki inte stöder mellanslag och stora bokstäver så måste vi ”normalisera” http://www.dokuwiki.org/tips:romanize i skriptet kollar jag bara på stora bokstäver och mellanslag.

Efter MÅNGA timmars surfande och debugging kom jag fram till nedanstående.

pdf_import.sh

#!/bin/bash
# file pdfimport.sh 
# Convert pdf to wiki syntax
# Take pdf file and rominize it and make a dir based on pdf file name.
# Execute pdftohtml and html2wiki on the pdf file
# Fix image url to dokuwiki syntax
# Replace the \\ with linefeed
#####################################
 
# LOGGFILE full path and file name ex. /var/www/dokuwiki/data/pages/config/logg.txt 
# Remember dir must end with /
 
LOGGFILE=/var/www/dokuwiki/data/pages/logg.txt
 
 
IMPORT_ROOT=/var/www/dokuwiki/data/media/pdf_import/
PAGES_DIR=/var/www/dokuwiki/data/pages/pdf_imported/
DOKUWIKI_MEDIA_ROOT=/var/www/dokuwiki/data/media/
 
#                           pdftohtml -c  "for complex"
PDFTOHTML="/var/www/pdftohtml -c -noframes -enc UTF-8"
HTML2WIKI="html2wiki --dialect DokuWiki"
 
 
# Set to true for configcheck (dir exists and script pdftohtml and html2wiki could be executed
RUN_CFG_CHK=true
 
clear
 
#set -x
 
cfgchk () {
# checking if I can write to $LOGGFILE, $IMPORT_DIR and $PAGES_DIR ..
if [ ! -w $LOGGFILE ]; then echo "<H1>Can´t write to loggfile"; exit 1; fi
if [ ! -w $IMPORT_ROOT ]; then echo "<H1>Can´t write to $IMPORT_ROOT  EXIT.."; exit 1; fi
if [ ! -w $PAGES_DIR ]; then echo "<H1>Can´t write to $PAGES_DIR  EXIT... "; exit 1; fi
 
#if [ $IMPORT_ROOT != $DOKUWIKI_MEDIA_ROOT ]; then  echo "<H1> I can´t find $DOKUWIKI_MEDIA_ROOT inside $IMPORT_ROOT  EXIT.. "; exit 1; fi
 
# cheking if pdftohtml and html2wiki could be executed ...
command -v $PDFTOHTML >/dev/null || { echo "<H1>Can´t execute $PDFTOHTML  EXIT.."; exit 1;}
command -v $HTML2WIKI >/dev/null || { echo "<H1>Can´t execute $HTML2WIKI  EXIT.."; exit 1;} 
echo 'You could turn the cfgchk off now e.g RUN_CFG_CHK=false' >> "$LOGGFILE"
}
 
# Mark the row bellow after you have check i all is okey
 
if $RUN_CFG_CHK ; then cfgchk; fi
 
    # loggfile  'basename $0 will give the running scripts name
    # writing to logg the script name and date and time
echo "==== Script \"`basename $0`\" is started ... $(date -u) ====" >> "$LOGGFILE"
 
    # Main loop
find $IMPORT_ROOT -maxdepth 1 -iname '*.pdf' | while read file;
  do
    # instead of string chopping you could use basename and filename
    oldfilename=$(basename "$file") 
    # write to logg what we have found (only .pdf files )
    echo "== Found file ...     \"${file##*/}\" ... ==" >> "$LOGGFILE"
    # Rominazie the file
    newfilename=$(echo "$oldfilename" | tr 'A-Z' 'a-z' | tr ' ' '_' |
    		    tr 'Å' 'å' | tr 'Ä' 'ä' | tr 'Ö' 'ö' | 
   				    sed 's/_-_/-/g');
 
   if [ "$newfilename" != "$oldfilename" ]; then
	    # Write to logg the new name
            # echo -n "text" >> file.txt  (will write "text" in the beginning of file.txt with no line feed)
            # the code bellow  will write to the end of the file with no line feed your sed implementation must support -i option
            # sed -i.bck '$s/$/After rominize......   '"$newfilename"'/ ' "$LOGGFILE"
        echo "== After rominize  .... $newfilename" >> "$LOGGFILE"
    fi
    	    # make dir based on newfilename 
	newdir="$IMPORT_ROOT""${newfilename%%.*}"   
            # create new dir
        mkdir -p "$newdir"
        echo "== Have created a new dir .. $newdir ==" >> "$LOGGFILE"
	    # copy the file no new dir with new name (new if rominized)
	cp "$IMPORT_ROOT$oldfilename" "$newdir/$newfilename"
	echo "== Copy $IMPORT_ROOT$newfilename" to "$newdir/$newfilename ==" >> "$LOGGFILE"
	    # remove old file
        rm "$IMPORT_ROOT/$oldfilename"
	echo "== Removed $IMPORT_ROOT$oldfilename ==" >> "$LOGGFILE"
 
    # convert from pdf to html  using the -c option (complex)
    # mark that -enc is not shown in the help for pdftohtml it is in xftp
    # Exec pdftohtml and write it to $LOGGFILE
    $PDFTOHTML $newdir/$newfilename $newdir/${newfilename%%.*}.html >> "$LOGGFILE"
 
 
 
    # Convert html to wiki syntax and fix the right path for pictures
    # first create a dummy url so we can find and replace that with correct path to pictures in wiki syntax 
    dummy=/dummy/
    # Convert to wiki syntax in the same dir as rominized pdf file
    echo "$HTML2WIKI --base-uri /dummy/ $newdir/${newfilename%%.*}.html $newdir/${newfilename%%.*}.txt" >> "$LOGGFILE" 
    $HTML2WIKI --base-uri /dummy/ $newdir/${newfilename%%.*}.html > $newdir/${newfilename%%.*}.txt
 
    # We take $IMPORT_ROOT and chop off $DOKUWIKI_MEDIA_ROOT and add $newdir with the $IMPORT_ROOT chopped off
    mediapath="${IMPORT_ROOT##"$DOKUWIKI_MEDIA_ROOT"}${newdir##"$IMPORT_ROOT"}"/
    # Repacing all the / with wiki's :
    mediapath=":$(echo "$mediapath" | tr '/' ':')"
echo "$mediapath"
    # Replacing the dummy string "/dummy/" with the correct wiki syntax path -> $mediapath in the .txt file
    # sed -i (-i in place= "on the spot")
 
    sed -i "s/\/dummy\//$mediapath/g" "$newdir/${newfilename%%.*}".txt
    # Replace \\ with line feed
    sed -i "s/\\\/\n/g" "$newdir/${newfilename%%.*}".txt
    cp "$newdir/${newfilename%%.*}".txt "$PAGES_DIR/${newfilename%%.*}".txt
done

När jag var klar så började jag fundera över hur jag skulle kunna starta scriptet utan att använda bash shell. Började då att titta på php.

Efter att provat lite med php så insåg jag snart att det behövs mera hjälp medel för att ”debugga” än bara webläsaren. Kollade först Komodo Edit som i sig själv inte är en debugger men har ”highlightning” och kodförslag. Men det räckte inte.

Efter att ha läst igenom den här sidanhttp://devzone.zend.com/1120/introducing-xdebug/. Så vart jag övertygad att xdebug och eclipse är vägen att gå. Fördelen är att xdebug kan köras på remote server och eclipse är plattforms oberoende.

Så med apt-file search xdebug fick jag fram att det fanns ett färdigt paket → php5-xdebug.

root@qnap:/var/www# apt-get install php5-xdebug

Sedan var det att editera php.ini (/ect/php5/apache2) och lägga till

zend_extension=/usr/lib/php5/20090626+lfs/xdebug.so

[debug]
; Remote settings
xdebug.remote_autostart=off
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=localhost
xdebug.remote_port=9000 

För att kolla var din xdebug.so finns någon stans …

root@qnap:/var/www#updatedb         # updaterar din databas över alla filer
root@qnap:/var/www#locate xdebug.so

Sedan var det eclipse PDT → http://www.eclipse.org/pdt/downloads/ Under tiden som den stora filen laddades ner.. kollade jag runt lite och fann Netbeans. http://netbeans.org/kb/docs/php/debugging.html Eftersom jag sitter på windows klient så tog jag ner den också.

Netbeans var bara på 47 mb och eclipse var på ett par hundra mb. Det vart netbeans.

Så för att köra remote debugg på netbeans så behövs det ftp.

root@qnap:/etc/proftpd#apt-get install proftpd
...
root@qnap:/etc/proftpd#../init.d/proftpd start
Stopping ftp server: proftpd.
Starting ftp server: proftpd - warning: unable to determine IP address of 'qnap'
 - error: no valid servers configured
 - Fatal: error processing configuration file '/etc/proftpd/proftpd.conf'

Aaahh … in och fixa proftpd.conf. Testa igen .. samma fel. Någonting med host. In i host filen och la till ip adressen och host namnet.

127.0.0.1       localhost
127.0.1.1       qnap219pII.example.org  qnap219pII
192.168.1.12    qnap

Efter att satt in rätt i Netbeans kom det som jag redan viste att filen måste laddas upp till /var/www/[något biblotek] Provade med symlink ln -s men ingen framgång. Så det vart att skapa en ny användare www-ftp

root@qnap:/etc#adduser www-ftp

Sedan så bytte jag dess hembiblotek till /var/www/www-ftp i passwd filen

root@qnap:/etc#nano passwd
......
proftpd:x:106:65534::/var/run/proftpd:/bin/false
www-ftp:x:1002:1003:,,,:/var/www/www-ftp:/bin/bash
......
root@qnap:/etc#mkdir /var/www/www-ftp
root@qnap:/etc#chown www-ftp:www-ftp /var/www/www-ftp

Nu när allt verkar funka så uppkom det problem med att debugg hela tiden öppnar en ny flik i firefox. Kom runt det med ett plugin → https://addons.mozilla.org/sv-se/firefox/addon/tab-mix-plus/

Så nu hade jag en fungerande utvecklings miljö. Började arbetet att försöka porta så mycket som möjligt till php för att få feedback på att saker och ting fungerade. Efter att fått romanizeringen och fil kopiering att fungera stöp det ändå på pdftohtml som inte ville spotta ut något på skärmen.

Efter 3 dagars letande så var det att man skulle lägga till växlen 2>1& för att sammanfoga STDERR till STDOUT som php kan fånga upp. I samma veva funderade jag över hur man skulle kunna förhindra att användaren släcker ner webläsaren. Provade lite med att köra första bash scriptet i bakgrunden med nohup.

Efter diverse tester så kom jag även på att kolla lite närmare på den färdiga txt filen. Såg då till min fasa att det inte skulle gå att använda. Html2wiki ger en txt fil som ser för jä.. ut.

Efter letande på nätet hittade jag ett php bilotek för att parsa html

http://simplehtmldom.sourceforge.net/

tutorial om hur man använder det.. http://net.tutsplus.com/tutorials/php/html-parsing-and-screen-scraping-with-the-simple-html-dom-library/.

Hittade även att skaparen av Dokuwiki Andreas Gohr har varit och tittat på html parsern.

http://www.freelists.org/post/dokuwiki/dokuwiki2html

Själv har jag inte kunskap och tid (har redan bränt 2 månader) att skriva det själv. Undrar om det finns redan eller någon vänlig själ vill ta vid där jag gav upp.

En annan sak som bör nämnas är att bilderna som pdftohtml plockar ut ur pdf filen håller mycket dålig kvalitet. Möjligt att det finns något knep för att få bättre kvalitet.

Startade en tråd för att se om någon kan komma upp med en lösning. http://forum.dokuwiki.org/thread/8071

Gör gärna ett inlägg nedan om det är något av min ”blog” som varit mat nyttigt. Skulle vara uppmuntrande med lite feedback efter nederlaget.