Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2008-08

Locale solution for Linux (and maybe *nix)

27 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

In FPC the locale information is all hard-coded for Linux and other Unix based systems. We don't all live in the USA. ;-) This is very annoying. I also know we may not use glibc calls in FPC to get the locale information, because glibc is not always available on systems other than Linux.

Today I found the following on my Linux system which could possibly solve this issues. Could other Linux distros and Unix users (*BSD, etc) confirm if they also have the following directory?

Under Ubuntu 7.10 I have the follow directory: /usr/share/i18n/locales/

Inside that directory are files like en_GB, en_US, es_ES, de_DE etc.... They are plain text files that should be fairly easy to parse and extract the locale information. Couldn't we use that to populate the locale information inside FPC, without the need of glibc?

For example, here are some of the content of the en_ZA (English South Africa) file:

-------------[ en_ZA ]--------------------
<....snip....>
LC_MONETARY
% ISO 4217 Currency and fund codes
% http://www.bsi-global.com/Technical+Information/Publications/_Publications/tig90.xalter % "ZAR "
int_curr_symbol "<U005A><U0041><U0052><U0020>"

% "R"
currency_symbol "<U0052>"

% "."
mon_decimal_point "<U002E>"

% ","
mon_thousands_sep "<U002C>"
mon_grouping 3;3
positive_sign ""

% "-"
negative_sign "<U002D>"
int_frac_digits 2
frac_digits 2
p_cs_precedes 1
p_sep_by_space 0
n_cs_precedes 1
n_sep_by_space 0
p_sign_posn 1
n_sign_posn 1
END LC_MONETARY

LC_NUMERIC
% "."
decimal_point "<U002E>"

% ","
thousands_sep "<U002C>"
grouping 3;3
END LC_NUMERIC

LC_TIME
% abday - The abbreviations for the week days:
% - Sun, Mon, Tue, Wed, Thu, Fri, Sat
abday "<U0053><U0075><U006E>";"<U004D><U006F><U006E>";/ "<U0054><U0075><U0065>";"<U0057><U0065><U0064>";/
"<U0054><U0068><U0075>";"<U0046><U0072><U0069>";/
"<U0053><U0061><U0074>"
<...snip...>
% Date representation to be referenced by the "%x" field descriptor - % "%d/%m/%Y", day/month/year as decimal numbers (01/01/2000). d_fmt "<U0025><U0064><U002F><U0025><U006D><U002F><U0025><U0059>" <...snip...>
first_weekday 1
END LC_TIME

LC_PAPER
<...snip...>
END LC_PAPER

LC_TELEPHONE
<...snip...>
END LC_TELEPHONE
----------------[ end ]---------------------

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Unknown author
to Graeme Geldenhuys
Graeme Geldenhuys wrote 86 lines
Hi, In FPC the locale information is all hard-coded for Linux and other Unix based systems. We don't all live in the USA. ;-) This is very annoying. I also know we may not use glibc calls in FPC to get the locale information, because glibc is not always available on systems other than Linux. Today I found the following on my Linux system which could possibly solve this issues. Could other Linux distros and Unix users (*BSD, etc) confirm if they also have the following directory? Under Ubuntu 7.10 I have the follow directory: /usr/share/i18n/locales/ Inside that directory are files like en_GB, en_US, es_ES, de_DE etc.... They are plain text files that should be fairly easy to parse and extract the locale information. Couldn't we use that to populate the locale information inside FPC, without the need of glibc? For example, here are some of the content of the en_ZA (English South Africa) file: -------------[ en_ZA ]-------------------- <....snip....> LC_MONETARY % ISO 4217 Currency and fund codes % http://www.bsi-global.com/Technical+Information/Publications/_Publications/tig90.xalter % "ZAR " int_curr_symbol "<U005A><U0041><U0052><U0020>" % "R" currency_symbol "<U0052>" % "." mon_decimal_point "<U002E>" % "," mon_thousands_sep "<U002C>" mon_grouping 3;3 positive_sign "" % "-" negative_sign "<U002D>" int_frac_digits 2 frac_digits 2 p_cs_precedes 1 p_sep_by_space 0 n_cs_precedes 1 n_sep_by_space 0 p_sign_posn 1 n_sign_posn 1 END LC_MONETARY LC_NUMERIC % "." decimal_point "<U002E>" % "," thousands_sep "<U002C>" grouping 3;3 END LC_NUMERIC LC_TIME % abday - The abbreviations for the week days: % - Sun, Mon, Tue, Wed, Thu, Fri, Sat abday "<U0053><U0075><U006E>";"<U004D><U006F><U006E>";/ "<U0054><U0075><U0065>";"<U0057><U0065><U0064>";/ "<U0054><U0068><U0075>";"<U0046><U0072><U0069>";/ "<U0053><U0061><U0074>" <...snip...> % Date representation to be referenced by the "%x" field descriptor - % "%d/%m/%Y", day/month/year as decimal numbers (01/01/2000). d_fmt "<U0025><U0064><U002F><U0025><U006D><U002F><U0025><U0059>" <...snip...> first_weekday 1 END LC_TIME LC_PAPER <...snip...> END LC_PAPER LC_TELEPHONE <...snip...> END LC_TELEPHONE ----------------[ end ]---------------------

Include rtl/unix/clocale.pp into your project.

Petr

Ing. Petr Kristan . EPOS PRO s.r.o., Bozeny Nemcove 2625, 530 02 Pardubice tel: +420 466335223 Czech Republic (Eastern Europe) fax: +420 466510709

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys: In FPC the locale information is all hard-coded for Linux and other Unix based systems.…
Graeme Geldenhuys wrote 18 lines
Hi, In FPC the locale information is all hard-coded for Linux and other Unix based systems. We don't all live in the USA. ;-) This is very annoying. I also know we may not use glibc calls in FPC to get the locale information, because glibc is not always available on systems other than Linux. Today I found the following on my Linux system which could possibly solve this issues. Could other Linux distros and Unix users (*BSD, etc) confirm if they also have the following directory? Under Ubuntu 7.10 I have the follow directory: /usr/share/i18n/locales/ Inside that directory are files like en_GB, en_US, es_ES, de_DE etc.... They are plain text files that should be fairly easy to parse and extract the locale information. Couldn't we use that to populate the locale information inside FPC, without the need of glibc?

I am aware of this, there should also be a symbolink link in /etc to one of these files. The reason I didn't use this info is because writing a parser for these files is not trivial.

So, if you can write a parser for these files, please do, and I'll integrate it at once in the sysutils unit :-)

Michael.

Reply by email

Marco van de Voort
to Unknown author: Include rtl/unix/clocale.pp into your project. Petr Ing. Petr Kristan . EPOS PRO s.r.o.,…
Show quoted text 8 lines
On Mon, Aug 04, 2008 at 09:31:35AM +0200, Graeme Geldenhuys wrote: > > LC_TELEPHONE > <...snip...> > END LC_TELEPHONE > ----------------[ end ]--------------------- > Include rtl/unix/clocale.pp into your project.

Note that clocale has been in the fixes branch (and thus in 2.2.2rcs) for a few months. 2.2.0 doesn't have it yet.

Reply by email

Graeme Geldenhuys
to Unknown author: Include rtl/unix/clocale.pp into your project. Petr Ing. Petr Kristan . EPOS PRO s.r.o.,…
> Include rtl/unix/clocale.pp into your project.

Thanks Petr, but that requires libc, hence the reason it can't be added to the sysutils unit. That was my understanding of the locale issue, based an a message I posted some months ago. Also, those libc API calls read the binary form of the locale files if I remember correctly.

What I am suggesting, is reading the plain text locale files and parse them ourselves without the need for Libc dependency.

I just need to confirm what other Linux and Unix OS's have those files available? My suggestion would be no good if only Ubuntu includes those files, but not other Linux distros or *BSD etc...

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys
Graeme Geldenhuys wrote 16 lines
On Mon, Aug 4, 2008 at 9:38 AM, wrote: >> > Include rtl/unix/clocale.pp into your project. Thanks Petr, but that requires libc, hence the reason it can't be added to the sysutils unit. That was my understanding of the locale issue, based an a message I posted some months ago. Also, those libc API calls read the binary form of the locale files if I remember correctly. What I am suggesting, is reading the plain text locale files and parse them ourselves without the need for Libc dependency. I just need to confirm what other Linux and Unix OS's have those files available? My suggestion would be no good if only Ubuntu includes those files, but not other Linux distros or *BSD etc...

All Linuxes have these files, they are required by Libc. I suppose that BSD has a similar mechanism as I think it is a POSIX spec.

Michael.

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: I am aware of this, there should also be a symbolink link in /etc to one of these files.…
Michael Van Canneyt wrote
I am aware of this, there should also be a symbolink link in /etc to one of these files. The reason I didn't use this info is because writing a parser for these files is not trivial.

I couldn't find any symbolic link in my /etc directory pointing to /usr/share/i18n/locale/*. Well, nothing for the parsing. I viewed quite a few and the all seem to have the same format. Plus the en_ZA file is quite well documented with comments explaining the meaning of the values. It's should be easy to parse.

So, if you can write a parser for these files, please do, and I'll integrate it at once in the sysutils unit :-)

I'll first wait and see if the '/usr/share/i18n/locale/' directory is common to other distros as well, before I start the work.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Marco van de Voort
to Graeme Geldenhuys: Thanks Petr, but that requires libc, hence the reason it can't be added to the sysutils…

[ Charset UTF-8 unsupported, converting... ]

Show quoted text 9 lines
On Mon, Aug 4, 2008 at 9:38 AM, wrote: >> > Include rtl/unix/clocale.pp into your project. Thanks Petr, but that requires libc, hence the reason it can't be added to the sysutils unit. That was my understanding of the locale issue, based an a message I posted some months ago. Also, those libc API calls read the binary form of the locale files if I remember correctly.

But it fills the locale records of the sysutils unit if you include it in your mainprogram. IOW it just works like thread support. (cthreads), where a libc driver updates system/classes (the threaddriver). clocale does the same for sysutils' locale.

What I am suggesting, is reading the plain text locale files and parse them ourselves without the need for Libc dependency.

It will add a lot of code to all programs, and make you dependant on the formats changing. Maybe it would be more clear if you explained what the problem with the clocale solution exactly is.

I just need to confirm what other Linux and Unix OS's have those files available?

FreeBSD seems to have different ones. Some are text, but just lists of strings without any annotation (iow different from yours). Some are binary.

Location /usr/share/locale/nl_NL.<codepage> The utf-8 ones are symlinks to the ISO8859-1 ones.

LC_COLLATE binary
LC_MESSAGES Something that looks like two regexes on separate lines. LC_NUMERIC 6 byte file. Probably a kind of record, but a field per line. LC_CTYPE binary
LC_MONETARY Same build-up as LC_NUMERIC, but larger. LC_TIME Same again, but even larger.

Reply by email

Marco van de Voort
to Michael Van Canneyt: All Linuxes have these files, they are required by Libc. I suppose that BSD has a similar…
Show quoted text 6 lines
On Mon, 4 Aug 2008, Graeme Geldenhuys wrote: > available? My suggestion would be no good if only Ubuntu includes > those files, but not other Linux distros or *BSD etc... All Linuxes have these files, they are required by Libc. I suppose that BSD has a similar mechanism as I think it is a POSIX spec.

The functions are, not the format of the storage.

Reply by email

Michael Van Canneyt
to Marco van de Voort
Marco van de Voort wrote 6 lines
> On Mon, 4 Aug 2008, Graeme Geldenhuys wrote: > > So, if you can write a parser for these files, please do, and I'll integrate > it at once in the sysutils unit :-) Why that? What is the problem with clocale?

The Libc dependency. Sysutils is used in a lot of small programs which do not necessarily depend on Libc. Having a locale available for these without pulling in libc would be a big plus in my eyes.

If we can have a routine that parses the locale file, we can add it to sysutils or as a plugin unit, whatever. To have separate widestring managers and thread managers would also be a good thing (tm).

Michael.

Reply by email

Graeme Geldenhuys
to Marco van de Voort: Why that? What is the problem with clocale?
Marco van de Voort wrote 6 lines
> On Mon, 4 Aug 2008, Graeme Geldenhuys wrote: > > So, if you can write a parser for these files, please do, and I'll integrate > it at once in the sysutils unit :-) Why that? What is the problem with clocale?

Old email from Michael regarding this....
Dependency on libc is not allowed in the sysutils.

---------- Forwarded message ----------

Earlier message 44 lines
From: Michael Van Canneyt Date: Mon, Mar 10, 2008 at 3:33 PM Subject: Re: [fpc-devel] Date and Time formatting via locale settings doesn't work under FPC 2.2.0 To: FPC developers' list On Mon, 10 Mar 2008, Graeme Geldenhuys wrote: > We got the exact same output on all three PC's tested. So basically > the locale/region information is totally ignored! Is the date format > hard-coded under Linux or is there something vital that we are missing > under Linux? The locale/region information is ignored by default. I have a unit that loads this information using Libc or the KDE settings, but it is not an option to have this in sysutils by default, since it introduces a dependency on Libc. The section on 'Localization support' in the sysutils documentation mentions that: Localization support depends on various constants and structures being initialized correctly. On Windows and OS/2 this is done automatically: a widestring manager is installed by default which helps taking care of the current locale when performing various operations on strings. The various internationalization settings (date/time format, currency, language etc) are also initialized correctly on these platforms. Michael. ------------------------[ end ]--------------------------- Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/

Reply by email

Marco van de Voort
to Michael Van Canneyt: The Libc dependency. Sysutils is used in a lot of small programs which do not necessarily…
Show quoted text 9 lines
On Mon, 4 Aug 2008, Marco van de Voort wrote: > > it at once in the sysutils unit :-) > > Why that? What is the problem with clocale? The Libc dependency. Sysutils is used in a lot of small programs which do not necessarily depend on Libc. Having a locale available for these without pulling in libc would be a big plus in my eyes.

It will inflate the size, but worse it will make these little applications vulnerable for bugs in the reading of these files, even if they don't use the locale info. These kind of things are simply more sensitive on *nix.

But since we know the libc interface is also not always stable, it might be good to have a choice. But please if you do implement this, keep it plugin style to keep choice, and avoid adding a dangerous dependancy to programs that don't use it.

If we can have a routine that parses the locale file, we can add it to sysutils or as a plugin unit, whatever. To have separate widestring managers and thread managers would also be a good thing (tm).

Yes, in time we'll need an own implementation of a (limited) widestring manager. Actually the unit charset already is a bit of a core for this (it converts codepages over unicode to other codepages).

Reply by email

Michael Van Canneyt
to Marco van de Voort
Marco van de Voort wrote 18 lines
> On Mon, 4 Aug 2008, Marco van de Voort wrote: > > > > it at once in the sysutils unit :-) > > > > Why that? What is the problem with clocale? > > The Libc dependency. Sysutils is used in a lot of small programs which > do not necessarily depend on Libc. Having a locale available for these > without pulling in libc would be a big plus in my eyes. It will inflate the size, but worse it will make these little applications vulnerable for bugs in the reading of these files, even if they don't use the locale info. These kind of things are simply more sensitive on *nix. But since we know the libc interface is also not always stable, it might be good to have a choice. But please if you do implement this, keep it plugin style to keep choice, and avoid adding a dangerous dependancy to programs that don't use it.

Like I said in the paragraph below: or as a plugin unit :-)

Show quoted text 8 lines
> If we can have a routine that parses the locale file, we can add it to > sysutils or as a plugin unit, whatever. To have separate widestring > managers and thread managers would also be a good thing (tm). Yes, in time we'll need an own implementation of a (limited) widestring manager. Actually the unit charset already is a bit of a core for this (it converts codepages over unicode to other codepages).

I know.
I have a framework for a 'fprecode' style unit ready, for use e.g. in TDataset.

Michael.

Reply by email

Vladimir Zhirov
to Graeme Geldenhuys: In FPC the locale information is all hard-coded for Linux and other Unix based systems.…
Graeme Geldenhuys wrote 5 lines
Today I found the following on my Linux system which could possibly solve this issues. Could other Linux distros and Unix users (*BSD, etc) confirm if they also have the following directory? Under Ubuntu 7.10 I have the follow directory: /usr/share/i18n/locales/

I don't have such directory on my ALT Linux Desktop 4.0. This is the latest desktop release of Russian KDE-based Linux distribution (http://www.altlinux.ru/). It is not so widespread as Ubuntu, but is popular in Russia, especially in education.

Reply by email

Graeme Geldenhuys
to Vladimir Zhirov
Vladimir Zhirov wrote 7 lines
> > Under Ubuntu 7.10 I have the follow directory: /usr/share/i18n/locales/ I don't have such directory on my ALT Linux Desktop 4.0. This is the latest desktop release of Russian KDE-based Linux distribution (http://www.altlinux.ru/). It is not so widespread as Ubuntu, but is popular in Russia, especially in education.

Thanks for letting me know. I'll try and find out what exact package those files came form. If only I can remember the damn apt command! :-) That way we can see if it's part of the FreeDesktop standard or something...

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Vinzent Höfler
to Graeme Geldenhuys

-------- Original-Nachricht --------

Show quoted text 22 lines
Datum: Mon, 4 Aug 2008 18:47:34 +0200 Von: "Graeme Geldenhuys" An: "FPC developers\' list" Betreff: Re: [fpc-devel] Locale solution for Linux (and maybe *nix) On Mon, Aug 4, 2008 at 5:56 PM, Vladimir Zhirov wrote: >> >> Under Ubuntu 7.10 I have the follow directory: /usr/share/i18n/locales/ > > I don't have such directory on my ALT Linux Desktop 4.0. > This is the latest desktop release of Russian KDE-based Linux distribution > (http://www.altlinux.ru/). It is not so widespread as Ubuntu, but is popular > in Russia, especially in education. Thanks for letting me know. I'll try and find out what exact package those files came form. If only I can remember the damn apt command! :-) That way we can see if it's part of the FreeDesktop standard or something...

-- 8< --
dpkg -s locales
Package: locales
Status: install ok installed
Priority: standard
Section: libs
Installed-Size: 9848
Maintainer: GNU Libc Maintainers
Architecture: all
Source: glibc
Version: 2.3.6.ds1-13etch7
Replaces: base-config, lliurex-belocs-locales-data Depends: glibc-2.3.6.ds1-1, debconf | debconf-2.0
Conflicts: base-config, belocs-locales-bin, belocs-locales-data Description: GNU C Library: National Language (locale) data [support] Machine-readable data files, shared objects and programs used by the C library for localization (l10n) and internationalization (i18n) support. .
This package contains the libc.mo i18n files, plus tools to generate locale definitions from source files (included in this package). It allows you to customize which definitions actually get generated. This is a savings over how this package used to be, where all locales were generated by default. This created a package that unpacked to an excess of 30 megs. -- 8< --

From a Debian 4.0, but I guess, it's about the same on Ubuntu.

Vinzent.

GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys: Thanks for letting me know. I'll try and find out what exact package those files came…
Graeme Geldenhuys wrote 13 lines
On Mon, Aug 4, 2008 at 5:56 PM, Vladimir Zhirov wrote: >> >> Under Ubuntu 7.10 I have the follow directory: /usr/share/i18n/locales/ > > I don't have such directory on my ALT Linux Desktop 4.0. > This is the latest desktop release of Russian KDE-based Linux distribution > (http://www.altlinux.ru/). It is not so widespread as Ubuntu, but is popular > in Russia, especially in education. Thanks for letting me know. I'll try and find out what exact package those files came form. If only I can remember the damn apt command! :-) That way we can see if it's part of the FreeDesktop standard or something...

On SuSE it's part of glibc-i18ndata

Michael.

Reply by email

Michael Van Canneyt
to Vladimir Zhirov: I don't have such directory on my ALT Linux Desktop 4.0. This is the latest desktop…
Vladimir Zhirov wrote 11 lines
Graeme Geldenhuys wrote: > Today I found the following on my Linux system which could possibly > solve this issues. Could other Linux distros and Unix users (*BSD, > etc) confirm if they also have the following directory? > > Under Ubuntu 7.10 I have the follow directory: /usr/share/i18n/locales/ I don't have such directory on my ALT Linux Desktop 4.0. This is the latest desktop release of Russian KDE-based Linux distribution (http://www.altlinux.ru/). It is not so widespread as Ubuntu, but is popular in Russia, especially in education.

I have checked altlinux.ru, and it is rpm-based. The glibc-i18ndata is definitely in the package list, probably you simply don't have it installed. I downloaded the package file and it has the same files as on SuSE.

You can check with the file
rpm -q glibc-i18ndata
and if rpm says it is installed, then you can do a rpm -q -l glibc-i18ndata

To Graeme: I think you can go ahead if you want to implement such routines. Make an interface that accepts a filename, and by default the unit will look in some standard locations.

Michael.

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: I have checked altlinux.ru, and it is rpm-based. The glibc-i18ndata is definitely in the…
Michael Van Canneyt wrote
To Graeme: I think you can go ahead if you want to implement such routines. Make an interface that accepts a filename, and by default the unit will look in some standard locations.

OK, added to my todo list. :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys
Graeme Geldenhuys wrote 8 lines
On Mon, Aug 4, 2008 at 8:43 PM, Michael Van Canneyt wrote: > > To Graeme: I think you can go ahead if you want to implement such routines. > Make an interface that accepts a filename, and by default the unit will look > in some standard locations. OK, added to my todo list. :-)

And scratched off mine... :-)

Michael.

Reply by email

Vladimir Zhirov
to Michael Van Canneyt: I have checked altlinux.ru, and it is rpm-based. The glibc-i18ndata is definitely in the…
Michael Van Canneyt wrote 8 lines
I have checked altlinux.ru, and it is rpm-based. The glibc-i18ndata is definitely in the package list, probably you simply don't have it installed. I downloaded the package file and it has the same files as on SuSE. You can check with the file rpm -q glibc-i18ndata and if rpm says it is installed, then you can do a rpm -q -l glibc-i18ndata

Impressive :) Thanks, Michael.
With this package installed these files appeared.

Reply by email

Michael Van Canneyt
to Vladimir Zhirov
Vladimir Zhirov wrote 13 lines
Michael Van Canneyt wrote: > I have checked altlinux.ru, and it is rpm-based. The glibc-i18ndata is definitely > in the package list, probably you simply don't have it installed. I downloaded the > package file and it has the same files as on SuSE. > > You can check with the file > rpm -q glibc-i18ndata > and if rpm says it is installed, then you can do a > rpm -q -l glibc-i18ndata Impressive :) Thanks, Michael. With this package installed these files appeared.

The pressure on Graeme just went up by a quantum... ;-)

Michael.

Reply by email

Marco van de Voort
to Graeme Geldenhuys: On Mon, Aug 4, 2008 at 8:43 PM, Michael Van Canneyt OK, added to my todo list. :-) -…
Show quoted text 8 lines
On Mon, Aug 4, 2008 at 8:43 PM, Michael Van Canneyt wrote: > > To Graeme: I think you can go ahead if you want to implement such routines. > Make an interface that accepts a filename, and by default the unit will look > in some standard locations. OK, added to my todo list. :-)

Shall I send you the FreeBSD files ? Maybe I can even dig up some description from the manpages.

Reply by email