On 12/3/14, waldo kitty wkitt...@windstream.net wrote:
On 12/3/2014 5:09 PM, Bart wrote:
Windows.FindFirstFile however treats ? as exactly 1 character AFAIK.
And is I'm not mistake this was also the case with TP in the old days.
Seems I was mistaken. Sorry for the confusion.
FF with mask
On 03 Dec 2014, at 06:05, waldo kitty wrote:
can you help me understand the differences in the output of the
below program?
given these three filenames: t.txt t1.txt t11.txt
with mask t?.txt why does MatchesMaskList not show t.txt and
t11.txt like plain findfirst?
? means a single
On Tue, 2 Dec 2014, waldo kitty wrote:
how do you process for multiple filemasks?
eg: find ts??.sel and t???.sel for the same processing run
I don't think FindFirst and FindNext has that capability. I would use the
AllMasks constant and then manually match using a simple regex that
On Wed, 3 Dec 2014, Michael Van Canneyt wrote:
They do.
Wow. We are never to old to learn. :-) I'll have to take a closer look at
that functionality.
Regards,
Graeme
This email and its attachments may be confidential and are intended solely for
the use of the individual to whom it is
On Wed, December 3, 2014 06:05, waldo kitty wrote:
On 12/2/2014 5:12 PM, Bart wrote:
On 12/2/14, waldo kitty wkitt...@windstream.net wrote:
how do you process for multiple filemasks?
eg: find ts??.sel and t???.sel for the same processing run
Maybe I misunderstand the question but:
Use
On 12/3/2014 3:41 AM, Jonas Maebe wrote:
On 03 Dec 2014, at 06:05, waldo kitty wrote:
can you help me understand the differences in the output of the below program?
given these three filenames: t.txt t1.txt t11.txt
with mask t?.txt why does MatchesMaskList not show t.txt and t11.txt like
On 12/3/2014 6:16 AM, Tomas Hajny wrote:
Given the fact that OS/2 appeared in your listing, I can clarify the
difference. It comes from the fact that in case of FindFirst/FindNext, the
interpretation of wildcards is performed by the underlying operating
system whereas the routine mentioned by
On 12/3/2014 8:30 AM, waldo kitty wrote:
On 12/3/2014 3:41 AM, Jonas Maebe wrote:
On 03 Dec 2014, at 06:05, waldo kitty wrote:
can you help me understand the differences in the output of the
below program?
given these three filenames: t.txt t1.txt t11.txt
with mask t?.txt why does
On 12/3/14, Ralf Quint freedos...@gmail.com wrote:
On any DOS based OS (that includes OS/2 and Windows), the ? wildcard
character will find any character, including no character at all in that
position. So in your example, t?.txt will find t.txt and tx.txt but not
txy.txt. It will not return
On 12/3/2014 12:27 PM, Bart wrote:
On 12/3/14, Ralf Quint freedos...@gmail.com wrote:
On any DOS based OS (that includes OS/2 and Windows), the ? wildcard
character will find any character, including no character at all in that
position. So in your example, t?.txt will find t.txt and tx.txt
On 12/3/14, Ralf Quint freedos...@gmail.com wrote:
On 12/3/2014 12:27 PM, Bart wrote:
Windows.FindFirstFile however treats ? as exactly 1 character AFAIK.
And is I'm not mistake this was also the case with TP in the old days.
A quick test in a Windows 8.1 command prompt:
I don't dispute
On 12/3/2014 3:02 PM, Ralf Quint wrote:
On 12/3/2014 8:30 AM, waldo kitty wrote:
yes, i wrote t11.txt when i should have written t1.txt... my bad...
however on
OS/2 native
OS/2 with 4OS2 command interpreter replacement
OS/2 DOS native
OS/2 DOS with 4DOS command interpreter replacement
On 12/3/2014 3:27 PM, Bart wrote:
On 12/3/14, Ralf Quint freedos...@gmail.com wrote:
On any DOS based OS (that includes OS/2 and Windows), the ? wildcard
character will find any character, including no character at all in that
position. So in your example, t?.txt will find t.txt and tx.txt but
On 12/3/2014 5:09 PM, Bart wrote:
On 12/3/14, Ralf Quint freedos...@gmail.com wrote:
On 12/3/2014 12:27 PM, Bart wrote:
Windows.FindFirstFile however treats ? as exactly 1 character AFAIK.
And is I'm not mistake this was also the case with TP in the old days.
A quick test in a Windows
On Wed, December 3, 2014 23:18, waldo kitty wrote:
.
.
desirable in some cases... i just have to test it on OS/2 and see if i can
compile it... i can't do that with MatchesMaskList because the unit that
contains it is not available on OS/2...
Which unit is it, btw? Have you tried compiling
On 12/3/2014 2:09 PM, Bart wrote:
I don't dispute teh way cmd/command treats ? in dir, I merely stated
that the OS function FindFirstFile des not do it like that. (And so we
should not change FindFirst/FidNext behaviour.)
Well, I have no way/time to do a more extensive test right now, but I am
On 12/3/2014 5:48 PM, Tomas Hajny wrote:
On Wed, December 3, 2014 23:18, waldo kitty wrote:
.
.
desirable in some cases... i just have to test it on OS/2 and see if i can
compile it... i can't do that with MatchesMaskList because the unit that
contains it is not available on OS/2...
Which
On 12/3/2014 8:10 PM, waldo kitty wrote:
MatchesMaskList and its friends are in the Lazarus MASKS unit... since lazarus
is not available for OS/2, i'm not looking for it to happen... then there's the
difference in the way it operates compared to what is expected...
not the way it operates...
On 03.12.2014 23:09, Bart wrote:
On 12/3/14, Ralf Quint freedos...@gmail.com wrote:
On 12/3/2014 12:27 PM, Bart wrote:
Windows.FindFirstFile however treats ? as exactly 1 character AFAIK.
And is I'm not mistake this was also the case with TP in the old days.
A quick test in a Windows
how do you process for multiple filemasks?
eg: find ts??.sel and t???.sel for the same processing run
== snip filemask.pas ==
Program Filemasks;
Uses
SysUtils, StrUtils, Classes;
var
dirSR : TSearchRec;
flist : TStringList;
fmask : string;
begin
if paramstr(1) ''
On 12/2/14, waldo kitty wkitt...@windstream.net wrote:
how do you process for multiple filemasks?
eg: find ts??.sel and t???.sel for the same processing run
Maybe I misunderstand the question but:
Use '*' as mask for FindFirst/FindNext then use MatchesMaskList()?
Bart
On 12/2/2014 5:12 PM, Bart wrote:
On 12/2/14, waldo kitty wkitt...@windstream.net wrote:
how do you process for multiple filemasks?
eg: find ts??.sel and t???.sel for the same processing run
Maybe I misunderstand the question but:
Use '*' as mask for FindFirst/FindNext then use
On 12/2/2014 5:12 PM, Bart wrote:
On 12/2/14, waldo kitty wkitt...@windstream.net wrote:
how do you process for multiple filemasks?
eg: find ts??.sel and t???.sel for the same processing run
Maybe I misunderstand the question but:
Use '*' as mask for FindFirst/FindNext then use
On 12/2/2014 5:12 PM, Bart wrote:
On 12/2/14, waldo kitty wkitt...@windstream.net wrote:
how do you process for multiple filemasks?
eg: find ts??.sel and t???.sel for the same processing run
Maybe I misunderstand the question but:
Use '*' as mask for FindFirst/FindNext then use
Hi,
Working with lazarus on Linux Mint I noticed that when I mount a windows
shared with Connect to server, everything works fine (Nautilus, Midnight
Commander, Lazarus file operations). But meeting that .gvfs folder is
hidden, I tried to mount mount -t cifs directly in the shell.
After such
On 03/01/2013 09:14 AM, Max Vlasov wrote:
Hi,
Working with lazarus on Linux Mint I noticed that when I mount a windows
shared with Connect to server, everything works fine (Nautilus,
Midnight Commander, Lazarus file operations). But meeting that .gvfs
folder is hidden, I tried to mount
On Fri, Mar 1, 2013 at 12:32 PM, Ludo Brands ludo.bra...@free.fr wrote:
On 03/01/2013 09:14 AM, Max Vlasov wrote:
The question is what is different in nautilus and midnight commander
comparing to fpc directoy-listing functions that allows them to list
directories correctly in the bug's
On 03/01/2013 10:55 AM, Max Vlasov wrote:
On Fri, Mar 1, 2013 at 12:32 PM, Ludo Brands ludo.bra...@free.fr
mailto:ludo.bra...@free.fr wrote:
On 03/01/2013 09:14 AM, Max Vlasov wrote:
The question is what is different in nautilus and midnight commander
comparing to fpc
In our previous episode, Ludo Brands said:
The question is what is different in nautilus and midnight commander
comparing to fpc directoy-listing functions that allows them to list
directories correctly in the bug's case?
The difference with other tools is that FPC gives a very
On 01.03.2013 12:31, Marco van de Voort wrote:
In our previous episode, Ludo Brands said:
The question is what is different in nautilus and midnight commander
comparing to fpc directoy-listing functions that allows them to list
directories correctly in the bug's case?
The difference with
On 03/01/2013 12:52 PM, Sven Barth wrote:
Currently FPC allocates only one pdirent in fpopendir
(rtl/linux/ossysc.inc). Maybe it should first stat the directory and
then decide based on st_blksize how much pdirent entries to allocate
(but it should also provide a sane default, as there is the
On Fri, 1 Mar 2013, Ludo Brands wrote:
On 03/01/2013 12:52 PM, Sven Barth wrote:
Currently FPC allocates only one pdirent in fpopendir
(rtl/linux/ossysc.inc). Maybe it should first stat the directory and
then decide based on st_blksize how much pdirent entries to allocate
(but it should
On 01.03.2013 16:08, Ludo Brands wrote:
On 03/01/2013 12:52 PM, Sven Barth wrote:
Currently FPC allocates only one pdirent in fpopendir
(rtl/linux/ossysc.inc). Maybe it should first stat the directory and
then decide based on st_blksize how much pdirent entries to allocate
(but it should also
On 03/01/2013 06:02 PM, Sven Barth wrote:
While the kernel might pass less than 256 characters the dirent
structure contains a dd_nextoff field which is already used in FPC's
fpreaddir call to locate the next returned entry.
Yes, I know. Otherwise we would lose more than one file name per
On 03/01/2013 04:37 PM, Michael Van Canneyt wrote:
On Fri, 1 Mar 2013, Ludo Brands wrote:
What about just using a 32k buffer?
No problem with that as far as I am concerned.
Since the code is shared between embedded and non-embedded targets, it
might be better to have the option to
In Windows XP and upper, traversing directories starting from root directory
(e.g. D:\) using FindFirst() and FindNext() will fail (ERROR_ACCESS_DENIED)
when iteration encounters System Volume Information directory. I solved this
by ignoring this error code and keep looping. However, I don't
Hi, I ported a Delphi service to linux using FPC. The app uses FindFirst,
FindNext and FindClose the same way Delphi Help shows:
if FindFirst(Edit1.Text, FileAttrs, sr) = 0 then
begin
repeat
...
...
until FindNext(sr) 0;
FindClose(sr);
end;
Apparently my program gets stuck after
On 18 May 2009, at 16:39, Leonardo M. Ramé wrote:
Apparently my program gets stuck after a couple (several, in fact)
of calls to the function that includes this code.
By reading the FPC.RTL documentation, I found it says that FindClose
must be used outside the if, as follows:
if
On Mon, 18 May 2009, Jonas Maebe wrote:
On 18 May 2009, at 16:39, Leonardo M. Ramé wrote:
Apparently my program gets stuck after a couple (several, in fact) of calls
to the function that includes this code.
By reading the FPC.RTL documentation, I found it says that FindClose must be
Canneyt mich...@freepascal.org wrote:
From: Michael Van Canneyt mich...@freepascal.org
Subject: Re: [fpc-pascal] FindFirst...FindClose
To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
Date: Monday, May 18, 2009, 12:25 PM
On Mon, 18 May 2009, Jonas Maebe wrote:
On 18
On 18 May 2009, at 17:25, Michael Van Canneyt wrote:
On Mon, 18 May 2009, Jonas Maebe wrote:
On 18 May 2009, at 16:39, Leonardo M. Ramé wrote:
By reading the FPC.RTL documentation, I found it says that
FindClose must be
used outside the if, as follows:
if FindFirst(Edit1.Text,
On Mon, 18 May 2009, Jonas Maebe wrote:
On 18 May 2009, at 17:25, Michael Van Canneyt wrote:
On Mon, 18 May 2009, Jonas Maebe wrote:
On 18 May 2009, at 16:39, Leonardo M. Ramé wrote:
By reading the FPC.RTL documentation, I found it says that FindClose must
be
used outside the if, as
I must agree with Michael.
In my experience, it doesn't matter where the findclose() is placed, as long
as it's called within the scope of the findfirst(), findnext(). If
findclose() is not called, all that happens is that the OS will use up file
handles, which are finite in quantity on any
Is that correct:
http://www.delphifaq.com/faq/delphi/windows_file_system/f419.shtml
?
If yes, then you need IFDEFs to distinguish between Linux and Windows. ;-(
Jürgen Hestermann
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
In our previous episode, Jonas Maebe said:
Yes.
Huh ? Since when is this requirement ?
Since as long as I can remember. It at least predates the switch to
svn (revision 1 of both rtl/unix/dos.pp and of rtl/unix/sysutils.pp
requires it).
The current situation is probably simply
On Mon, 18 May 2009, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
Yes.
Huh ? Since when is this requirement ?
Since as long as I can remember. It at least predates the switch to
svn (revision 1 of both rtl/unix/dos.pp and of rtl/unix/sysutils.pp
requires it).
On 18 May 2009, at 18:15, Michael Van Canneyt wrote:
As far as I know, the FindClose is only needed when FindFirst
returned zero.
That has never been true on FPC/unix, as far as I can see.
Jonas
___
fpc-pascal maillist -
This sounds good, just also check what happens if FindClose receives an invalid
handle.
Leonardo M. Ramé
http://leonardorame.blogspot.com
--- On Mon, 5/18/09, Michael Van Canneyt mich...@freepascal.org wrote:
From: Michael Van Canneyt mich...@freepascal.org
Subject: Re: [fpc-pascal
On Mon, 18 May 2009, Leonardo M. Ramé wrote:
This sounds good, just also check what happens if FindClose receives an
invalid handle.
That was the second line in my line count estimate ;-)
Michael.___
fpc-pascal maillist -
In our previous episode, Michael Van Canneyt said:
Opinions ? If no-one objects, I'll implement the 'fix', it's only
2 lines of code.
No fundamental objections, but maybe wait till just before a release to
avoid packages that work with both 2.2.4 and 2.3.1 having to ifdef till the next
release?
On Mon, 18 May 2009, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Opinions ? If no-one objects, I'll implement the 'fix', it's only
2 lines of code.
No fundamental objections, but maybe wait till just before a release to
avoid packages that work with
On 18 May 2009, at 21:03, Michael Van Canneyt wrote:
I checked the windows code, and FindClose explicitly checks that
the searchrec record contains a valid handle (i.e. NOT
INVALID_HANDLE_VALUE), so all platforms would behave the same.
Opinions ? If no-one objects, I'll implement the 'fix',
On 18 May 09, at 22:10, Jonas Maebe wrote:
On 18 May 2009, at 21:03, Michael Van Canneyt wrote:
I checked the windows code, and FindClose explicitly checks that
the searchrec record contains a valid handle (i.e. NOT
INVALID_HANDLE_VALUE), so all platforms would behave the same.
I thought the file attributes are ignored under linux, but apparently
they are not.
Is it normal, that FindNext returns a file twice?
uses
SysUtils;
var
Info: TSearchRec;
begin
if FindFirst('*',faDirectory,Info)=0 then
begin
repeat
writeln(Info.Name);
until FindNext(Info)0;
On Fri, May 1, 2009 at 11:55 AM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
I thought the file attributes are ignored under linux, but apparently
they are not.
Is it normal, that FindNext returns a file twice?
Would that explain why the TFileListBox component and Lazarus's File
Browser
On Fri, May 1, 2009 at 11:55 AM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
I thought the file attributes are ignored under linux, but apparently
they are not.
Is it normal, that FindNext returns a file twice?
And sometimes even more than twice as the following output shows
(using the
On Fri, 1 May 2009 17:13:39 +0200
Graeme Geldenhuys graemeg.li...@gmail.com wrote:
On Fri, May 1, 2009 at 11:55 AM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
I thought the file attributes are ignored under linux, but
apparently they are not.
Is it normal, that FindNext returns a
On Fri, May 1, 2009 at 5:24 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
Yes.
Ah. And using faAnyFile and then testing .Attr for faDirectory is one
way to overcome the problem.
It seems it is buggy under OS X too.
I guess, this must be added to the wiki pages about cross
platform
On 01 May 2009, at 11:55, Mattias Gaertner wrote:
I thought the file attributes are ignored under linux, but apparently
they are not.
They are currently ignored if you do not use wildcards, otherwise they
are used. I'm tested a fix to change that so that they are always used.
Is it
On Fri, 1 May 2009 17:43:48 +0200
Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 01 May 2009, at 11:55, Mattias Gaertner wrote:
I thought the file attributes are ignored under linux, but
apparently they are not.
They are currently ignored if you do not use wildcards, otherwise
they
On 01 May 2009, at 17:52, Mattias Gaertner wrote:
On Fri, 1 May 2009 17:43:48 +0200
Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 01 May 2009, at 11:55, Mattias Gaertner wrote:
I thought the file attributes are ignored under linux, but
apparently they are not.
They are currently
Hi,
I'm doing a FindFirst / FindNext and fitering out all faHidden and
faDirectory results.
I don't want to show and dot (.name) directories as they are
considered hidden under Linux.
Yet FindFirst / FindNext doesn't have the faHidden flag set for those
directories
Is there another function or
Op Tue, 12 Jun 2007, schreef Graeme Geldenhuys:
Hi,
I'm doing a FindFirst / FindNext and fitering out all faHidden and
faDirectory results.
I don't want to show and dot (.name) directories as they are
considered hidden under Linux.
Yet FindFirst / FindNext doesn't have the faHidden flag
Am Mittwoch, den 28.06.2006, 11:01 +0200 schrieb Tomas Hajny:
Which platform are you talking about, which FindFirst/FindNext
(Dos/SysUtils) and what is the behaviour expected from you? E.g. with:
Sorry, I was too deep into the problem.
I'm using FreeBSD as main platform for development but
Marc Santhoff wrote:
Am Mittwoch, den 28.06.2006, 11:01 +0200 schrieb Tomas Hajny:
Which platform are you talking about, which FindFirst/FindNext
(Dos/SysUtils) and what is the behaviour expected from you? E.g. with:
Sorry, I was too deep into the problem.
I'm using FreeBSD as main
Am Mittwoch, den 28.06.2006, 15:57 +0200 schrieb Marc Santhoff:
Am Mittwoch, den 28.06.2006, 11:01 +0200 schrieb Tomas Hajny:
Which platform are you talking about, which FindFirst/FindNext
(Dos/SysUtils) and what is the behaviour expected from you? E.g. with:
Sorry, I was too deep into
Am Mittwoch, den 28.06.2006, 18:13 +0200 schrieb Tomas Hajny:
Marc Santhoff wrote:
Am Mittwoch, den 28.06.2006, 11:01 +0200 schrieb Tomas Hajny:
Which platform are you talking about, which FindFirst/FindNext
(Dos/SysUtils) and what is the behaviour expected from you? E.g. with:
Sorry,
Okay,
now I tried it but got no valuable result:
$ ls -lF /usr/X11R6/include/ | grep /
...
drwx-- 104 root wheel8192 6 Okt 2005 nvu-1.0/
...
$ ls -lF /usr/X11R6/ | grep include/
drwxr-xr-x 76 root wheel 10240 14 Mai 00:07 include/
I am allowed to read the last one, but not the
Hi,
trying to use FindFirst and FindNext on files I cannot detect the
difference between a failed call because of no matching file and a
failure when the file or dir is not listable by the user lacking
permissions.
If I'd use fpstat and friends myself this would mean doing anything
doubly and
Hi
How do I know if a file returned by findfirst is a real file or a symbolic link ?
Thanks
--
_
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.
Powered by Outblaze
At 19:05 2-3-2004, you wrote:
Hi
How do I know if a file returned by findfirst is a real file or a symbolic
link ?
Use stat() (fpStat() in 1.9.x). There is a patch supplied to add a Mode
field to TSearchRec, but that is not applied yet.
Peter
___
Thanks... !
That patch can be applied to the fpc 1.0.4 source ?
There is any other workaround to the problem ?
At 19:05 2-3-2004, you wrote:
Hi
How do I know if a file returned by findfirst is a real file or a symbolic
link ?
Use stat() (fpStat() in 1.9.x). There is a patch supplied to
Thanks... !
That patch can be applied to the fpc 1.0.4 source ?
There is any other workaround to the problem ?
I don't think it, the Unix RTL is different. But ofcourse you can do patch
it manual. See the fpc-devel mailinglist archives for the patch.
73 matches
Mail list logo
