---

Hejsa!
Jeg har følgende kode som læser i en mappe efter de aktuelle
billeder:

:::SNIP:::
<?php
$billeder = Array();

if ($handle = @opendir('_pic/_galleri/_mig')) {
while (false !== ($file = readdir($handle))) {
if ($file != "." && $file != "..") {
$billeder[] = $file;
}
}
closedir($handle);
:::/SNIP:::

Jeg vil dog gerne have det sådan, at den KUN finder .gif
billederne og altså ikke tager evt. skjulte filer og lignende
med.

Hvor skal den ekstra lille kode tilføjes?

Håber hjælpen findes.

vh. Rask

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ronni Andersen wrote:
> Hejsa!
> Jeg har følgende kode som læser i en mappe efter de aktuelle
> billeder:
>
> :::SNIP:::
> <?php
> $billeder = Array();
>
> if ($handle = @opendir('_pic/_galleri/_mig')) {
> while (false !== ($file = readdir($handle))) {
> if ($file != "." && $file != "..") {
> $billeder[] = $file;
> }
> }
> closedir($handle);
> :::/SNIP:::
>
> Jeg vil dog gerne have det sådan, at den KUN finder .gif
> billederne og altså ikke tager evt. skjulte filer og lignende
> med.
>
> Hvor skal den ekstra lille kode tilføjes?
>
> Håber hjælpen findes.
>
> vh. Rask
>

du kan checke på "efternavnet" .gif så du skal have

&& substr($file, strrpos($file, "."), strlen($file)) == "gif"

med i din if

ellers kan du også bruge
http://dk2.php.net/manual/en/function.getimagesize.php den er mere
"sikker" da den checker filtypen rigtigt ikke kun om "efternavnet" er
..gif, men den er også noget langsommere, tror den første methode er "bedst".

--
Henrik Hansen

---

On Wed, 21 Jul 2004 12:21:37 +0200, Henrik Hansen wrote:

> du kan checke på "efternavnet" .gif så du skal have
>
> && substr($file, strrpos($file, "."), strlen($file)) == "gif"
>
> med i din if
>
Finder dog ikke billed.GIF.
--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Debian Hint #4: You can see the available and installed versions for one
or more available packages with the command 'apt-cache policy <packages>'.

---

Michael Rasmussen wrote:
> On Wed, 21 Jul 2004 12:21:37 +0200, Henrik Hansen wrote:
>
>
>>du kan checke på "efternavnet" .gif så du skal have
>>
>>&& substr($file, strrpos($file, "."), strlen($file)) == "gif"
>>
>>med i din if
>>
>
> Finder dog ikke billed.GIF.

nej så kan man lige sætte en strtolower omkring.

--
Henrik Hansen

---

Henrik Hansen wrote:

> Michael Rasmussen wrote:
>
>> On Wed, 21 Jul 2004 12:21:37 +0200, Henrik Hansen wrote:
>>
>>
>>> du kan checke på "efternavnet" .gif så du skal have
>>>
>>> && substr($file, strrpos($file, "."), strlen($file)) == "gif"
>>>
>>> med i din if
>>>
>>
>> Finder dog ikke billed.GIF.
>
>
> nej så kan man lige sætte en strtolower omkring.
>

Eller evt. bruge funktionen strcasecmp
(og så skal der vist lige en '+1' til substr index, eller evt. et '.'
før 'gif')

(strcasecmp( substr($file, (strrpos($file,'.')+1)), 'gif')==0 )

Se: http://dk2.php.net/strcasecmp

MVH Per Thomsen,
http://www.pert.dk/

---

On Wed, 21 Jul 2004 09:40:01 +0000, Ronni Andersen wrote:

>
> Jeg vil dog gerne have det sådan, at den KUN finder .gif billederne og
> altså ikke tager evt. skjulte filer og lignende med.
>
> Hvor skal den ekstra lille kode tilføjes?
>
Måske nedenstående løsning:

:::SNIP:::
<?php
$billeder = Array();

if ($handle = @opendir('_pic/_galleri/_mig')) {
while (false !== ($file = readdir($handle))) {
if ($file != "." && $file != ".." &&
preg_match("/\b.gif\b$/i", $file)) {
$billeder[] = $file;
}
}
closedir($handle);
:::/SNIP:::

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plaugher)

---

Davs

Jeg skrev lige følgende lille funktion her den anden dag:

function ls($dir = '.', $filter = '')
{
$files = array();
if ( ($d = opendir($dir)) !== false )
{
while ( ($file = readdir($d)) !== false )
{
// Skip . and ..
if ( in_array($file, array('.', '..')) ) continue;
// Apply filter
if ( $filter && !preg_match($filter, "$dir/$file") ) continue;
if ( is_dir("$dir/$file") )
{
$files = array_merge($files, ls("$dir/$file"));
}
else
{
$files[] = "$dir/$file";
}
}
}
sort($files);
return $files;
}

Input til funktionen er et dir og et regulært udtryk som filnavnene skal
matche - begge valgfrie.

Så man kunne f.eks. kalde

ls('./images', '_\.gif$_U');

Det skulle gerne finde alle filer med efternavnet ".gif" (uanset om det er
skrevet med store eller små bogstaver) i underbiblioteket "images".

Bemærk! Funktionen kalder sig selv rekursivt, hvis der er
underbiblioteker.

--
Mvh.
/Thomas

---

Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> writes:

> Jeg skrev lige følgende lille funktion her den anden dag:

Hvorfor ikke bare bruge glob()?

[snip kode]

> Så man kunne f.eks. kalde
>
> ls('./images', '_\.gif$_U');
>
> Det skulle gerne finde alle filer med efternavnet ".gif" (uanset om det er
> skrevet med store eller små bogstaver) i underbiblioteket "images".

Så skal du have modifieren 'i' med i dit filter.

> Bemærk! Funktionen kalder sig selv rekursivt, hvis der er
> underbiblioteker.

Men så vidt jeg kan se benytter den ikke filteret når den læser
underbibliotekerne. Desuden bliver biblioteket kun scannet i det
tilfælde biblioteksnavnet matcher filteret.

--
Med venlig hilsen
- Jacob Atzen

---

On Fri, 23 Jul 2004 09:33:26 +0200, Jacob Atzen wrote:

>> Jeg skrev lige følgende lille funktion her den anden dag:
>
> Hvorfor ikke bare bruge glob()?

Hmm... den kendte jeg ikke - men jeg har heller ikke brugt den i version
2 herunder, da det ser ud til at den kigger på store og små bogstaver.

>> Så man kunne f.eks. kalde
>>
>> ls('./images', '_\.gif$_U');
>>
>> Det skulle gerne finde alle filer med efternavnet ".gif" (uanset om det
>> er skrevet med store eller små bogstaver) i underbiblioteket "images".
>
> Så skal du have modifieren 'i' med i dit filter.

Det har du naturligvis ret i - det kunne være at man lige skulle køre en
test næste gang :)

>> Bemærk! Funktionen kalder sig selv rekursivt, hvis der er
>> underbiblioteker.
>
> Men så vidt jeg kan se benytter den ikke filteret når den læser
> underbibliotekerne. Desuden bliver biblioteket kun scannet i det
> tilfælde biblioteksnavnet matcher filteret.

Og det har du igen ret i (irriterende så mange fejl der kan være på så
få linier!).

Her er version 2 som gerne skulle rette de fundne fejl - den tilføjer
desuden mulighed for at slå rekursionen fra:

function ls($dir = '.', $filter = '', $recursion = true)
{
$files = array();
if ( ($d = opendir($dir)) !== false )
{
while ( ($file = readdir($d)) !== false )
{
if ( in_array($file, array('.', '..')) ) continue; // Skip . and ..
if ( is_dir("$dir/$file") && $recursion)
{
$files = array_merge($files, ls("$dir/$file", $filter, $recursion));
}
else if ( !$filter || ( $filter && preg_match($filter, "$dir/$file") ) )
{
$files[] = "$dir/$file";
}
}
}
sort($files);
return $files;
}

Og så kaldet der kan finde giffer:

ls('images', '_\.gif_i', false); // uden rekursion
ls('images', '_\.gif_i'); // med rekursion

og et par mere:

ls(); // find alle filer - også i alle underbiblioteker
ls('.', '', 'false'); // find alle filer i aktive dir

Håber ikke at der er flere fejl :)

--
Mvh.
/Thomas

---

Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> writes:

> Her er version 2 som gerne skulle rette de fundne fejl - den
> tilføjer desuden mulighed for at slå rekursionen fra:

Jeg synes din kode er noget snørklet at gennemskue. Jeg har
refaktoreret en del på den og prøvet at lave lidt kode, der gør
noget tilsvarende på en mere læsevenlig måde. Antallet af linier er
steget en hel del, men jeg håber at læsbarheden kan retfærdiggøre det.

function acceptDir($dir) {
if($dir == '.' || $dir == '..') {
return false;
}
return true;
}

function processDir($file, $filter, $recursion) {
$files = array();
if(acceptDir($file) && $recursion) {
$files = ls($file, $filter, $recursion);
}
return $files;
}

function acceptFile($file, $filter) {
return preg_match($filter, $file);
}

function processFile($file, $filter) {
$files = array();
if (acceptFile($file, $filter)) {
$files[] = $file;
}
return $files;
}

function process($file, $filter, $recursion) {
$appendum = array();
if(is_dir($file)) {
$appendum = processDir($file, $filter, $recursion);
} else {
$appendum = processFile($file, $filter);
}
return $appendum;
}

function dirEmpty($dir) {
return (glob($dir.'/*') == false ? true : false );
}

function ls($dir = '.', $filter, $recursion = true)
{
$files = array();
if(!dirEmpty($dir)) {
foreach(glob($dir.'/*') as $file) {
$files = array_merge($files, process($file, $filter, $recursion));
}
sort($files);
}
return $files;
}

--
Med venlig hilsen
- Jacob Atzen

---

On Fri, 23 Jul 2004 11:58:15 +0200, Jacob Atzen wrote:

> Jeg synes din kode er noget snørklet at gennemskue. Jeg har
> refaktoreret en del på den og prøvet at lave lidt kode, der gør
> noget tilsvarende på en mere læsevenlig måde. Antallet af linier er
> steget en hel del, men jeg håber at læsbarheden kan retfærdiggøre det.

Det må bero på en smagssag :)

Men vi kan da lave en lille krig om antallet af linier... glob() kan jo
bruges i stedet for opendir() og readdir(), så her kommer version 3:

function ls($dir = '.', $filter = '', $recursion = true)
{
$files = array();

foreach (glob("$dir/*") as $file)
{
if ( is_dir($file) && $recursion)
{
$files = array_merge($files, ls($file, $filter, $recursion));
}
else if ( !$filter || ( $filter && preg_match($filter, $file) ) )
{
$files[] = $file;
}
}
sort($files);
return $files;
}

--
Mvh.
/Thomas

---

Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> writes:

> Det må bero på en smagssag :)

Jep.

> Men vi kan da lave en lille krig om antallet af linier... glob() kan jo
> bruges i stedet for opendir() og readdir(), så her kommer version 3:

Jeg bryder mig ikke om at biblioteker bliver opfattet som filer, når
$recursion er false. For mig at se, er det skidt, at man i det ene
tilfælde kan få listet biblioteker og ikke i det andet tilfælde.

Desuden vil din indledende glob returnere false, hvis det aktuelle
bibliotek er tomt og du vil få warnings.

Min pointe med mit eksempel var, at du ved at dele funktionen op i
mindre funktioner meget nemmere kan overskue, hvad de enkelte
funktioner gør.

--
Med venlig hilsen
- Jacob Atzen

---

On Fri, 23 Jul 2004 23:12:39 +0200, Jacob Atzen wrote:

>> Men vi kan da lave en lille krig om antallet af linier... glob() kan jo
>> bruges i stedet for opendir() og readdir(), så her kommer version 3:
>
> Jeg bryder mig ikke om at biblioteker bliver opfattet som filer, når
> $recursion er false. For mig at se, er det skidt, at man i det ene
> tilfælde kan få listet biblioteker og ikke i det andet tilfælde.

Det er nok igen en smagssag - i Linux er alt i bund og grund filer...

> Desuden vil din indledende glob returnere false, hvis det aktuelle
> bibliotek er tomt og du vil få warnings.

Jeg må igen krybe til korset og tilstå at funktionen ikke er blevet
voldtestet :) - den er skrevet med et snævert mål for øje, hvor jeg
kontrollerer alle ydre omstændigheder.

> Min pointe med mit eksempel var, at du ved at dele funktionen op i
> mindre funktioner meget nemmere kan overskue, hvad de enkelte funktioner
> gør.

Umiddelbart har jeg ikke lettere ved at læse dit eksempel, men vi har jo
tydeligvis også forskellig kodestil :)

Man skal desuden holde sig for øje at koden kan blive _for_ pæn, idet
hvert funktionskald jo tager tid. Jeg arbejde for et par år siden med et
web-interface hvor jeg endte med at lave koden alt for slikket - alt blev
sat op med smarte funktioner som kaldte smarte funktioner, og
gennemgribende ændringer kunne laves ved at rette et enkelt sted. Men
performance-mæssigt var det noget gylle.

--
Mvh.
/Thomas

---

Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> writes:

> > Jeg bryder mig ikke om at biblioteker bliver opfattet som filer, når
> > $recursion er false. For mig at se, er det skidt, at man i det ene
> > tilfælde kan få listet biblioteker og ikke i det andet tilfælde.
>
> Det er nok igen en smagssag - i Linux er alt i bund og grund filer...

Ja, men det er det ikke i mit hovede

> > Min pointe med mit eksempel var, at du ved at dele funktionen op i
> > mindre funktioner meget nemmere kan overskue, hvad de enkelte funktioner
> > gør.
>
> Umiddelbart har jeg ikke lettere ved at læse dit eksempel, men vi har jo
> tydeligvis også forskellig kodestil :)

Har du heller ikke lettere ved at læse de enkelte funktioner?

> Man skal desuden holde sig for øje at koden kan blive _for_ pæn, idet
> hvert funktionskald jo tager tid. Jeg arbejde for et par år siden med et
> web-interface hvor jeg endte med at lave koden alt for slikket - alt blev
> sat op med smarte funktioner som kaldte smarte funktioner, og
> gennemgribende ændringer kunne laves ved at rette et enkelt sted. Men
> performance-mæssigt var det noget gylle.

Premature optimization is the root of all evil
- Donald Knuth

--
Med venlig hilsen
- Jacob Atzen

---

On Sun, 25 Jul 2004 11:57:17 +0200, Jacob Atzen wrote:

> Har du heller ikke lettere ved at læse de enkelte funktioner?

Hmm... jeg tror at jeg vil sige det på denne måde: Jeg kan sagtens læse
din kode og forstå hvad den gør - men det er ikke lettere for mig at
overskue den end min egen.

>> Man skal desuden holde sig for øje at koden kan blive _for_ pæn, idet
>> hvert funktionskald jo tager tid. Jeg arbejde for et par år siden med et
>> web-interface hvor jeg endte med at lave koden alt for slikket - alt blev
>> sat op med smarte funktioner som kaldte smarte funktioner, og
>> gennemgribende ændringer kunne laves ved at rette et enkelt sted. Men
>> performance-mæssigt var det noget gylle.
>
> Premature optimization is the root of all evil
> - Donald Knuth

Her mangler jeg så et godt mod-citat :) - men en hurtig søgning på dit
citat førte mig til

http://www.cookcomputing.com/blog/archives/000084.html

og herfra vil jeg da lige fremhæve en linie (Hoare's Dictum er det samme
som Donald Knuth-citatet):

I've worked on systems where the architects adhered to "Hoare's Dictum".
All goes well until realistic large-scale testing is performed and it
becomes painfully obvious that the system is never going to scale
upwards. Unfortunately by then it can be very difficult to fix the
problem without a large amount of re-design and re-coding.

--
Mvh.
/Thomas

---

Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> writes:

> Hmm... jeg tror at jeg vil sige det på denne måde: Jeg kan sagtens
> læse din kode og forstå hvad den gør - men det er ikke lettere for
> mig at overskue den end min egen.

Ikke desto mindre, var der flere fejl i din oprindelige kode som
formentlig ville være undgået, hvis du havde abstraheret koden lidt
mere. Det vil jeg i alle fald tillade mig at påstå

> I've worked on systems where the architects adhered to "Hoare's
> Dictum". All goes well until realistic large-scale testing is
> performed and it becomes painfully obvious that the system is
> never going to scale upwards. Unfortunately by then it can be very
> difficult to fix the problem without a large amount of re-design
> and re-coding.

Jeg siger ikke, at man skal ignorere alle fornuftige ideer man har om,
hvordan man skriver effektive programmer til at starte med. Der er
bare alt for mange der fokuserer meget på implementationsdetaljer, der
ikke nødvendigvis giver den store performance ændring. Bare prøv at
læse lidt tilbage her i gruppen og se, hvor meget der bliver
diskuteret performance omkring mere eller mindre irrelevante ting.

Argumenter imod (premature) optimering:

- Det er ikke sikkert, at applikationen behøver optimeres. Langt de
fleste maskiner har i dag masser af overskydende CPU kraft. Hvorfor
bruge tid og energi, før man overhovedet har en ide om det er
nødvendigt.

- Det viser sig mange gange, at ubegrundet optimering har en meget
minimal indvirkning på applikationens performance, da det er næsten
umuligt, at gætte sig til, hvilke dele af koden, der er performance
kritiske. Med ubegrundet mener jeg, at man ikke har foretaget
målinger for at finde ud af, hvilke dele af koden der halter.

- Det er betydeligt nemmere, at optimere let læselig og
velstruktureret kode end det er at gøre optimeret kode let læselig
og velstruktureret.

- "Optimeret" kode har en tendens til at være noget forfærdeligt snask
at læse. Ulæsbar kode er betydeligt sværere at finde fejl og
foretage videreudvikling på.

Til slut et af mine yndlingscitater:

Rules of Optimization:
Rule no. 1: Don't do it.
Rule no. 2: Don't do it!
Rule no. 3 (for experts only): Don't do it yet.
(frit efter M.A. Jackson)

Der er flere guldkorn her:

<http://c2.com/cgi/wiki?PrematureOptimization>

--
Med venlig hilsen
- Jacob Atzen

---

On Sun, 25 Jul 2004 13:14:37 +0200, Jacob Atzen wrote:

> Ikke desto mindre, var der flere fejl i din oprindelige kode som
> formentlig ville være undgået, hvis du havde abstraheret koden lidt
> mere. Det vil jeg i alle fald tillade mig at påstå

Hehe - den er jo svær at finde modargumenter til :)

Det eneste jeg kan finde på er, at funktionen var skrevet med en bestemt
anvendelse for øje (hvilket den klarede uden problemer), og derefter
udvidet i forbindelse med mit første indlæg i denne tråd og derefter
videregivet i utestet stand. (Dårlig undskyldning - men jeg kan altså
ikke komme på en bedre...)

> Jeg siger ikke, at man skal ignorere alle fornuftige ideer man har om,
> hvordan man skriver effektive programmer til at starte med. Der er bare
> alt for mange der fokuserer meget på implementationsdetaljer, der ikke
> nødvendigvis giver den store performance ændring.

Enig enig enig. Min løsning vil (så fremt der ikke er flere fejl) nok
være hurtigere end din, men forskellen vil slet ikke kunne mærkes i
daglig brug - med mindre man har et specielt behov for at finde filer
enormt mange gange.

[snip]

> - Det er betydeligt nemmere, at optimere let læselig og
> velstruktureret kode end det er at gøre optimeret kode let læselig
> og velstruktureret.
>
> - "Optimeret" kode har en tendens til at være noget forfærdeligt snask
> at læse. Ulæsbar kode er betydeligt sværere at finde fejl og
> foretage videreudvikling på.

Enig igen, dog med et forbehold for at man ikke skal lave koden "alt for
pæn" - du har f.eks. en funktion der hedder acceptFile som udelukkende er
en wrapper til preg_match, og den slags synes jeg at man bør undgå.
Det giver dels et ekstra funktionskald med deraf følgende
performance-forringelse, og dels opnår man i mine øjne en mere
læsevenlig kode ved simpelthen at bruge preg_match direkte og så i en
kommentar fortælle, hvad den linies kode gør godt for.

> Til slut et af mine yndlingscitater:
>
> Rules of Optimization:
> Rule no. 1: Don't do it.
> Rule no. 2: Don't do it!
> Rule no. 3 (for experts only): Don't do it yet. (frit efter M.A.
> Jackson)

Hehe.

--
Mvh.
/Thomas

---

Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> writes:

> On Sun, 25 Jul 2004 13:14:37 +0200, Jacob Atzen wrote:
>
> > Ikke desto mindre, var der flere fejl i din oprindelige kode som
> > formentlig ville være undgået, hvis du havde abstraheret koden lidt
> > mere. Det vil jeg i alle fald tillade mig at påstå
>
> Hehe - den er jo svær at finde modargumenter til :)
>
> Det eneste jeg kan finde på er, at funktionen var skrevet med en bestemt
> anvendelse for øje (hvilket den klarede uden problemer), og derefter
> udvidet i forbindelse med mit første indlæg i denne tråd og derefter
> videregivet i utestet stand. (Dårlig undskyldning - men jeg kan altså
> ikke komme på en bedre...)

Her illustrerer du så, mit argument:

> > - "Optimeret" kode har en tendens til at være noget forfærdeligt snask
> > at læse. Ulæsbar kode er betydeligt sværere at finde fejl og
> > foretage videreudvikling på.
>
> Enig igen, dog med et forbehold for at man ikke skal lave koden "alt for
> pæn" - du har f.eks. en funktion der hedder acceptFile som udelukkende er
> en wrapper til preg_match, og den slags synes jeg at man bør undgå.

Der er jeg så uenig. acceptFile() kommunikerer betydeligt klarerer end
preg_match(), hvad det er jeg gerne vil opnå. Jeg vil hellere have, at
koden forklarer sig selv, frem for at man skal skrive kommentarer ud
fra den simple regel, at koden _aldrig_ lyver.

--
Med venlig hilsen
- Jacob Atzen

---

Jacob Atzen wrote:

> Hvorfor ikke bare bruge glob()?

Fordi funktionaliteten af denne funktion afhænger kraftigt af hvilken
version af php du kører samt, hvilken platform du kører det på. Jeg har
selv opgivet at bruge den for nyligt - den er mildest talt ustabil.

Mvh Tommy

---

Tommy Ipsen <tipsen@imada.sdu.dk> writes:

> Jacob Atzen wrote:
>
> > Hvorfor ikke bare bruge glob()?
>
> Fordi funktionaliteten af denne funktion afhænger kraftigt af hvilken
> version af php du kører samt, hvilken platform du kører det på. Jeg
> har selv opgivet at bruge den for nyligt - den er mildest talt ustabil.

På hvilke platforme har du oplevet den som værende ustabil?

--
Med venlig hilsen
- Jacob Atzen

---

Ronni Andersen wrote:

eller bare :

if(preg_match("/[^.]+\.gif$/i",$file))

Mvh Christian


> Hejsa!
> Jeg har følgende kode som læser i en mappe efter de aktuelle
> billeder:
>
> :::SNIP:::
> <?php
> $billeder = Array();
>
> if ($handle = @opendir('_pic/_galleri/_mig')) {
> while (false !== ($file = readdir($handle))) {
> if ($file != "." && $file != "..") {
> $billeder[] = $file;
> }
> }
> closedir($handle);
> :::/SNIP:::
>
> Jeg vil dog gerne have det sådan, at den KUN finder .gif
> billederne og altså ikke tager evt. skjulte filer og lignende
> med.
>
> Hvor skal den ekstra lille kode tilføjes?
>
> Håber hjælpen findes.
>
> vh. Rask
>


--
----------------------------------------------------------------------
Christian Hansen tlf : 98486747
Vrangbækvej 6 e-mail : chrsen@fundanemt.com
9900 Frederikshavn web : http://www.fundanemt.com/
======================================================================
Politimanden : De kørte vist over for rødt hva?
Doppler : Så har jeg sørme kørt stærkt, for det syntes
grønt!

----------------------------------------------------------------------

---

Christian Hansen wrote:

og så glemte jeg lige en lille hat :

if(preg_match("/^[^.]+\.gif$/i",$file))

> Ronni Andersen wrote:
>
> eller bare :
>
> if(preg_match("/[^.]+\.gif$/i",$file))
>
> Mvh Christian
>

---

On Mon, 26 Jul 2004 08:39:23 +0200, Christian Hansen
<webmaster@telescopium.dk> wrote:

>og så glemte jeg lige en lille hat :
>
>if(preg_match("/^[^.]+\.gif$/i",$file))

Ingen "mit.billede.gif" ?

--
- Peter Brodersen

Ugens sprogtip: te (og ikke the)

---

Peter Brodersen wrote:
> On Mon, 26 Jul 2004 08:39:23 +0200, Christian Hansen
> <webmaster@telescopium.dk> wrote:
>
>
>>og så glemte jeg lige en lille hat :
>>
>>if(preg_match("/^[^.]+\.gif$/i",$file))
>
>
> Ingen "mit.billede.gif" ?

Næ ikke i det regexp - og hvor tit optræder også det i praksis?

Men man kan da sagtens lave det, så . er tilladt i strengen. Spørgsmålet
er blot om man skal definere en tegnklasse med tilladte tegn eller
tillade alle tegn herunder mellemrum,æ ,ø og å.

Mvh Christian

---

On Mon, 26 Jul 2004 19:16:36 +0200, Christian Hansen
<chrsen@fundanemt.com> wrote:

>Næ ikke i det regexp - og hvor tit optræder også det i praksis?

En hurtig søgning fortalte mig, at jeg har 162 .gif-billeder liggende
og 88 .jpg-billeder liggende, der har flere punktummer i filnavnet.
Flere af dem følger med diverse standardprodukter. Under alle
omstændigheder ville det være en pudsig restriktion.

>Men man kan da sagtens lave det, så . er tilladt i strengen. Spørgsmålet
>er blot om man skal definere en tegnklasse med tilladte tegn eller
>tillade alle tegn herunder mellemrum,æ ,ø og å.

Det afhænger vel af brugen. Hvis man vil finde alle filer, der slutter
på .gif, så bør alle vel inkluderes.

Hvis det handler om at referere til filerne med links eller
billede-indlejringer, så ka man jo altid fyre op under rawurlencode(),
hvis man er bekymret over mellemrum og lignende i filnavnet.

--
- Peter Brodersen

Ugens sprogtip: te (og ikke the)

---

Peter Brodersen wrote:
> On Mon, 26 Jul 2004 19:16:36 +0200, Christian Hansen
> <chrsen@fundanemt.com> wrote:
> En hurtig søgning fortalte mig, at jeg har 162 .gif-billeder liggende
> og 88 .jpg-billeder liggende, der har flere punktummer i filnavnet.
> Flere af dem følger med diverse standardprodukter. Under alle
> omstændigheder ville det være en pudsig restriktion.

Nu er det jo nok fordi jeg hovedsageligt arbejder med web og har kunder,
som gør det samme og det i windows. jeg kan ikke komme i tanke om et
eneste eksempel, hvor jeg har oplevet en kunde bruge et billedefilnavn
med flere punktummer. Jeg tror det er noget, som i vid udstrækning er
begrænset til *nix-verdenen.

>
> Det afhænger vel af brugen. Hvis man vil finde alle filer, der slutter
> på .gif, så bør alle vel inkluderes.

Det er klart og så er det jo blot /\.gif$/i i stedet.


> Hvis det handler om at referere til filerne med links eller
> billede-indlejringer, så ka man jo altid fyre op under rawurlencode(),
> hvis man er bekymret over mellemrum og lignende i filnavnet.

Jep, men efter min mening er det nu meget pænere at undgå specieltegn i
ting, der skal ses på nettet.

mvh Christian

---

On Mon, 26 Jul 2004 20:02:13 +0200, Christian Hansen
<chrsen@fundanemt.com> wrote:

>Jep, men efter min mening er det nu meget pænere at undgå specieltegn i
>ting, der skal ses på nettet.

Jeg er ikke uenig, men efterhånden er "selv" Mozilla begyndt at vise
pæne URLs i fx statuslinjen, hvis man kører musen over et
rawurlencoded link med %20 og lignende, og det samme gælder hvis man
gemmer filer fra de URLs.

Eneste er, at adressen stadigvæk står urlencoded i adresselinjen.

--
- Peter Brodersen

Ugens sprogtip: te (og ikke the)