Interpretation of extensions different from Unix/Linux?

Interpretation of extensions different from Unix/Linux?

[vlc]

Hi *,

I noticed that the function Ada.Directories.Base_Name has a different
opinion about what a file name / extension is than my linux box:

$ cat base_name_test.adb
with Ada.Text_Io;     use Ada.Text_Io;
with Ada.Directories; use Ada.Directories;

procedure Base_Name_Test is
begin
   Put_Line ("Base_Name: " & Base_Name (".b"));
   Put_Line ("Extension: " & Extension (".b"));
end Base_Name_Test;

$ ./base_name_test
Base_Name:
Extension: b

$ basename .b
.b

Is there a reason for this difference?

Thanks a lot in advance for any help!

Re: Interpretation of extensions different from Unix/Linux?

[Jacob Sparre Andersen]

Somebody wrote:

> I noticed that the function Ada.Directories.Base_Name has a different
> opinion about what a file name / extension is than my linux box:
>
> $ cat base_name_test.adb
> with Ada.Text_Io;     use Ada.Text_Io;
> with Ada.Directories; use Ada.Directories;
>
> procedure Base_Name_Test is
> begin
>    Put_Line ("Base_Name: " & Base_Name (".b"));
>    Put_Line ("Extension: " & Extension (".b"));
> end Base_Name_Test;
>
> $ ./base_name_test
> Base_Name:
> Extension: b
>
> $ basename .b
> .b
>
> Is there a reason for this difference?

The specifications are different.

The GNU basename command removes "any leading directory components".
If _specified_, it will "also remove a trailing SUFFIX".

Greetings,

Jacob
-- 
Infinite loop: n., see loop, infinite.
Loop, infinite: n., see infinite loop.

Re: Interpretation of extensions different from Unix/Linux?

[vlc]

On Aug 2, 7:13 pm, Jacob Sparre Andersen <spa...@nbi.dk> wrote:
> The specifications are different.
>
> The GNU basename command removes "any leading directory components".
> If _specified_, it will "also remove a trailing SUFFIX".
>
> Greetings,
>
> Jacob
> --
> Infinite loop: n., see loop, infinite.
> Loop, infinite: n., see infinite loop.

If the specifications are different, the utilities in Ada.Directories
are quite unusable for UNIX/Linux. In case I want to process all *.c
files in a given directory, I could code something like

with Ada.Directories; use Ada.Directories;

procedure Parse is
   procedure Do_It (Directory_Entry : Directory_Entry_Type) is
   begin
      -- Do something
   end Do_It;
begin
   Ada.Directories.Search (".", "*.c", (others => True),
Do_It'Access);
end Parse;

If I want to ensure me what files will be processed, I would call e.g.

ls -A *.c

first. But if there would be a file ".c" in the current directory, it
would not be listed by the "ls" command, but processed by my program.

Cheers!

Re: Interpretation of extensions different from Unix/Linux?

[Jacob Sparre Andersen]

Somebody <just.another.spam.account@googlemail.com> wrote:
> On Aug 2, 7:13�pm, Jacob Sparre Andersen <spa...@nbi.dk> wrote:

> > The specifications are different.
> >
> > The GNU basename command removes "any leading directory components".
> > If _specified_, it will "also remove a trailing SUFFIX".

> If the specifications are different, the utilities in
> Ada.Directories are quite unusable for UNIX/Linux.

I disagree!

> In case I want to process all *.c files in a given directory, I
> could code something like
> 
> with Ada.Directories; use Ada.Directories;
> 
> procedure Parse is
>    procedure Do_It (Directory_Entry : Directory_Entry_Type) is
>    begin
>       -- Do something
>    end Do_It;
> begin
>    Ada.Directories.Search (".", "*.c", (others => True), Do_It'Access);
> end Parse;

Unfortunately the meaning of the argument "Pattern" to
"Ada.Directories.Search" is implementation defined (RM-A-16-111/2).
You will have to check the manual for your compiler, to find out how
"Pattern" is interpreted.

> If I want to ensure me what files will be processed, I would call
> e.g.
> 
> ls -A *.c
> 
> first.

But that list depends on your shell.

> But if there would be a file ".c" in the current directory, it would
> not be listed by the "ls" command, but processed by my program.

That depends on your shell.

Greetings,

Jacob
-- 
Who guards the guardians?

Re: Interpretation of extensions different from Unix/Linux?

[Georg Bauhaus]

Jacob Sparre Andersen schrieb:
> Somebody <just.another.spam.account@googlemail.com> wrote:
>> On Aug 2, 7:13 pm, Jacob Sparre Andersen <spa...@nbi.dk> wrote:
> 
>>> The specifications are different.
>>>
>>> The GNU basename command removes "any leading directory components".
>>> If _specified_, it will "also remove a trailing SUFFIX".
> 
>> If the specifications are different, the utilities in
>> Ada.Directories are quite unusable for UNIX/Linux.
> 
> I disagree!
> 
>> In case I want to process all *.c files in a given directory, I
>> could code something like
>>
>> with Ada.Directories; use Ada.Directories;
>>
>> procedure Parse is
>>    procedure Do_It (Directory_Entry : Directory_Entry_Type) is
>>    begin
>>       -- Do something
>>    end Do_It;
>> begin
>>    Ada.Directories.Search (".", "*.c", (others => True), Do_It'Access);
>> end Parse;
> 
> Unfortunately the meaning of the argument "Pattern" to
> "Ada.Directories.Search" is implementation defined (RM-A-16-111/2).

Not surprisingly?  Even the set of permissible characters
in a file name differs among OSs.

In Ada or other languages, all I have seen is directory
searches as a procedures that runs along a list of results
(file names from a directory) and pay attention to
special names like "." or "..".  Seems quite easy to
filter Unix's hidden names?

Re: Interpretation of extensions different from Unix/Linux?

[vlc]

On Aug 4, 1:57 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> Not surprisingly?  Even the set of permissible characters
> in a file name differs among OSs.

This differs even among applications on the same OS.

> In Ada or other languages, all I have seen is directory
> searches as a procedures that runs along a list of results
> (file names from a directory) and pay attention to
> special names like "." or "..".  Seems quite easy to
> filter Unix's hidden names?

Sure, it's not a big thing to add files / directories starting with a
dot as a special case, but I have to think about it. If the
interpretation would be the same, I would not have to care.

Cheers!

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Tue, 04 Aug 2009 13:57:39 +0200, Georg Bauhaus wrote:

> Jacob Sparre Andersen schrieb:

>> Unfortunately the meaning of the argument "Pattern" to
>> "Ada.Directories.Search" is implementation defined (RM-A-16-111/2).
> 
> Not surprisingly?  Even the set of permissible characters
> in a file name differs among OSs.

Surprising is that Ada.Directories uses plain String for file names, paths,
extension and patterns. This is clearly not an "Ada way" to deal with such
things.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:b4dn28zky4qe$.mrr68avem08a$.dlg@40tude.net...
...
> Surprising is that Ada.Directories uses plain String for file names, 
> paths,
> extension and patterns. This is clearly not an "Ada way" to deal with such
> things.

Why is that surprising? It has to be compatible with the file names accepted 
by the various Open routines in Ada.Text_IO, Ada.Direct_IO, etc.

You could argue that String is the wrong choice for all of those things, and 
I think you'd be right, but it's irrelevant as we stuck with the Ada 83 
definitions of the file I/O routines. (Adding overloaded ones would be 
unacceptibly incompatible, you wouldn't be able to use literals.)

                                                     Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Thu, 13 Aug 2009 23:33:40 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:b4dn28zky4qe$.mrr68avem08a$.dlg@40tude.net...
> ...
>> Surprising is that Ada.Directories uses plain String for file names, paths,
>> extension and patterns. This is clearly not an "Ada way" to deal with such
>> things.
> 
> Why is that surprising? It has to be compatible with the file names accepted 
> by the various Open routines in Ada.Text_IO, Ada.Direct_IO, etc.
>
> You could argue that String is the wrong choice for all of those things, and 
> I think you'd be right, but it's irrelevant as we stuck with the Ada 83 
> definitions of the file I/O routines. (Adding overloaded ones would be 
> unacceptibly incompatible, you wouldn't be able to use literals.)

No, I don't see any problem here. There is no literals for private types,
(unfortunately). But if the type Fully_Qualified_File_Name (or whatever we
called it) should have literals, they would be record aggregates. So we
would write something like:

   File : File_Type;
begin
   Open
   (  File => File,
      Mode => In_File,
      Name =>
      (  Volume => "C:",
         Directory => ("Documents and Settings", "me", "work"),
         Name => "test",
         Extension => "txt"
   )  );

the above is impossible due to language limitations, but we could:

   File : File_Type;
begin
   Open
   (  File => File,
      Mode => In_File,
      Volume => "C:",
      Directory => ("Documents and Settings", "me", "work"),
      Name => "test",
      Extension => "txt"
   );

or / and

   File : File_Type;
begin
   Open
   (  File => File,
      Mode => In_File,
      Name =>
      Name
      (  Volume => "C:",
         Directory => ("Documents and Settings", "me", "work"),
         Name => "test",
         Extension => "txt"
   )  );

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[vlc]

On Aug 4, 1:44 pm, Jacob Sparre Andersen <spa...@nbi.dk> wrote:
> Unfortunately the meaning of the argument "Pattern" to
> "Ada.Directories.Search" is implementation defined (RM-A-16-111/2).
> You will have to check the manual for your compiler, to find out how
> "Pattern" is interpreted.

The "Pattern" is implementation defined (which implies IMHO that this
function is not portable between compilers), but the same problem also
occurs with the functions "Base_Name" and "Extension" as shown in my
first post.

> But that list depends on your shell.

Hmmm, I just tried with bash, sh, dash, zsh, csh and tcsh, always the
same behaviour. Are there any more shells out there?

I just noticed that I have to take care when processing file names /
extensions as the creators of Ada seem to disagree with the UNIX /
Linux guys about the composition of a file name.

Cheers!

Re: Interpretation of extensions different from Unix/Linux?

[Jeffrey R. Carter]

vlc wrote:
> 
> I just noticed that I have to take care when processing file names /
> extensions as the creators of Ada seem to disagree with the UNIX /
> Linux guys about the composition of a file name.

Ada is OS independent, and tries to be OS neutral. It's if you assume otherwise 
that you'll cause yourself trouble.

-- 
Jeff Carter
"This trial is a travesty. It's a travesty of a mockery of a
sham of a mockery of a travesty of two mockeries of a sham. ...
Do you realize there's not a single homosexual on that jury?"
Bananas
27

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Tue, 04 Aug 2009 12:18:08 -0700, Jeffrey R. Carter wrote:

> vlc wrote:
>> 
>> I just noticed that I have to take care when processing file names /
>> extensions as the creators of Ada seem to disagree with the UNIX /
>> Linux guys about the composition of a file name.
> 
> Ada is OS independent, and tries to be OS neutral.

But Ada.Directories does not.

> It's if you assume otherwise 
> that you'll cause yourself trouble.

One have to assume otherwise when using Ada.Directories, which
unfortunately was not designed OS-agnostic.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> On Tue, 04 Aug 2009 12:18:08 -0700, Jeffrey R. Carter wrote:
> 
>> vlc wrote:
>>> I just noticed that I have to take care when processing file names /
>>> extensions as the creators of Ada seem to disagree with the UNIX /
>>> Linux guys about the composition of a file name.
>> Ada is OS independent, and tries to be OS neutral.
> 
> But Ada.Directories does not.
> 
>> It's if you assume otherwise 
>> that you'll cause yourself trouble.
> 
> One have to assume otherwise when using Ada.Directories, which
> unfortunately was not designed OS-agnostic.

I disagree. While Ada.Directories is limited to OSes with file systems, it tries 
to be neutral towards such OSes.

-- 
Jeff Carter
"This trial is a travesty. It's a travesty of a mockery of a
sham of a mockery of a travesty of two mockeries of a sham. ...
Do you realize there's not a single homosexual on that jury?"
Bananas
27

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Tue, 04 Aug 2009 13:45:33 -0700, Jeffrey R. Carter wrote:

> Dmitry A. Kazakov wrote:
>> On Tue, 04 Aug 2009 12:18:08 -0700, Jeffrey R. Carter wrote:
>> 
>>> vlc wrote:
>>>> I just noticed that I have to take care when processing file names /
>>>> extensions as the creators of Ada seem to disagree with the UNIX /
>>>> Linux guys about the composition of a file name.
>>> Ada is OS independent, and tries to be OS neutral.
>> 
>> But Ada.Directories does not.
>> 
>>> It's if you assume otherwise 
>>> that you'll cause yourself trouble.
>> 
>> One have to assume otherwise when using Ada.Directories, which
>> unfortunately was not designed OS-agnostic.
> 
> I disagree. While Ada.Directories is limited to OSes with file systems, it tries 
> to be neutral towards such OSes.

I don't see how it was tried:

1. It assumes Latin-1 encoding of the file paths
2. It assumes singe root of the file system
3. Even so it provides no way to get the name of the root
4. It assumes that directory name can be composed from simple names
(Compose is broken for the systems where the syntax of a directory name
differs from the name of a plain file.)
5. It totally ignores devices, file versions, mount points, URL, URI
6. It does not eliminate OS-specific pseudo names, e.g "." and ".."
7. It does not provide any means to compare and canonize file names in an
OS-independent way

A trivial test is to write a portable program that prints names of all
files. With Ada.Directories it is impossible to do.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> 
> 1. It assumes Latin-1 encoding of the file paths

True, because of the definition of String. What specific OS that Ada.Directories 
is targeted to has such a limitation?

> 2. It assumes singe root of the file system

No, it doesn't. It has no concept of a root.

> 3. Even so it provides no way to get the name of the root

Because it is OS neutral, and there is no independent concept of a root.

> 4. It assumes that directory name can be composed from simple names
> (Compose is broken for the systems where the syntax of a directory name
> differs from the name of a plain file.)

The directory part has to be representable as a single String, but there's no 
requirement that directory names be the same as a plain file name.

> 5. It totally ignores devices, file versions, mount points, URL, URI

Since they do not exist on all OSes. More evidence of its OS neutrality.

> 6. It does not eliminate OS-specific pseudo names, e.g "." and ".."

Because it is OS neutral.

> 7. It does not provide any means to compare and canonize file names in an
> OS-independent way

I'm not sure what you mean. A file name is a String; one compares them using 
String operations. One can use Full_Name to determine if two paths are the same 
file. Dealing with OS-dependent features, such as case insensitivity, is 
obviously not part of an OS-neutral pkg.

> A trivial test is to write a portable program that prints names of all
> files. With Ada.Directories it is impossible to do.

It's impossible with any OS-neutral pkg.

-- 
Jeff Carter
"This trial is a travesty. It's a travesty of a mockery of a
sham of a mockery of a travesty of two mockeries of a sham. ...
Do you realize there's not a single homosexual on that jury?"
Bananas
27

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Tue, 04 Aug 2009 15:04:55 -0700, Jeffrey R. Carter wrote:

> Dmitry A. Kazakov wrote:
>> 
>> 1. It assumes Latin-1 encoding of the file paths
> 
> True, because of the definition of String. What specific OS that Ada.Directories 
> is targeted to has such a limitation?

Maybe MS-DOS?

Latin-1 is a limitation that makes impossible to write OS-independent
programs. BTW, I didn't check it but I suppose that the GNAT implementation
is not even Latin-1, it is in fact UTF-8, at least under Linux. So it is
broken twice. Once per design, once by the implementation to fix broken
design.

>> 2. It assumes singe root of the file system
> 
> No, it doesn't. It has no concept of a root.

Is this any better?

>> 3. Even so it provides no way to get the name of the root
> 
> Because it is OS neutral, and there is no independent concept of a root.

An OS-neutral Ada.Directories would provide enumeration of roots. Any
usable Ada.Directories must have the concept of roots nodes.

>> 4. It assumes that directory name can be composed from simple names
>> (Compose is broken for the systems where the syntax of a directory name
>> differs from the name of a plain file.)
> 
> The directory part has to be representable as a single String, but there's no 
> requirement that directory names be the same as a plain file name.

The requirement is implicit because Compose and Containing_Directory do not
distinguish absolute and relative paths, directory and file names.

>> 5. It totally ignores devices, file versions, mount points, URL, URI
> 
> Since they do not exist on all OSes. More evidence of its OS neutrality.

That only makes it unusable. A portable package is not the least
denominator (which is most likely null). It is a mapping to some language
defined concept of a file system. There is no problem to have such a
concept with devices which would work for OS-es that do not have them. The
inverse is wrong.

>> 6. It does not eliminate OS-specific pseudo names, e.g "." and ".."
> 
> Because it is OS neutral.

No, it is because it is not neutral. It fails to abstract proper DAG from a
file system.

>> 7. It does not provide any means to compare and canonize file names in an
>> OS-independent way
> 
> I'm not sure what you mean. A file name is a String; one compares them using 
> String operations. One can use Full_Name to determine if two paths are the same 
> file. Dealing with OS-dependent features, such as case insensitivity, is 
> obviously not part of an OS-neutral pkg.

It is a required part of.

IF file name is a String (which is not!), THEN the operations defined on
String must be semantically meaningful for file names. Standard string
comparison is not meaningful. Hence either the file name is not String or
else "=" is broken.

>> A trivial test is to write a portable program that prints names of all
>> files. With Ada.Directories it is impossible to do.
> 
> It's impossible with any OS-neutral pkg.

This is not true. But if it were true, then I don't understand why
Ada.Directories was introduced.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:

    a bunch of stuff

It's clear that our definitions of "neutral" differ. I mean offering a set of 
operations common to all OS' file systems; you seem to mean offering all 
possible operations for all OS' file systems.

I don't think that a pkg meeting what seems to be your meaning is possible 
within a reasonable effort. If you disagree, I'd like to see your version of 
such a pkg, including implementations for 2 significantly differing file systems 
(for example, one that maintains different versions of files and one that doesn't).

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Wed, 05 Aug 2009 09:07:56 -0700, Jeffrey R. Carter wrote:

> Dmitry A. Kazakov wrote:
> 
>     a bunch of stuff
> 
> It's clear that our definitions of "neutral" differ. I mean offering a set of 
> operations common to all OS' file systems; you seem to mean offering all 
> possible operations for all OS' file systems.

Not so. The situation is same as with Ada tasks. Ada does not try to
provide all possible tasking operations, processes, threads, fibers etc.
Instead of that it provides a model of concurrent computing that can be
mapped to practically any OS. This is what I consider portable. The same
can be done to abstract file systems. We do not need to provide all
operations of concrete file systems, we have to the operation one has in
mind working with a file system.

> I don't think that a pkg meeting what seems to be your meaning is possible 
> within a reasonable effort. If you disagree, I'd like to see your version of 
> such a pkg, including implementations for 2 significantly differing file systems 
> (for example, one that maintains different versions of files and one that doesn't).

Hmm, I see no problem with that. I would change Compose, just one more
argument:

type Absolute_Path is private;
type Simple_Name is private;
type File_Extension is private;
type File_Version is range <implementation-defined>;

function Compose
(  Containing_Directory : Absolute_Path := Current_Directory;
   Name : Simple_Name;
   Extension : File_Extension := No_Extension;
   Version : File_Version := File_Version'First
) return Absolute_Path;

For a file system without versions the only valid File_Version will be 1.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> 
> Not so. The situation is same as with Ada tasks. Ada does not try to
> provide all possible tasking operations, processes, threads, fibers etc.
> Instead of that it provides a model of concurrent computing that can be
> mapped to practically any OS. This is what I consider portable. The same
> can be done to abstract file systems. We do not need to provide all
> operations of concrete file systems, we have to the operation one has in
> mind working with a file system.

I don't think the situations are precisely the same; Ada tasking can be 
implemented on systems with no OS. It would be somewhat more difficult to 
implement an abstraction of a file system on a system with no file system.

> Hmm, I see no problem with that. I would change Compose, just one more
> argument:
> 
> type Absolute_Path is private;
> type Simple_Name is private;
> type File_Extension is private;
> type File_Version is range <implementation-defined>;
> 
> function Compose
> (  Containing_Directory : Absolute_Path := Current_Directory;
>    Name : Simple_Name;
>    Extension : File_Extension := No_Extension;
>    Version : File_Version := File_Version'First
> ) return Absolute_Path;
> 
> For a file system without versions the only valid File_Version will be 1.

I think there would be more to it than that. You need to deal with roots, 
including none, single, and multiple; with "devices, ... mount points, URL, 
URI", even on file systems that have no concept of them; with comparing and 
canonizing file names; with file names that cannot be represented by a String.

And I'd think this would need to extend beyond Ada.Directories to all of the 
standard I/O pkgs.

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Wed, 05 Aug 2009 10:49:24 -0700, Jeffrey R. Carter wrote:

> Dmitry A. Kazakov wrote:
>> 
>> Not so. The situation is same as with Ada tasks. Ada does not try to
>> provide all possible tasking operations, processes, threads, fibers etc.
>> Instead of that it provides a model of concurrent computing that can be
>> mapped to practically any OS. This is what I consider portable. The same
>> can be done to abstract file systems. We do not need to provide all
>> operations of concrete file systems, we have to the operation one has in
>> mind working with a file system.
> 
> I don't think the situations are precisely the same; Ada tasking can be 
> implemented on systems with no OS. It would be somewhat more difficult to 
> implement an abstraction of a file system on a system with no file system.

A memory-mapped container with a tree structure? Consider it done!

>> Hmm, I see no problem with that. I would change Compose, just one more
>> argument:
>> 
>> type Absolute_Path is private;
>> type Simple_Name is private;
>> type File_Extension is private;
>> type File_Version is range <implementation-defined>;
>> 
>> function Compose
>> (  Containing_Directory : Absolute_Path := Current_Directory;
>>    Name : Simple_Name;
>>    Extension : File_Extension := No_Extension;
>>    Version : File_Version := File_Version'First
>> ) return Absolute_Path;
>> 
>> For a file system without versions the only valid File_Version will be 1.
> 
> I think there would be more to it than that.

Yes.

> You need to deal with roots, 
> including none, single, and multiple; with "devices, ... mount points, URL, 
> URI", even on file systems that have no concept of them; with comparing and 
> canonizing file names; with file names that cannot be represented by a String.

You asked for file versions.

A full interface of Ada.Directories would be an AI.

> And I'd think this would need to extend beyond Ada.Directories to all of the 
> standard I/O pkgs.

Sure, all Ada I/O packages should be expanded with non-string variants of
procedures using file names. This includes Directory_Entry_Type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> 
> A memory-mapped container with a tree structure? Consider it done!

It seems to lack persistence, one of the defining features of file systems.

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Wed, 05 Aug 2009 12:27:57 -0700, Jeffrey R. Carter wrote:

> Dmitry A. Kazakov wrote:
>> 
>> A memory-mapped container with a tree structure? Consider it done!
> 
> It seems to lack persistence, one of the defining features of file systems.

A non-volatile memory + for X'Address use ...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> 
> A non-volatile memory + for X'Address use ...

Hardly something that can be required by a language-defined pkg.

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Wed, 05 Aug 2009 13:46:06 -0700, Jeffrey R. Carter wrote:

> Dmitry A. Kazakov wrote:
>> 
>> A non-volatile memory + for X'Address use ...
> 
> Hardly something that can be required by a language-defined pkg.

That was a possible implementation. Other could use sockets (over an UART)
with an FTP client etc.

It is not a big problem to implement Ada I/O packages without a file
system.

And in no case bare boards should prevent us from making Ada environment
usable on main stream platforms.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Dmitry A. Kazakov wrote:
>> A memory-mapped container with a tree structure? Consider it done!
>
> It seems to lack persistence, one of the defining features of file systems.

There's no persistence requirement in the RM.  On an embedded system,
it might be perfectly reasonable for files to vanish on program
termination, or on power-off.  Such behavior would be a horrible
bug for an Ada implementation on Unix or Windows -- but it would
still conform to the RM.

There's also RM-1.1.3(6).

Just because some embedded systems don't have file systems, doesn't mean
we shouldn't have portable I/O packages (including directories) in the
language.  I mean, portable to the popular non-embedded operating
systems that exist today, not necessarily portable to any imaginable
OS.

Common Lisp has a pretty reasonable abstraction for dealing with path
names and directories and whatnot.

- Bob

Re: Interpretation of extensions different from Unix/Linux?

[vlc]

On Aug 5, 7:49 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Ada tasking can be implemented on systems with no OS.

Does this mean that Ada ships with its own scheduler?

What are the requirements for programming an Ada application for a µC
without an OS if I want to use tasking?

Thanks!

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Wed, 5 Aug 2009 12:45:11 -0700 (PDT), vlc wrote:

> On Aug 5, 7:49�pm, "Jeffrey R. Carter"
> <spam.jrcarter....@spam.acm.org> wrote:
>> Ada tasking can be implemented on systems with no OS.
> 
> Does this mean that Ada ships with its own scheduler?

Yes, and even under an OS.

Ada tasks can be mapped onto OS scheduling items or else scheduled by Ada
RTL. That is an implementation choice. The latter choice is less popular
because it becomes difficult to implement I/O which would not block all
tasks.

> What are the requirements for programming an Ada application for a �C
> without an OS if I want to use tasking?

No difference, provided you get a full Ada compiler.

However bare-board Ada compilers may have some vendor-specific
restrictions. You have to contact your compiler vendor for details.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:iavqqy3ue6ne$.uxihdofxdalx.dlg@40tude.net...
...
> Latin-1 is a limitation that makes impossible to write OS-independent
> programs. BTW, I didn't check it but I suppose that the GNAT 
> implementation
> is not even Latin-1, it is in fact UTF-8, at least under Linux. So it is
> broken twice. Once per design, once by the implementation to fix broken
> design.

Actually, the use of UTF-8 in this way is the recommendation of the ARG. We 
have no plans of changing any of the file handling routines away from 
String. We may add some Implementation Advice to make it clear that 
implementations are advised to support UTF-8 encoded file names.

>>> 3. Even so it provides no way to get the name of the root
>>
>> Because it is OS neutral, and there is no independent concept of a root.
>
> An OS-neutral Ada.Directories would provide enumeration of roots. Any
> usable Ada.Directories must have the concept of roots nodes.

Enumeration of roots is impractible on Windows, because every possible file 
share would have to be included in such a list (including any that don't 
have permissions to read). That would be impossibly slow, and pretty 
pointless to boot. It also would cause problems with removable disks 
(Windows gives a failure if you try to enumerate an empty floppy disk). I've 
dealt with those headaches from our compiler installer, and I wouldn't want 
to force them on other users of Ada.

If you can't do it reasonably in Windows, it surely doesn't belong in 
Ada.Directories.

                           Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Thu, 13 Aug 2009 23:56:03 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:iavqqy3ue6ne$.uxihdofxdalx.dlg@40tude.net...
> ...
>> Latin-1 is a limitation that makes impossible to write OS-independent
>> programs. BTW, I didn't check it but I suppose that the GNAT implementation
>> is not even Latin-1, it is in fact UTF-8, at least under Linux. So it is
>> broken twice. Once per design, once by the implementation to fix broken
>> design.
> 
> Actually, the use of UTF-8 in this way is the recommendation of the ARG. We 
> have no plans of changing any of the file handling routines away from 
> String. We may add some Implementation Advice to make it clear that 
> implementations are advised to support UTF-8 encoded file names.

The problem is 3.5.2 which claims that Character is Latin-1.

(UTF-8 is a problem of its own in Ada. We need a private type with two
interfaces. One of Wide_Wide_String another of an array of octets. Ada
cannot provide this.)

>>>> 3. Even so it provides no way to get the name of the root
>>>
>>> Because it is OS neutral, and there is no independent concept of a root.
>>
>> An OS-neutral Ada.Directories would provide enumeration of roots. Any
>> usable Ada.Directories must have the concept of roots nodes.
> 
> Enumeration of roots is impractible on Windows, because every possible file 
> share would have to be included in such a list (including any that don't 
> have permissions to read). That would be impossibly slow, and pretty 
> pointless to boot. It also would cause problems with removable disks 
> (Windows gives a failure if you try to enumerate an empty floppy disk). I've 
> dealt with those headaches from our compiler installer, and I wouldn't want 
> to force them on other users of Ada.

Same to me. But it is required to make Ada.Directories any usable.

Presently I use Exists in a loop through "A".."Z" + "/". That works both
under Linux and Windows. Do you think that is *better*?! (:-))

> If you can't do it reasonably in Windows, it surely doesn't belong in 
> Ada.Directories.

The MS-explorer does not drop that nasty c0000013 pop up window when
started. From this I conclude there should be a way to.

Technically, it is certainly possible, for example (a bit exaggerated), do
system with "cmd" on "dir A:". If the output is "The system cannot find the
path ,specified." (in the current locale (:-)), there is no "A:". Repeat up
to "Z:"... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Adam Beneschan]

On Aug 14, 1:01 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 13 Aug 2009 23:56:03 -0500, Randy Brukardt wrote:
> > "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote in message
> >news:iavqqy3ue6ne$.uxihdofxdalx.dlg@40tude.net...
> > ...
> >> Latin-1 is a limitation that makes impossible to write OS-independent
> >> programs. BTW, I didn't check it but I suppose that the GNAT implementation
> >> is not even Latin-1, it is in fact UTF-8, at least under Linux. So it is
> >> broken twice. Once per design, once by the implementation to fix broken
> >> design.
>
> > Actually, the use of UTF-8 in this way is the recommendation of the ARG. We
> > have no plans of changing any of the file handling routines away from
> > String. We may add some Implementation Advice to make it clear that
> > implementations are advised to support UTF-8 encoded file names.
>
> The problem is 3.5.2 which claims that Character is Latin-1.
>
> (UTF-8 is a problem of its own in Ada. We need a private type with two
> interfaces. One of Wide_Wide_String another of an array of octets. Ada
> cannot provide this.)

I'm not sure I understand just what is being proposed---but if the
idea is that a String type is to be used as an array of UTF-8 octets,
it would definitely be a disappointment.  Abstractly, a String is an
array where each element of the array represents a "character", which
is either one graphic symbol or a control character.  Forcing a String
to represent, basically, an arbitrary sequence of bytes that don't
have any relation to graphic characters, seems like an abomination to
me---the sort of thing a C programmer might do, but that shouldn't be
allowed or encouraged in Ada, and it would sadden me if it were
allowed.  It would be a step toward making Ada "just another
programming language", as Randy put it in another thread.  I think I
could even live with having a routine take an Interfaces.C.char_array
parameter to represent an array of octets.  But not String, please...

                                         -- Adam



>
> >>>> 3. Even so it provides no way to get the name of the root
>
> >>> Because it is OS neutral, and there is no independent concept of a root.
>
> >> An OS-neutral Ada.Directories would provide enumeration of roots. Any
> >> usable Ada.Directories must have the concept of roots nodes.
>
> > Enumeration of roots is impractible on Windows, because every possible file
> > share would have to be included in such a list (including any that don't
> > have permissions to read). That would be impossibly slow, and pretty
> > pointless to boot. It also would cause problems with removable disks
> > (Windows gives a failure if you try to enumerate an empty floppy disk). I've
> > dealt with those headaches from our compiler installer, and I wouldn't want
> > to force them on other users of Ada.
>
> Same to me. But it is required to make Ada.Directories any usable.
>
> Presently I use Exists in a loop through "A".."Z" + "/". That works both
> under Linux and Windows. Do you think that is *better*?! (:-))
>
> > If you can't do it reasonably in Windows, it surely doesn't belong in
> > Ada.Directories.
>
> The MS-explorer does not drop that nasty c0000013 pop up window when
> started. From this I conclude there should be a way to.
>
> Technically, it is certainly possible, for example (a bit exaggerated), do
> system with "cmd" on "dir A:". If the output is "The system cannot find the
> path ,specified." (in the current locale (:-)), there is no "A:". Repeat up
> to "Z:"... (:-))
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1f999bfa99erz$.9b8p6yymr8x7$.dlg@40tude.net...
> On Thu, 13 Aug 2009 23:56:03 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:iavqqy3ue6ne$.uxihdofxdalx.dlg@40tude.net...
>> ...
>>> Latin-1 is a limitation that makes impossible to write OS-independent
>>> programs. BTW, I didn't check it but I suppose that the GNAT 
>>> implementation
>>> is not even Latin-1, it is in fact UTF-8, at least under Linux. So it is
>>> broken twice. Once per design, once by the implementation to fix broken
>>> design.
>>
>> Actually, the use of UTF-8 in this way is the recommendation of the ARG. 
>> We
>> have no plans of changing any of the file handling routines away from
>> String. We may add some Implementation Advice to make it clear that
>> implementations are advised to support UTF-8 encoded file names.
>
> The problem is 3.5.2 which claims that Character is Latin-1.
>
> (UTF-8 is a problem of its own in Ada. We need a private type with two
> interfaces. One of Wide_Wide_String another of an array of octets. Ada
> cannot provide this.)

You mean, "Ada cannot provide this optimally". As far as the ARG is 
concerned, a UTF-8 encoded string is a String. We looked at other options 
and decided they weren't worth the effort.

Indeed, we approved the encoding package at the last ARG meeting, so it is 
in the current working draft of the Ada Standard: 
http://www.adaic.com/standards/1zrm/html/RM-A-4-11.html.

So clearly Ada can do this, just not the way you would like to see it done. 
Not the first time. ;-)

>>>>> 3. Even so it provides no way to get the name of the root
>>>>
>>>> Because it is OS neutral, and there is no independent concept of a 
>>>> root.
>>>
>>> An OS-neutral Ada.Directories would provide enumeration of roots. Any
>>> usable Ada.Directories must have the concept of roots nodes.
>>
>> Enumeration of roots is impractible on Windows, because every possible 
>> file
>> share would have to be included in such a list (including any that don't
>> have permissions to read). That would be impossibly slow, and pretty
>> pointless to boot. It also would cause problems with removable disks
>> (Windows gives a failure if you try to enumerate an empty floppy disk). 
>> I've
>> dealt with those headaches from our compiler installer, and I wouldn't 
>> want
>> to force them on other users of Ada.
>
> Same to me. But it is required to make Ada.Directories any usable.
>
> Presently I use Exists in a loop through "A".."Z" + "/". That works both
> under Linux and Windows. Do you think that is *better*?! (:-))

No, actually it is just wrong! There are many roots in Windows that don't 
have the disk name syntax. "C:\" is surely a root, but so is 
\\Gatekeeper\Weblogs\. You can't enumerate roots in Windows, the only 
program that ought to try is Windows Explorer.

You do need to know if you have a root in hand (so you don't try to 
decompose it). I'm tenatively planning to add an Is_Root function to 
Ada.Directories to handle that need.

>> If you can't do it reasonably in Windows, it surely doesn't belong in
>> Ada.Directories.
>
> The MS-explorer does not drop that nasty c0000013 pop up window when
> started. From this I conclude there should be a way to.
>
> Technically, it is certainly possible, for example (a bit exaggerated), do
> system with "cmd" on "dir A:". If the output is "The system cannot find 
> the
> path ,specified." (in the current locale (:-)), there is no "A:". Repeat 
> up
> to "Z:"... (:-))

That's possible to do, but it can only be done by handling traps. And 
handling traps in the Ada runtime system is a bad idea. Moreover, that does 
nothing about enumerating network shares, which is a whol 'nother kettle of 
fish.

This is simply something you shouldn't do (like comparing file names).

[And, yes, I agree with you that they shouldn't even have "=", but blame 
Ichbiah for making these things Strings. It's 25 years to late to change 
that definition.]

                                      Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Fri, 14 Aug 2009 18:54:40 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1f999bfa99erz$.9b8p6yymr8x7$.dlg@40tude.net...
>> On Thu, 13 Aug 2009 23:56:03 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:iavqqy3ue6ne$.uxihdofxdalx.dlg@40tude.net...
>>> ...
>>>> Latin-1 is a limitation that makes impossible to write OS-independent
>>>> programs. BTW, I didn't check it but I suppose that the GNAT 
>>>> implementation
>>>> is not even Latin-1, it is in fact UTF-8, at least under Linux. So it is
>>>> broken twice. Once per design, once by the implementation to fix broken
>>>> design.
>>>
>>> Actually, the use of UTF-8 in this way is the recommendation of the ARG. 
>>> We
>>> have no plans of changing any of the file handling routines away from
>>> String. We may add some Implementation Advice to make it clear that
>>> implementations are advised to support UTF-8 encoded file names.
>>
>> The problem is 3.5.2 which claims that Character is Latin-1.
>>
>> (UTF-8 is a problem of its own in Ada. We need a private type with two
>> interfaces. One of Wide_Wide_String another of an array of octets. Ada
>> cannot provide this.)
> 
> You mean, "Ada cannot provide this optimally". As far as the ARG is 
> concerned, a UTF-8 encoded string is a String. We looked at other options 
> and decided they weren't worth the effort.

But UTF-8 encoded string is a Wide_Wide_String. The elements of a Unicode
string are code points (Wide_Wide_Character). It is only the representation
which is a string of octets (not Character!). Who should care of
representations in Ada?

> Indeed, we approved the encoding package at the last ARG meeting, so it is 
> in the current working draft of the Ada Standard: 
> http://www.adaic.com/standards/1zrm/html/RM-A-4-11.html.

Shudder, it is C in Ada. Everything is a String... I am using this solution
for years in my strings edit library. It is inherently unsafe. UTF-8 string
must be a separate from String type.

> So clearly Ada can do this, just not the way you would like to see it done. 
> Not the first time. ;-)

Oh, yes! (:-))

>> Presently I use Exists in a loop through "A".."Z" + "/". That works both
>> under Linux and Windows. Do you think that is *better*?! (:-))
> 
> No, actually it is just wrong! There are many roots in Windows that don't 
> have the disk name syntax. "C:\" is surely a root, but so is 
> \\Gatekeeper\Weblogs\. You can't enumerate roots in Windows, the only 
> program that ought to try is Windows Explorer.

Maybe, but these are not "true" roots of the file system.

> You do need to know if you have a root in hand (so you don't try to 
> decompose it). I'm tenatively planning to add an Is_Root function to 
> Ada.Directories to handle that need.

Yes, this is a problem. Presently I am using a wild mixture of Glib and
Ada.Directories to get the functionality I need. Is_Root is among that.

Probably I will drop Ada.Directories altogether because of its useless. The
only thing that holds me is that Glib's volume monitor

   http://library.gnome.org/devel/gio/unstable/GVolumeMonitor.html

does not work either.

>>> If you can't do it reasonably in Windows, it surely doesn't belong in
>>> Ada.Directories.
>>
>> The MS-explorer does not drop that nasty c0000013 pop up window when
>> started. From this I conclude there should be a way to.
>>
>> Technically, it is certainly possible, for example (a bit exaggerated), do
>> system with "cmd" on "dir A:". If the output is "The system cannot find 
>> the path ,specified." (in the current locale (:-)), there is no "A:". Repeat 
>> up to "Z:"... (:-))
> 
> That's possible to do, but it can only be done by handling traps. And 
> handling traps in the Ada runtime system is a bad idea. Moreover, that does 
> nothing about enumerating network shares, which is a whol 'nother kettle of 
> fish.
> 
> This is simply something you shouldn't do (like comparing file names).

and like Ada.Directories...

If Ada.Directories is provided it must be specified as a useful package.
Its implementation under Windows or Unix (of which file system is no less
broken) is not a matter of concern. I see no problem with traps or even Ada
RTL starting processes and system services, if Ada.Directories has been
used by the executable. If it comes with this price I buy it. What I do not
buy is writing OS-dependent code myself.

> [And, yes, I agree with you that they shouldn't even have "=", but blame 
> Ichbiah for making these things Strings. It's 25 years to late to change 
> that definition.]

No need to change, just overload it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Pascal Obry]

Le 15/08/2009 10:10, Dmitry A. Kazakov a �crit :
> Shudder, it is C in Ada. Everything is a String... I am using this solution
> for years in my strings edit library. It is inherently unsafe. UTF-8 string
> must be a separate from String type.

I have sympathy with Dmitry. As one who have worked on the UTF-8 support 
for GNAT on Windows I can tell you that it is pure mess to get something 
working fine. The harder part is to ensure that no multiple conversions 
are done.

Now I'm not sure UTF-8 is what should be supported anyway. Windows offer 
either the plain ASCII (A suffix) or wide (W suffix) version of all 
services dealing with file names. So for the Windows case it would be 
far more efficient to have OS services based on Wide_String (an 
Ada.Wide_Directories for example).

What seems wrong to me is that we have Wide_Text_IO but file names are 
plain string! I don't see why this is so, it would have been better to 
use a Wide_String. Given that Wide_Text_IO is recent I think it would 
even be good to "fix" that in the next release. I understand that 
Wide_Text_IO is dealing with Wide_Character in the content of the 
file... but it would even be better to also handle name of the file as 
Wide_String. It is always possible to convert between string and 
wide_string anyway.

I may be missing something... but as an implementor and user I find this 
just broken.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Sat, 15 Aug 2009 14:49:26 +0200, Pascal Obry wrote:

> Now I'm not sure UTF-8 is what should be supported anyway. Windows offer 
> either the plain ASCII (A suffix) or wide (W suffix) version of all 
> services dealing with file names. So for the Windows case it would be 
> far more efficient to have OS services based on Wide_String (an 
> Ada.Wide_Directories for example).

Windows "W" is no more Wide_String (UCS-2), they switched it to UTF-16.
Microsoft is perfect in choosing the worst possible solution. (:-)) Anyway,
this is another reason why we should never use String for file names.

File name should be of a private type, which can be composted from strings
of either type, OS-independently, or converted to a string type using an
equivalent of the attribute Image.

> I may be missing something... but as an implementor and user I find this 
> just broken.

Wide_String has no advantage as it must be UTF-16. If we persist on keeping
it broken, then String as UTF-8 is obviously better than Wide_String as
UTF-16. It is native to Linux. Under Windows you would have to recode it
into UTF-16 and call to a "W" API. If upon recoding you see that the thing
is 7-bit,you could call to "A" without recoding.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Pascal Obry]

Le 15/08/2009 15:23, Dmitry A. Kazakov a �crit :
> Wide_String has no advantage as it must be UTF-16. If we persist on keeping

At least when you use FindFirstFileW() on Windows the resulting filename 
can be safely stored into a Wide_String. It just cannot on a standard 
String. Not perfect but far better than what is possible with current API.

> it broken, then String as UTF-8 is obviously better than Wide_String as
> UTF-16. It is native to Linux. Under Windows you would have to recode it
> into UTF-16 and call to a "W" API. If upon recoding you see that the thing
> is 7-bit,you could call to "A" without recoding.

But I agree a better approach would be to use a proper private type to 
store filenames. This seems quite delicate to fix in Ada at this point.

I do think changing Wide_Text_IO and Wide_Wide_Text_IO to use 
Wide_String and Wide_Wide_String respectively is a possible option even 
if not upward compatible.

We could at least add another set of API dealing with file names to 
support Wide_String and Wide_Wide_String. This last solution is upward 
compatible.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Sat, 15 Aug 2009 17:11:49 +0200, Pascal Obry wrote:

> Le 15/08/2009 15:23, Dmitry A. Kazakov a �crit :

>> Wide_String has no advantage as it must be UTF-16. If we persist on keeping
> 
> At least when you use FindFirstFileW() on Windows the resulting filename 
> can be safely stored into a Wide_String. It just cannot on a standard 
> String.

Hmm, Why? You could store it in String the same way you do in Wide_String.
Neither result is a string in terms of Ada standard. 

The only Ada string which can be used with "W" APIs is Wide_Wide_String.
This requires recoding to UTF-16 and back.

I see nothing to lose if we introduced a private type. Moreover it is a
performance gain. Using a String type you always forced to convert it to a
C string, recode it, etc. A private type could have just the representation
required by the OS.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Pascal Obry]

Le 15/08/2009 19:11, Dmitry A. Kazakov a �crit :
> The only Ada string which can be used with "W" APIs is Wide_Wide_String.
> This requires recoding to UTF-16 and back.

No, a wide character on Windows is 16 bits. This can be stored in 
Wide_String.

> I see nothing to lose if we introduced a private type. Moreover it is a
> performance gain. Using a String type you always forced to convert it to a
> C string, recode it, etc. A private type could have just the representation
> required by the OS.

How can this be made upward compatible?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Sat, 15 Aug 2009 22:07:01 +0200, Pascal Obry wrote:

> Le 15/08/2009 19:11, Dmitry A. Kazakov a �crit :

>> The only Ada string which can be used with "W" APIs is Wide_Wide_String.
>> This requires recoding to UTF-16 and back.
> 
> No, a wide character on Windows is 16 bits. This can be stored in 
> Wide_String.

In the same sense as it can be stored in a Storage_Array or a String.

Semantically, even ignoring potential issue of byte ordering, some values
of Wide_Character are illegal in "W" APIs and conversely UTF-16 strings
with surrogate pairs cannot be represented as Wide_String.

http://msdn.microsoft.com/en-us/library/dd374081(VS.85).aspx

>> I see nothing to lose if we introduced a private type. Moreover it is a
>> performance gain. Using a String type you always forced to convert it to a
>> C string, recode it, etc. A private type could have just the representation
>> required by the OS.
> 
> How can this be made upward compatible?

Where is any problem? You add new packages or else overload some procedures
in the old ones. I never understood why people are talking about
compatibility problem regarding *libraries*...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:cbxuxz06dr5r$.9zo0supfl50x.dlg@40tude.net...
> On Fri, 14 Aug 2009 18:54:40 -0500, Randy Brukardt wrote:
...
>> You mean, "Ada cannot provide this optimally". As far as the ARG is
>> concerned, a UTF-8 encoded string is a String. We looked at other options
>> and decided they weren't worth the effort.
>
> But UTF-8 encoded string is a Wide_Wide_String. The elements of a Unicode
> string are code points (Wide_Wide_Character). It is only the 
> representation
> which is a string of octets (not Character!). Who should care of
> representations in Ada?

If course you care of representations. A Wide_Wide_String takes 4 times as 
much space as a UTF-8 encoded string, which can be a severe performance 
drag. And if you *don't* care about representation, then just store 
everything as Wide_Wide_String and do not worry about the representation at 
all.

For Ada purposes, UTF-8 is a storage format, not an operation format. You 
manipulate a Wide_Wide_Character string, then convert to/from UTF-8 for 
storage only.

...
>> No, actually it is just wrong! There are many roots in Windows that don't
>> have the disk name syntax. "C:\" is surely a root, but so is
>> \\Gatekeeper\Weblogs\. You can't enumerate roots in Windows, the only
>> program that ought to try is Windows Explorer.
>
> Maybe, but these are not "true" roots of the file system.

What is a "true" root? There are only file names which form roots (that is, 
cannot be decomposed further and still give a file or directory). It doesn't 
matter where the storage is or what the technology is.

...
> If Ada.Directories is provided it must be specified as a useful package.
> Its implementation under Windows or Unix (of which file system is no less
> broken) is not a matter of concern. I see no problem with traps or even 
> Ada
> RTL starting processes and system services, if Ada.Directories has been
> used by the executable. If it comes with this price I buy it. What I do 
> not
> buy is writing OS-dependent code myself.

I agree, but the problem is that you are asking to write code that you ought 
not even be writing for Windows (and probably not for Unix as well). Ada 
shouldn't be in the business of encouraging you to write stupid code.

>> [And, yes, I agree with you that they shouldn't even have "=", but blame
>> Ichbiah for making these things Strings. It's 25 years to late to change
>> that definition.]
>
> No need to change, just overload it.

Can't overload "=" for type String, as it is in Standard and the predefined 
one is always visible. Any overloaded one would (almost) never be visible 
(use visibility has lower priority than things in Standard).

The problem here is that String really is not the right type, but since you 
can't have string literals for private types in Ada, you can't make it a 
private type. (And if you could have string literals, it still couldn't be 
used with the existing I/O packages, it would be way too incompatible.)

                                                     Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Adam Beneschan]

On Aug 17, 3:28 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> The problem here is that String really is not the right type, but since you
> can't have string literals for private types in Ada, you can't make it a
> private type. (And if you could have string literals, it still couldn't be
> used with the existing I/O packages, it would be way too incompatible.)

That wouldn't even be an issue if UTF-8 were strictly a "storage
format" as you called it above.  If that were the case, you wouldn't
need string literals for it.  I think the problem is that UTF-8 is
something of a hybrid.  If all characters in the string are in the
32..126 range, the "sequence of octets" stored in the UTF-8 string is
identical to the graphic characters stored in a String.  (UTF-8 was
designed purposefully so that would happen.)  In cases like that, it
makes sense to use a string literal.

I can understand how "hybrid" types like that can cause headaches for
fans of strong typing.  A "String" should be an array of graphic or
control characters; an encoded type should be a sequence of octets;
but here we need a type that is sometimes one thing and sometimes
another.  So I can respect the decision to make these String types,
but I don't like it.

Also, I'm afraid that using String can backfire.  If I understand it
correctly, the decision was that the Name parameter of Text_IO.Open
should be interpreted as a UTF-8 octet sequence even though it's a
String.  But the intent is to allow string literals.  At some point,
though, some poor innocent programmer in Germany or Spain is going to
try to use a string literal (or a Latin-1 string variable) with an
umlaut or an accented vowel in it and get totally screwed up since
those characters don't represent themselves in UTF-8 encoding, and
they'll end up puzzling over how their program created a file with a
Chinese character in the middle of the name.  (Yeah, I know, that's
very unlikely; most likely the UTF-8 encoding will simply be invalid.)

                                              -- Adam

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:6f80c882-fa03-4ca9-a53e-fae34cea160d@b15g2000yqd.googlegroups.com...
On Aug 17, 3:28 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

>> The problem here is that String really is not the right type, but since 
>> you
>> can't have string literals for private types in Ada, you can't make it a
>> private type. (And if you could have string literals, it still couldn't 
>> be
>> used with the existing I/O packages, it would be way too incompatible.)
>
>That wouldn't even be an issue if UTF-8 were strictly a "storage
>format" as you called it above.  If that were the case, you wouldn't
>need string literals for it.  I think the problem is that UTF-8 is
>something of a hybrid.  If all characters in the string are in the
>32..126 range, the "sequence of octets" stored in the UTF-8 string is
>identical to the graphic characters stored in a String.  (UTF-8 was
>designed purposefully so that would happen.)  In cases like that, it
>makes sense to use a string literal.

Well, the problem here is that it *always* makes sense to use a string 
literal. That's how you specify what you want in storage in Ada.

I think Dmitry's point is that he'd rather always see explicit conversions. 
The problem is that they don't work well -- exhibit A is unbounded strings. 
That's especially true for the use-adverse like me. I hate having to write:

    A_Str := Ada.Strings.Unbounded.To_Unbounded_String ("ABC");

and surely UTF8 would be worse:

   A_Str := Ada.Strings.Unbounded_UTF_8.To_Unbounded_UTF_8_String ("ABC");

..
>Also, I'm afraid that using String can backfire.  If I understand it
>correctly, the decision was that the Name parameter of Text_IO.Open
>should be interpreted as a UTF-8 octet sequence even though it's a
>String.  But the intent is to allow string literals.  At some point,
>though, some poor innocent programmer in Germany or Spain is going to
>try to use a string literal (or a Latin-1 string variable) with an
>umlaut or an accented vowel in it and get totally screwed up since
>those characters don't represent themselves in UTF-8 encoding, and
>they'll end up puzzling over how their program created a file with a
>Chinese character in the middle of the name.  (Yeah, I know, that's
>very unlikely; most likely the UTF-8 encoding will simply be invalid.)

I've been presuming that UTF-8 encoding started with a BOM or something like 
that, else you couldn't tell it from regular Latin-1 encoding. It would be 
hard to insert a BOM into a string literal by accident!

But I do agree that this issue needs some discussion.

(Also note that a major reason for this package is to make ASIS work; there 
[as with I/O], we're stuck with existing routines that return Wide_Strings 
that are not enough to handle all possible text.)

                                        Randy.

                                              -- Adam 

Re: Interpretation of extensions different from Unix/Linux?

[stefan-lucks]

> I think Dmitry's point is that he'd rather always see explicit conversions. 
> The problem is that they don't work well -- exhibit A is unbounded strings. 
> That's especially true for the use-adverse like me. [...]

How about "use type"?

Then call an appropriately defined operator, such as the unary "+" or 
the binary "&":

>    A_Str := Ada.Strings.Unbounded_UTF_8.To_Unbounded_UTF_8_String ("ABC");

     A_Str := +"ABC";

or 

    A_Str := "" & "ABC";


-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

<stefan-lucks@see-the.signature> wrote in message 
news:Pine.LNX.4.64.0908190604510.3835@medsec1.medien.uni-weimar.de...
>> I think Dmitry's point is that he'd rather always see explicit 
>> conversions.
>> The problem is that they don't work well -- exhibit A is unbounded 
>> strings.
>> That's especially true for the use-adverse like me. [...]
>
> How about "use type"?
>
> Then call an appropriately defined operator, such as the unary "+" or
> the binary "&":

We tried to add a unary "+" for this purpose in Ada 2005, but there are 
enough people who think the idea is "ugly" to prevent a consensus. 
Similarly, there was a proposal way back in the Ada 83 days to add a an 
operator "@" specifically for this conversion purpose, but there hasn't been 
enough support for that, either. (In part, because some people claim that is 
the purpose of "+"! Great way to get to an impass!) I'd be happy with 
either, but I don't think there is much chance of either happening in the 
near future.

                                            Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Jean-Pierre Rosen]

Randy Brukardt a �crit :
> But I do agree that this issue needs some discussion.
> 
> (Also note that a major reason for this package is to make ASIS work; there 
> [as with I/O], we're stuck with existing routines that return Wide_Strings 
> that are not enough to handle all possible text.)
> 
Sure, in the abstract, code points are not characters. Note that they
are not in the proposed AI either: the wording is careful to talk of
"characters whose position value is the code point". But another reason
to use strings is to not make things too complicated for the casual
user. By making a UTF8 type different from String, we would please Ada
purist, and once again send the message to the rest of the world that
Ada manages to turn things that are so simple in other languages into
horrible complications. We don't need that.
-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Interpretation of extensions different from Unix/Linux?

[Adam Beneschan]

On Aug 18, 1:48 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Adam Beneschan" <a...@irvine.com> wrote in message
>
> news:6f80c882-fa03-4ca9-a53e-fae34cea160d@b15g2000yqd.googlegroups.com...
> On Aug 17, 3:28 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> >> The problem here is that String really is not the right type, but since
> >> you
> >> can't have string literals for private types in Ada, you can't make it a
> >> private type. (And if you could have string literals, it still couldn't
> >> be
> >> used with the existing I/O packages, it would be way too incompatible.)
>
> >That wouldn't even be an issue if UTF-8 were strictly a "storage
> >format" as you called it above.  If that were the case, you wouldn't
> >need string literals for it.  I think the problem is that UTF-8 is
> >something of a hybrid.  If all characters in the string are in the
> >32..126 range, the "sequence of octets" stored in the UTF-8 string is
> >identical to the graphic characters stored in a String.  (UTF-8 was
> >designed purposefully so that would happen.)  In cases like that, it
> >makes sense to use a string literal.
>
> Well, the problem here is that it *always* makes sense to use a string
> literal. That's how you specify what you want in storage in Ada.

We might be talking about two different things.  If I had a type whose
purpose was to represent the storage of a string in Huffman code, it
wouldn't make sense to specify its value with a string literal,
because the octets in that storage wouldn't have any direct
relationship with any meaningful graphic characters.  So specifying
the value of such a type with a string literal wouldn't make sense,
except via a conversion routine of some sort.  UTF-8 is different
because in many cases the octets being stored *do* have a direct
relationship with the graphic characters.  That's what I was trying to
get at.  But it's possible that I've lost the plot.


> >Also, I'm afraid that using String can backfire.  If I understand it
> >correctly, the decision was that the Name parameter of Text_IO.Open
> >should be interpreted as a UTF-8 octet sequence even though it's a
> >String.  But the intent is to allow string literals.  At some point,
> >though, some poor innocent programmer in Germany or Spain is going to
> >try to use a string literal (or a Latin-1 string variable) with an
> >umlaut or an accented vowel in it and get totally screwed up since
> >those characters don't represent themselves in UTF-8 encoding, and
> >they'll end up puzzling over how their program created a file with a
> >Chinese character in the middle of the name.  (Yeah, I know, that's
> >very unlikely; most likely the UTF-8 encoding will simply be invalid.)
>
> I've been presuming that UTF-8 encoding started with a BOM or something like
> that, else you couldn't tell it from regular Latin-1 encoding. It would be
> hard to insert a BOM into a string literal by accident!
>
> But I do agree that this issue needs some discussion.

My understanding, which could be wrong, was that the UTF-8 standard
specified how to encode a single "character" (from the entire set of
almost 2**32 possibilities) as a sequence of 8-bit octets.  I wasn't
aware that the standard also said anything about special octet
sequences that precede the encoding of a character *sequence*.  Maybe
it does; I'll have to go back and look.

I don't have a lot of experience working with UTF-8 encoded files (on
Windows, say) to know how they're stored or how applications
distinguish the encodings.  In mail messages, though, I sometimes see
contents and attachments that are encoded in UTF-8, and some that are
encoded in Latin-1.  (My mail reader is pretty primitive so I can get
a good look at exactly how the message is encoded.)  In the UTF-8
messages, I don't see any special characters or anything at the
beginning of the contents; in that case, I think it's information in
the mail message headers that tells the application whether to
interpret the string as encoded in UTF-8 or Latin-1.

... OK, after a bit of research, it looks as though the use of BOM to
distinguish UTF-8 from other encodings isn't part of an official
"standard", but it's widely used by Windows applications.  But I also
note that in the Wikipedia entry for "byte-order mark", they recommend
*against* this practice on Unix-type systems (for example, if a shell
script were stored in this manner, the first character would no longer
be recognized as '!' by utilities that checked for shell scripts).  I
don't know whether this advice is obsolete or not.  Anyway, perhaps
this means that the UTF_Encoding package shouldn't assume the use of
BOM to distinguish UTF-8-encoded strings, but perhaps the routines
there should provide an optional parameter to specify what
"protocol" (if any) is used to distinguish between encodings (a
protocol of None would mean that we assume the calling program knows
by some other means what kind of encoding is being used, and the
UTF_Encoding package just converts single characters according to the
standard without worrying about any kind of header sequence).

                                        -- Adam

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:b3995dcd-11bd-4101-94b7-0d154c0ad47d@l35g2000pra.googlegroups.com...
On Aug 18, 1:48 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
...
>> Well, the problem here is that it *always* makes sense to use a string
>> literal. That's how you specify what you want in storage in Ada.
>
>We might be talking about two different things.  If I had a type whose
>purpose was to represent the storage of a string in Huffman code, it
>wouldn't make sense to specify its value with a string literal,
>because the octets in that storage wouldn't have any direct
>relationship with any meaningful graphic characters.  So specifying
>the value of such a type with a string literal wouldn't make sense,
>except via a conversion routine of some sort.

IMHO, there is *always* a conversion routine of some sort. Surely "ABC" has 
no direct relationship to the three bytes that are actually stored in memory 
for type String. Similarly for numeric literals. It is just a shorthand for 
a a number of encodings (keep in mind that the form of a string literal is 
the same for String, Wide_String, and for Wide_Wide_String). I don't see any 
reason that it can't be a shorthand for some other encoding as well.
>... OK, after a bit of research, it looks as though the use of BOM to
>distinguish UTF-8 from other encodings isn't part of an official
>"standard", but it's widely used by Windows applications.
...
> Anyway, perhaps this means that the UTF_Encoding package shouldn't
> assume the use of BOM to distinguish UTF-8-encoded strings, but perhaps
> the routines there should provide an optional parameter to specify what
> "protocol" (if any) is used to distinguish between encodings (a protocol 
> of
> None would mean that we assume the calling program knows
> by some other means what kind of encoding is being used, and the
> UTF_Encoding package just converts single characters according to the
> standard without worrying about any kind of header sequence).

Or you could have just read AI05-0137-1 and/or clause A.4.11 in the latest 
RM draft to see what is proposed and why. ;-) [Modulo the stupid missing 
"not" in A.4.11(20/3), which will be fixed next time, of course.] All of the 
issues with the BOM already have been considered and dealt with.

My comment was specifically in relation to using UTF-8 in file names in the 
standard I/O packages, and is not related to anything else (as that is 
already covered by the proposal and by common practice).

                                        Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Mon, 17 Aug 2009 17:28:44 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:cbxuxz06dr5r$.9zo0supfl50x.dlg@40tude.net...
>> On Fri, 14 Aug 2009 18:54:40 -0500, Randy Brukardt wrote:
> ...
>>> You mean, "Ada cannot provide this optimally". As far as the ARG is
>>> concerned, a UTF-8 encoded string is a String. We looked at other options
>>> and decided they weren't worth the effort.
>>
>> But UTF-8 encoded string is a Wide_Wide_String. The elements of a Unicode
>> string are code points (Wide_Wide_Character). It is only the 
>> representation
>> which is a string of octets (not Character!). Who should care of
>> representations in Ada?
> 
> If course you care of representations. A Wide_Wide_String takes 4 times as 
> much space as a UTF-8 encoded string, which can be a severe performance 
> drag. And if you *don't* care about representation, then just store 
> everything as Wide_Wide_String and do not worry about the representation at 
> all.

Wide_Wide_String is an interface of UTF-8 string. It is *not* its
representation. Consider it in not-Ada:

   type Wide_Wide_String is interface
      array (Positive range <>) of Wide_Wide_Character;

   type Octet_No is range 1..<implementation_defined>;
   type Octet is mod 2**8:
   type UTF8_String is new Wide_Wide_String with
      array (Octet_No range <>) of Octet;

> For Ada purposes, UTF-8 is a storage format, not an operation format. You 
> manipulate a Wide_Wide_Character string, then convert to/from UTF-8 for 
> storage only.

You manipulate it as Wide_Wide_String without conversions. The only serious
problem is that replacing a character in UTF8_String might change its
"octet" bounds and converse changing octets may change "character" bounds.

>> Maybe, but these are not "true" roots of the file system.
> 
> What is a "true" root? There are only file names which form roots (that is, 
> cannot be decomposed further and still give a file or directory). It doesn't 
> matter where the storage is or what the technology is.

"Untrue" roots are those Windows itself does not understand. There is a
large percentage of Windows programs that do not handle file names with
\\-stuff.

>> If Ada.Directories is provided it must be specified as a useful package.
>> Its implementation under Windows or Unix (of which file system is no less
>> broken) is not a matter of concern. I see no problem with traps or even Ada
>> RTL starting processes and system services, if Ada.Directories has been
>> used by the executable. If it comes with this price I buy it. What I do not
>> buy is writing OS-dependent code myself.
> 
> I agree, but the problem is that you are asking to write code that you ought 
> not even be writing for Windows (and probably not for Unix as well). Ada 
> shouldn't be in the business of encouraging you to write stupid code.

Sorry, but writing a file browser is not stupid. Consider implementation of
a GUI open-file dialog using Ada.Directories.

>>> [And, yes, I agree with you that they shouldn't even have "=", but blame
>>> Ichbiah for making these things Strings. It's 25 years to late to change
>>> that definition.]
>>
>> No need to change, just overload it.
> 
> Can't overload "=" for type String, as it is in Standard and the predefined 
> one is always visible. Any overloaded one would (almost) never be visible 
> (use visibility has lower priority than things in Standard).

It is not a String, it is a private type like Directory_Entry. You have to
overload Open, Create, Delete and Rename. That is.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1d0e8zv4oco66$.1qqitij5kmc4w$.dlg@40tude.net...
> On Mon, 17 Aug 2009 17:28:44 -0500, Randy Brukardt wrote:
...
> You manipulate it as Wide_Wide_String without conversions. The only 
> serious
> problem is that replacing a character in UTF8_String might change its
> "octet" bounds and converse changing octets may change "character" bounds.

I think that would be prohibitively expensive in both time and space. (If 
you don't care about time and space, then there is no reason to use UTF-8 or 
UTF-16 in the first place.)

>>> Maybe, but these are not "true" roots of the file system.
>>
>> What is a "true" root? There are only file names which form roots (that 
>> is,
>> cannot be decomposed further and still give a file or directory). It 
>> doesn't
>> matter where the storage is or what the technology is.
>
> "Untrue" roots are those Windows itself does not understand. There is a
> large percentage of Windows programs that do not handle file names with
> \\-stuff.

Windows surely does recognize UNC names natively - surely the file open 
does. So by your definition these are "true" roots. There of course is a lot 
of crappy software out there that doesn't allow them, but what does that 
have to do with Ada?? Software that supports text file names but doesn't 
support UNC names is broken, IMHO.

>>> If Ada.Directories is provided it must be specified as a useful package.
>>> Its implementation under Windows or Unix (of which file system is no 
>>> less
>>> broken) is not a matter of concern. I see no problem with traps or even 
>>> Ada
>>> RTL starting processes and system services, if Ada.Directories has been
>>> used by the executable. If it comes with this price I buy it. What I do 
>>> not
>>> buy is writing OS-dependent code myself.
>>
>> I agree, but the problem is that you are asking to write code that you 
>> ought
>> not even be writing for Windows (and probably not for Unix as well). Ada
>> shouldn't be in the business of encouraging you to write stupid code.
>
> Sorry, but writing a file browser is not stupid. Consider implementation 
> of
> a GUI open-file dialog using Ada.Directories.

That is *exactly* what I mean. Any "proper" Windows program will use the 
built-in file browser, not create some less-powerful version on their own. 
(Indeed, this was one of the primary reasons we created Claw.) Any decent 
GUI will have a way to do that (and if it is portable, will have to provide 
similar functionality on other systems). That's way outside of Ada's sphere.

>>>> [And, yes, I agree with you that they shouldn't even have "=", but 
>>>> blame
>>>> Ichbiah for making these things Strings. It's 25 years to late to 
>>>> change
>>>> that definition.]
>>>
>>> No need to change, just overload it.
>>
>> Can't overload "=" for type String, as it is in Standard and the 
>> predefined
>> one is always visible. Any overloaded one would (almost) never be visible
>> (use visibility has lower priority than things in Standard).
>
> It is not a String, it is a private type like Directory_Entry. You have to
> overload Open, Create, Delete and Rename. That is.

That's going to be ambiguous if you have proper string literals and very 
hard to use if you don't. We created a package like that for use within the 
Janus/Ada toolset, and using it is very complicated -- it takes many lines 
of code to do anything - no matter how simple. I don't think anyone would 
use such a contraption.

                                       Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Tue, 18 Aug 2009 15:37:39 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1d0e8zv4oco66$.1qqitij5kmc4w$.dlg@40tude.net...
>> On Mon, 17 Aug 2009 17:28:44 -0500, Randy Brukardt wrote:
> ...
>> You manipulate it as Wide_Wide_String without conversions. The only serious
>> problem is that replacing a character in UTF8_String might change its
>> "octet" bounds and converse changing octets may change "character" bounds.
> 
> I think that would be prohibitively expensive in both time and space.

Absolutely not. Again, Wide_Wide_String is not an implementation of
UTF8_String, it is merely an interface. The implementation of UTF8_String
stays an array of octets. Except for indexing which is rarely used with
UTF8_String other operations of Wide_Wide_String can be delegated to the
representation's operations. No overhead.

>>>> Maybe, but these are not "true" roots of the file system.
>>>
>>> What is a "true" root? There are only file names which form roots (that 
>>> is,
>>> cannot be decomposed further and still give a file or directory). It 
>>> doesn't
>>> matter where the storage is or what the technology is.
>>
>> "Untrue" roots are those Windows itself does not understand. There is a
>> large percentage of Windows programs that do not handle file names with
>> \\-stuff.
> 
> Windows surely does recognize UNC names natively - surely the file open 
> does. So by your definition these are "true" roots. There of course is a lot 
> of crappy software out there that doesn't allow them,

It is not crappy, it is backward compatible. All this software uses *legal*
Windows API, and it is the API functions (16-bit or whatever) which fail to
handle fake \\nodes, useless stuff like "My Documents", "Desktop" etc. This
rubbish has nothing to do with the file system. It could be supported, no
question, but no portable program will probably ever use it. So why should
we care?

> but what does that 
> have to do with Ada?? Software that supports text file names but doesn't 
> support UNC names is broken, IMHO.

Nope. The design rule I propose is, any local file has to be accessible
through at least one root determinable by Ada.Directories. The rest is up
to the implementor's good will. This is certainly doable in any operating
system I know.

>>>> If Ada.Directories is provided it must be specified as a useful package.
>>>> Its implementation under Windows or Unix (of which file system is no less
>>>> broken) is not a matter of concern. I see no problem with traps or even Ada
>>>> RTL starting processes and system services, if Ada.Directories has been
>>>> used by the executable. If it comes with this price I buy it. What I do not
>>>> buy is writing OS-dependent code myself.
>>>
>>> I agree, but the problem is that you are asking to write code that you ought
>>> not even be writing for Windows (and probably not for Unix as well). Ada
>>> shouldn't be in the business of encouraging you to write stupid code.
>>
>> Sorry, but writing a file browser is not stupid. Consider implementation 
>> of a GUI open-file dialog using Ada.Directories.
> 
> That is *exactly* what I mean. Any "proper" Windows program will use the 
> built-in file browser, not create some less-powerful version on their own.

No. First there are two (maybe three) of them under Windows. Both
(especially the newer one) are quite unusable. The older was extensible so
that you could add buttons and other stuff *required* by a "proper"
applications like mine. (:-)) Under Linux the situation is much worse than
that. So I have my own set of file selection widgets, BTW, docked widgets,
not dialog boxes.
 
>>>>> [And, yes, I agree with you that they shouldn't even have "=", but blame
>>>>> Ichbiah for making these things Strings. It's 25 years to late to change
>>>>> that definition.]
>>>>
>>>> No need to change, just overload it.
>>>
>>> Can't overload "=" for type String, as it is in Standard and the 
>>> predefined
>>> one is always visible. Any overloaded one would (almost) never be visible
>>> (use visibility has lower priority than things in Standard).
>>
>> It is not a String, it is a private type like Directory_Entry. You have to
>> overload Open, Create, Delete and Rename. That is.
> 
> That's going to be ambiguous if you have proper string literals and very 
> hard to use if you don't.

It will not:

   Open (File, In_File, "C:", ("temp", "tests"), "test20", "txt");

instead of

   Open (File, In_File, "C:\temp\tests\test20.txt");

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Tue, 18 Aug 2009 15:37:39 -0500, Randy Brukardt wrote:
> 

>>  Any "proper" Windows program will use the 
>> built-in file browser, not create some less-powerful version on their own.
> 
> No. First there are two (maybe three) of them under Windows. Both
> (especially the newer one) are quite unusable. The older was extensible so
> that you could add buttons and other stuff *required* by a "proper"
> applications like mine. (:-)) Under Linux the situation is much worse than
> that. So I have my own set of file selection widgets, BTW, docked widgets,
> not dialog boxes.

The File dialogue mess could have been addressed by getting rid
of stupid File dialogues in the first place: Instead, drag
a file from a GUI onto your program (or have a GUI folder appear
in your program and drag from there.)

Some OS/2 programs such as editors even had a title bar
icon for dragging the file to some destination folder
of choice. This would work in the opposite direction, then.

A generalized user call back of sorts.

However, using a GUI's facilities would mean five minutes of
learning a GUI concept new to some...  Shudder.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Wed, 19 Aug 2009 12:32:04 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
>> On Tue, 18 Aug 2009 15:37:39 -0500, Randy Brukardt wrote: 
> 
>>>  Any "proper" Windows program will use the 
>>> built-in file browser, not create some less-powerful version on their own.
>> 
>> No. First there are two (maybe three) of them under Windows. Both
>> (especially the newer one) are quite unusable. The older was extensible so
>> that you could add buttons and other stuff *required* by a "proper"
>> applications like mine. (:-)) Under Linux the situation is much worse than
>> that. So I have my own set of file selection widgets, BTW, docked widgets,
>> not dialog boxes.
> 
> The File dialogue mess could have been addressed by getting rid
> of stupid File dialogues in the first place: Instead, drag
> a file from a GUI onto your program (or have a GUI folder appear
> in your program and drag from there.)

I just show a tree directory view and a file view panes on a docked panel.
The user clicks a file and it appears in an external edit box. This kind of
interface requires communication between file browser and other widgets.

> Some OS/2 programs such as editors even had a title bar
> icon for dragging the file to some destination folder
> of choice. This would work in the opposite direction, then.

Sun's Open Look under Solaris used this concept too (before OS/2?).

But I dislike d'n'd, it is not very handy on a desktop PC, but in the times
of notebooks, I doubt anybody would miss it.

Modern interfaces are kind of "OO".  Older interfaces, like d'n'd, were
"functional": you had a function first (the text editor window open) and
then you chose arguments for it, by dropping objects into it. "OO" GUI
first selects an object. Only then the you choose the operation, like
"open" in the popup menu. That opens a corresponding application, which is
not necessarily a text editor. There are too many applications and their
functional parts in these days to have all them active and visible on the
desktop.

> A generalized user call back of sorts.
> 
> However, using a GUI's facilities would mean five minutes of
> learning a GUI concept new to some...  Shudder.

I am using the look and feel of Windows file browser,

   http://www.dmitry-kazakov.de/ada/gtkada_contributions.htm#2.9

Everybody knows what it is, genetically imprinted.... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

> Modern interfaces are kind of "OO".  Older interfaces, like d'n'd, were
> "functional": you had a function first (the text editor window open) and
> then you chose arguments for it, by dropping objects into it. "OO" GUI
> first selects an object. Only then the you choose the operation, like
> "open" in the popup menu. That opens a corresponding application, which is
> not necessarily a text editor. There are too many applications and their
> functional parts in these days to have all them active and visible on the
> desktop.

A context would be the important and user centric notion, I think.
Click on a file---is the file a component in an O-O sense,
what should the click trigger, etc.  Several options that can
be controlled by the context. Maybe the context will establish
a priority list of programs/services that can deal with this
particular file object. D'n'd is not the essential piece:
file dialogue windows are another opportunity to foster
contracts about the ongoing support of ever changing file
selection machanisms ... ;-)

A good search box helps me a lot when finding files.  Lucene
is a good, free, quick, and known-format indexing library
for file system names.


> Everybody knows what it is, genetically imprinted.... (:-))

(I mean, could anything be worse than the preconfigured
auto-wiggling of narrowly boxed tree views in Vista's "explorer"?
Psycho MS salesmanship... We are open to removing our innovations
when users don't like them. Comes with the next release.)

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:tww2guh98m4j.vbxz4nv412g1.dlg@40tude.net...
> On Tue, 18 Aug 2009 15:37:39 -0500, Randy Brukardt wrote:
...
>> I think that would be prohibitively expensive in both time and space.
>
> Absolutely not. Again, Wide_Wide_String is not an implementation of
> UTF8_String, it is merely an interface. The implementation of UTF8_String
> stays an array of octets. Except for indexing which is rarely used with
> UTF8_String other operations of Wide_Wide_String can be delegated to the
> representation's operations. No overhead.

Indexing (and slicing) are pretty much the *only* operations that you do on 
a String. If they are very expensive, the entire implementation will be very 
expensive (especially as operations like "&" are already very expensive).

 ...
>> Windows surely does recognize UNC names natively - surely the file open
>> does. So by your definition these are "true" roots. There of course is a 
>> lot
>> of crappy software out there that doesn't allow them,
>
> It is not crappy, it is backward compatible. All this software uses 
> *legal*
> Windows API, and it is the API functions (16-bit or whatever) which fail 
> to
> handle fake \\nodes, useless stuff like "My Documents", "Desktop" etc. 
> This
> rubbish has nothing to do with the file system. It could be supported, no
> question, but no portable program will probably ever use it. So why should
> we care?

I have no idea what you are talking about. Every 32-bit API supports UNC 
names, and always has (at least as far back as Windows 95). I suppose there 
might be some pre-1995 programs out there that can't support such names 
because of API limitations, but what does that have to do with Ada? All of 
the Ada compilers out there for Windows are 32-bit (or more).

In any case, all of my programs are intended to be portable (to other 
compilers and to other Windows and Windows-like systems), and surely *I* 
depend a lot on UNC names (it's a heck of a lot easier to use them for file 
sharing than to create your own TCP-IP protocol!).

>> but what does that
>> have to do with Ada?? Software that supports text file names but doesn't
>> support UNC names is broken, IMHO.
>
> Nope. The design rule I propose is, any local file has to be accessible
> through at least one root determinable by Ada.Directories. The rest is up
> to the implementor's good will. This is certainly doable in any operating
> system I know.

What is a "local file"? Disk-based names are obsolete for most purposes 
(most of the devices on my latest computer don't have them), so you are 
essentially claiming that you don't want to access anything other than the 
local hard disk.

In any case, if an implementation supports UNC names (and Janus/Ada surely 
does, in *all* operations), it has to treat them as roots. And that means 
that Ada.Directories has to treat them as roots.

The fact that you and I don't even seem to agree what a root is just shows 
how silly it is to even consider trying to do this sort of stuff portably.

...
>>> Sorry, but writing a file browser is not stupid. Consider implementation
>>> of a GUI open-file dialog using Ada.Directories.
>>
>> That is *exactly* what I mean. Any "proper" Windows program will use the
>> built-in file browser, not create some less-powerful version on their 
>> own.
>
> No. First there are two (maybe three) of them under Windows. Both
> (especially the newer one) are quite unusable. The older was extensible so
> that you could add buttons and other stuff *required* by a "proper"
> applications like mine. (:-)) Under Linux the situation is much worse than
> that. So I have my own set of file selection widgets, BTW, docked widgets,
> not dialog boxes.

Barf. When you do that, you lose the capabilities that are specific to the 
particular OS, such as direct access to file shares. And they end up looking 
different than they ought to on a particular target.

In any case, both of the Windows file dialogs are extensible; I know because 
I've done it, both to test Claw and to add checkout buttons to the GUI for 
our version control front-end. It's actually pretty easy to do with Claw.

...
>> That's going to be ambiguous if you have proper string literals and very
>> hard to use if you don't.
>
> It will not:
>
>   Open (File, In_File, "C:", ("temp", "tests"), "test20", "txt");
>
> instead of
>
>   Open (File, In_File, "C:\temp\tests\test20.txt");

That's hard to use in my book. (Besides, I have no idea what you intended it 
to mean other than the Rosetta Stone-like example. It's just not readable or 
understandable.) When you get a user-provided file name (a full path like 
"\\Gatekeeper\Webroot\AdaIC\index.html", which is what you're going to get 
back from a Windows file dialog box or from a simple string entry field), 
you're going to have to parse it to get to a form like the one you are 
suggesting. And then the program will have to put it back together -- just 
adding opportunities to introduce bugs and do something other than the 
user's intent.

If you simplify it and provide an appropriate string literal converter, you 
again have the ambiguity problem (or lots of wordy junky conversions).

                                               Randy.

Variable- and fixed-length-character strings (Was: Interpretation of extensions different from Unix/Linux?)

[Jacob Sparre Andersen]

Randy Brukardt wrote:

> Indexing (and slicing) are pretty much the *only* operations that
> you do on a String.

I would guess that comparison is the most common operation on strings.
And after that searching for patterns.

Do we have any data on the frequency of operations on strings?

> If they are very expensive, the entire implementation will be very
> expensive (especially as operations like "&" are already very
> expensive).

An interface for variable-length-character strings should definitely
look slightly different than how we handle fixed-length-character
strings in the Ada standard libraries.  I think that an appropriate
interface would make operations on variable-length-character strings
almost as efficient ans those on fixed-length-character strings.

Greetings,

Jacob
-- 
"I am an old man now, and when I die and go to Heaven there are two matters
 on which I hope enlightenment. One is quantum electro-dynamics and the
 other is turbulence of fluids. About the former, I am rather optimistic."
 Sir Horace Lamb.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Wed, 19 Aug 2009 17:40:06 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:tww2guh98m4j.vbxz4nv412g1.dlg@40tude.net...
>> On Tue, 18 Aug 2009 15:37:39 -0500, Randy Brukardt wrote:
> ...
>>> I think that would be prohibitively expensive in both time and space.
>>
>> Absolutely not. Again, Wide_Wide_String is not an implementation of
>> UTF8_String, it is merely an interface. The implementation of UTF8_String
>> stays an array of octets. Except for indexing which is rarely used with
>> UTF8_String other operations of Wide_Wide_String can be delegated to the
>> representation's operations. No overhead.
> 
> Indexing (and slicing) are pretty much the *only* operations that you do on 
> a String. If they are very expensive, the entire implementation will be very 
> expensive (especially as operations like "&" are already very expensive).

Expensive than what? There is no any cheaper way to index characters of an
UTF-8 string. It not expensive it how it is. Do you propose not to provide
indexing characters of a UTF-8 string?

>>> Windows surely does recognize UNC names natively - surely the file open
>>> does. So by your definition these are "true" roots. There of course is a lot
>>> of crappy software out there that doesn't allow them,
>>
>> It is not crappy, it is backward compatible. All this software uses *legal*
>> Windows API, and it is the API functions (16-bit or whatever) which fail to
>> handle fake \\nodes, useless stuff like "My Documents", "Desktop" etc. This
>> rubbish has nothing to do with the file system. It could be supported, no
>> question, but no portable program will probably ever use it. So why should
>> we care?
> 
> I have no idea what you are talking about. Every 32-bit API supports UNC 
> names, and always has (at least as far back as Windows 95).

No, I think that this includes NT4, 95, 98, ME. But I am lazy to verify it.

>>> but what does that
>>> have to do with Ada?? Software that supports text file names but doesn't
>>> support UNC names is broken, IMHO.
>>
>> Nope. The design rule I propose is, any local file has to be accessible
>> through at least one root determinable by Ada.Directories. The rest is up
>> to the implementor's good will. This is certainly doable in any operating
>> system I know.
> 
> What is a "local file"? Disk-based names are obsolete for most purposes 
> (most of the devices on my latest computer don't have them), so you are 
> essentially claiming that you don't want to access anything other than the 
> local hard disk.

Yes, if we are talking about file systems. There can be various extensions
of the file system notion. But the minimal required support is obviously
the local drives and virtual drives. Beyond that I would leave it to the
vendor. If he decides to support data sources (ODBC), code source
versioning systems (Subversion), or field-bus devices, be it so. 

> In any case, if an implementation supports UNC names (and Janus/Ada surely 
> does, in *all* operations), it has to treat them as roots. And that means 
> that Ada.Directories has to treat them as roots.

I have nothing against it, except that Ada standard cannot mandate the way
roots are to be enumerated under Windows. What it has to mandate is that an
ability to enumerate roots shall be provided.

> The fact that you and I don't even seem to agree what a root is just shows 
> how silly it is to even consider trying to do this sort of stuff portably.

No, it shows that Windows is a silly OS. But that should not prevent us
from having sound standard libraries.

>>> That's going to be ambiguous if you have proper string literals and very
>>> hard to use if you don't.
>>
>> It will not:
>>
>>   Open (File, In_File, "C:", ("temp", "tests"), "test20", "txt");
>>
>> instead of
>>
>>   Open (File, In_File, "C:\temp\tests\test20.txt");
> 
> That's hard to use in my book. (Besides, I have no idea what you intended it 
> to mean other than the Rosetta Stone-like example. It's just not readable or 
> understandable.) When you get a user-provided file name (a full path like 
> "\\Gatekeeper\Webroot\AdaIC\index.html", which is what you're going to get 
> back from a Windows file dialog box or from a simple string entry field), 
> you're going to have to parse it to get to a form like the one you are 
> suggesting.

Yes, this is the Value function, which takes an OS-specific String or
Wide_Wide_String and returns Directory_Entry object (or whatever). This
object can be used in Open either directly:

   Open (File, In_File, Value (Get_Text (Widget)));;

 or as above:

   declare
      Name : Directory_Entry := Value (Get_Text (Widget));
   begin
      Open (File, In_File, Device (Name), Path (Name), Base_Name (Name),
Extension (Name));

---------
Look when you read a number from a text entry box, does that imply that
Integer must be String? Is it Ada or Perl?

> And then the program will have to put it back together -- just 
> adding opportunities to introduce bugs and do something other than the 
> user's intent.

No bug is possible as it is typed.

> If you simplify it and provide an appropriate string literal converter, you 
> again have the ambiguity problem (or lots of wordy junky conversions).

It is far more, it is sane way to have literals of file names. These
literal are OS-independent:

"Gatekeeper", ("Webroot", "AdaIC"), "index", "html"

We could also add operations to compose such literals in other ways:

"Gatekeeper" mod "Webroot" / "AdaIC" * "index" & "html"

The choice of operation names is left to your imagination.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1x1alb3nqznbn.5pnmbt638tqf$.dlg@40tude.net...
...
> Expensive than what? There is no any cheaper way to index characters of an
> UTF-8 string. It not expensive it how it is. Do you propose not to provide
> indexing characters of a UTF-8 string?

If it is strongly typed, I'd only provide storage and equality comparisons. 
No indexing, surely no slicing, and not even any ordering operators. They're 
all too expensive to implement.

>>>> Windows surely does recognize UNC names natively - surely the file open
>>>> does. So by your definition these are "true" roots. There of course is 
>>>> a lot
>>>> of crappy software out there that doesn't allow them,
>>>
>>> It is not crappy, it is backward compatible. All this software uses 
>>> *legal*
>>> Windows API, and it is the API functions (16-bit or whatever) which fail 
>>> to
>>> handle fake \\nodes, useless stuff like "My Documents", "Desktop" etc. 
>>> This
>>> rubbish has nothing to do with the file system. It could be supported, 
>>> no
>>> question, but no portable program will probably ever use it. So why 
>>> should
>>> we care?
>>
>> I have no idea what you are talking about. Every 32-bit API supports UNC
>> names, and always has (at least as far back as Windows 95).
>
> No, I think that this includes NT4, 95, 98, ME. But I am lazy to verify 
> it.

Well, that's because you *can't* verify it. My Ada programs (including our 
compiler and our version control front-end) run on all of those systems, and 
we regularly use shares directly from them. The version control *only* uses 
shares for communication, and I used it on Windows 98 for years (it 
originally was created there, I believe).

You can have issues if you have password-protected shares (since you can't 
provide the password this way), but if you provide the password another way 
(via explorer, for instance), or you use a Windows domain for security, all 
is well. (If you need passwords to be remembered, you have to use XP or 
newer; no idea why that was.) And if you don't have the password, you just 
get Use_Error as you would expect for a security-related issue. No biggie.

...
> I have nothing against it, except that Ada standard cannot mandate the way
> roots are to be enumerated under Windows. What it has to mandate is that 
> an
> ability to enumerate roots shall be provided.

I disagree with everything you wrote on this topic. And there will be a way 
to enumerate roots over my dead body, because it is not reliably 
implementable on Windows (no matter how you define the roots). Requiring Ada 
programs to handle traps would be itiotic, the result would be incompatible 
with other language runtimes, with some anti-virus, and it *still* wouldn't 
be reliable.

                                  Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Thu, 20 Aug 2009 19:08:31 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1x1alb3nqznbn.5pnmbt638tqf$.dlg@40tude.net...
> ...
>> Expensive than what? There is no any cheaper way to index characters of an
>> UTF-8 string. It not expensive it how it is. Do you propose not to provide
>> indexing characters of a UTF-8 string?
> 
> If it is strongly typed, I'd only provide storage and equality comparisons. 
> No indexing, surely no slicing, and not even any ordering operators. They're 
> all too expensive to implement.

But you defined UTF-8 String as Standard.String. That has indexing, which
is broken. I don't understand your point, sorry.

>> I have nothing against it, except that Ada standard cannot mandate the way
>> roots are to be enumerated under Windows. What it has to mandate is that 
>> an ability to enumerate roots shall be provided.
> 
> I disagree with everything you wrote on this topic. And there will be a way 
> to enumerate roots over my dead body, because it is not reliably 
> implementable on Windows (no matter how you define the roots).

Then the consequence must be removing Ada.Directories altogether.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:qyn3t7gwzai0$.1sy8ut5f57ryw.dlg@40tude.net...
> On Thu, 20 Aug 2009 19:08:31 -0500, Randy Brukardt wrote:
...
>> I disagree with everything you wrote on this topic. And there will be a 
>> way
>> to enumerate roots over my dead body, because it is not reliably
>> implementable on Windows (no matter how you define the roots).
>
> Then the consequence must be removing Ada.Directories altogether.

<Sarcasm> That makes sense: I can't have one rarely used capatibility, so no 
one should have any commonly used capabilities, either. </Sarcasm>

In any case, I think you are seriously confused about the purpose of 
Ada.Directories. It is all about manipulating file and directories (and 
their names) that come from some outside source. It is *not* about 
constructing file names from nothing.

Indeed, no competent programmer should ever be constructing file names from 
nothing, because that is how you get the abomination of hard-coded paths and 
file names. Those *always* cause trouble. These things have to come from 
outside of the file system (commonly from the environment or GUI) and thus 
Ada.Directories has nothing to do with their source.

You want to use Ada.Directories for purposes for which it was not intended, 
so it isn't surprising that it doesn't work. And for purposes that are a bad 
idea in the first place, so there is no reason for Ada to support them.

                                Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Fri, 21 Aug 2009 17:10:36 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:qyn3t7gwzai0$.1sy8ut5f57ryw.dlg@40tude.net...
>> On Thu, 20 Aug 2009 19:08:31 -0500, Randy Brukardt wrote:
> ...
>>> I disagree with everything you wrote on this topic. And there will be a way
>>> to enumerate roots over my dead body, because it is not reliably
>>> implementable on Windows (no matter how you define the roots).
>>
>> Then the consequence must be removing Ada.Directories altogether.
> 
> <Sarcasm> That makes sense: I can't have one rarely used capatibility, so no 
> one should have any commonly used capabilities, either. </Sarcasm>
> 
> In any case, I think you are seriously confused about the purpose of 
> Ada.Directories. It is all about manipulating file and directories (and 
> their names) that come from some outside source. It is *not* about 
> constructing file names from nothing.

You should have place closing </sarcasm> brace here.

> Indeed, no competent programmer should ever be constructing file names from 
> nothing, because that is how you get the abomination of hard-coded paths and 
> file names. Those *always* cause trouble.

That has nothing to do with Ada.Directories. If you have a file name you
can use it in Ada.Text_IO. Ada.Directories is all about getting these
names.

> These things have to come from 
> outside of the file system (commonly from the environment or GUI) and thus 
> Ada.Directories has nothing to do with their source.

Huh, and what do the procedures Start_Search and Search there? All
Ada.Directories is built around  them.

> You want to use Ada.Directories for purposes for which it was not intended,

That is certainly true. This is why I said that Ada.Directories is almost
unusable. It cannot serve the purpose of searching a file system. The
negligible rest is:

1. copy, delete files by name;
2. get modification time;
3. create directory;
4. broken file name manipulation operations.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:t16bietxydy8$.10aq5n9g127pq$.dlg@40tude.net...
> On Fri, 21 Aug 2009 17:10:36 -0500, Randy Brukardt wrote:
...
>> These things have to come from
>> outside of the file system (commonly from the environment or GUI) and 
>> thus
>> Ada.Directories has nothing to do with their source.
>
> Huh, and what do the procedures Start_Search and Search there? All
> Ada.Directories is built around  them.

They're for finding out about the files/directories in a directory that you 
already know. Typically, a directory that your program created. The location 
of that directory should have come from some external source.

>> You want to use Ada.Directories for purposes for which it was not 
>> intended,
>
> That is certainly true. This is why I said that Ada.Directories is almost
> unusable. It cannot serve the purpose of searching a file system. The
> negligible rest is:
>
> 1. copy, delete files by name;
> 2. get modification time;
> 3. create directory;

You forgot:

4. search within a known directory.

And I don't consider any of these things "negligible". The Janus/Ada 
compiler depends heavily on the first two, and it is nice that we finally 
can get away from using non-portable kludges to get that information.

> 4. broken file name manipulation operations.

Of course they're broken! They were added over my objections; I don't think 
that it is possible to define useful file name manipulations that are also 
portable, implementable, well-defined, and consistent across 
implementations.

We tried anyway, and of course we got very limited results. And we'll try to 
extend them, and we'll still have operations of very limited use. If you 
need them perfect for a given OS, you *have* to write them yourself. And 
otherwise, maybe these are good enough, but don't expect perfection.

                                       Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Mon, 31 Aug 2009 20:50:56 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 

>> That is certainly true. This is why I said that Ada.Directories is almost
>> unusable. It cannot serve the purpose of searching a file system. The
>> negligible rest is:
>>
>> 1. copy, delete files by name;
>> 2. get modification time;
>> 3. create directory;
> 
> You forgot:
> 
> 4. search within a known directory.

Under the assumption of directories known to the application, there is no
need to search them. Typically an application either maintains its files
and so "knows" them up to the Exits test, or it knows nothing.

> And I don't consider any of these things "negligible". The Janus/Ada 
> compiler depends heavily on the first two, and it is nice that we finally 
> can get away from using non-portable kludges to get that information.

A compiler is a very specific kind of application.

> We tried anyway, and of course we got very limited results. And we'll try to 
> extend them, and we'll still have operations of very limited use. If you 
> need them perfect for a given OS, you *have* to write them yourself.

We need them reasonable working. "Perfect" may attribute an implementation.
But the problem now is lack of functionality. Once the functionality is
present, we could talk about perfection.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Under the assumption of directories known to the application, there is no
> need to search them. Typically an application either maintains its files
> and so "knows" them up to the Exits test, or it knows nothing.

Nonsense.

I have an application that builds mp3 playlists. I specify the
root directory of the mp3 file tree on the command line, the Ada code
searches within that directory for mp3 files to add to a playlist.

-- 
-- Stephe

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Tue, 01 Sep 2009 23:41:02 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Under the assumption of directories known to the application, there is no
>> need to search them. Typically an application either maintains its files
>> and so "knows" them up to the Exits test, or it knows nothing.
> 
> Nonsense.
> 
> I have an application that builds mp3 playlists. I specify the
> root directory of the mp3 file tree on the command line, the Ada code
> searches within that directory for mp3 files to add to a playlist.

I said "typically". A command-line application for maintenance of
playlists, which does not support file browsing by is by no means typical.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[tmoran]

> > I have an application that builds mp3 playlists. I specify the
> > root directory of the mp3 file tree on the command line, the Ada code
> > searches within that directory for mp3 files to add to a playlist.
>
> I said "typically". A command-line application for maintenance of
> playlists, which does not support file browsing by is by no means typical.

  "Unusual" for one person is "typical" for another.

I have an Ada system that runs a TV station.  There are lots of places
where the user uses a GUI to indicate a show, and the program needs to
scan a directory to find its episodes, or he indicates a show episode
and the system needs to build a playlist by scanning a directory to find
the video files, or the user loads a DVD and the system needs to scan
its directory to find the video files.  The user sees "show", "episode",
"DVD" as his abstractions - he doesn't see directories or files.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Wed, 2 Sep 2009 19:49:10 +0000 (UTC), tmoran@acm.org wrote:

>>> I have an application that builds mp3 playlists. I specify the
>>> root directory of the mp3 file tree on the command line, the Ada code
>>> searches within that directory for mp3 files to add to a playlist.
>>
>> I said "typically". A command-line application for maintenance of
>> playlists, which does not support file browsing by is by no means typical.
> 
>   "Unusual" for one person is "typical" for another.
> 
> I have an Ada system that runs a TV station.  There are lots of places
> where the user uses a GUI to indicate a show, and the program needs to
> scan a directory to find its episodes, or he indicates a show episode
> and the system needs to build a playlist by scanning a directory to find
> the video files, or the user loads a DVD and the system needs to scan
> its directory to find the video files.  The user sees "show", "episode",
> "DVD" as his abstractions - he doesn't see directories or files.

And there is no way to specify the directory where files to be stored? It
is impossible to add such directories? It cannot play anything from
mountable drives?

OK, I give up. All these file-manager programs seem useless and untypical.
No need to write them in Ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[tmoran]

> And there is no way to specify the directory where files to be stored? It
> is impossible to add such directories? It cannot play anything from
> mountable drives?
   Who uses your "typical" programs?  Programmers?  My users know about
television - shows, episodes, seasons, DVDs, clips - but I certainly
wouldn't want them to futz around with particular files, whose content and
purpose they don't understand, on a live system transmitting TV to the
whole city.  Of course there's a configuration which specifies directories
etc, but that should be changed exceedingly rarely.  And no, this system
doesn't play directly from mountable drives.  If you want to add a new
episode, or a news flash, it must be loaded into the system from a disk,
DVD, or the net.  Loading includes skipping any bars and tone at the
front, and black at the end, making sure the mpeg files are good, and
putting a copy on the backup as well as the live system.  It's not just a
matter of copying a file.  Even though it uses almost no floating point,
this is not a trivial system - trust me.

> OK, I give up. All these file-manager programs seem useless and untypical.
> No need to write them in Ada.
  Ada is good here for error prevention/detection before run-time, error
reporting at run-time, and, in the part that actually plays video and
audio, timing control and tasking.  Of course it also has features that
make programming simply easier than some languages I won't mention.

> > "Unusual" for one person is "typical" for another.
  A corollary to "the other guy's job always seems easy".

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Thu, 3 Sep 2009 17:27:26 +0000 (UTC), tmoran@acm.org wrote:

>> And there is no way to specify the directory where files to be stored? It
>> is impossible to add such directories? It cannot play anything from
>> mountable drives?
>    Who uses your "typical" programs?

Don't you use anything like MS-Explorer, Konqueror, Midnight Commander? You
must a be Jedi Knight then... (:-))

> Programmers?  My users know about
> television - shows, episodes, seasons, DVDs, clips - but I certainly
> wouldn't want them to futz around with particular files, whose content and
> purpose they don't understand, on a live system transmitting TV to the
> whole city.

Forget about files. How playlists are organized? As a catalogue, right? Do
you provide user an ability to see what is it? Can user find *any* movie in
the catalogue? If yes, then this is what I call typical. You have browsing
of a catalogue and you can enumerate *all* its items. Ada.Directories has
not and cannot.

>> OK, I give up. All these file-manager programs seem useless and untypical.
>> No need to write them in Ada.

>   Ada is good here for error prevention/detection before run-time, error
> reporting at run-time, and, in the part that actually plays video and
> audio, timing control and tasking.  Of course it also has features that
> make programming simply easier than some languages I won't mention.

This does not answer my question. Is file manager a typical application?
How can it be designed in Ada using Ada.Directories? Let us ignore GUI
issues.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:17qw45cbpv4r.1rcmhhpnxv3dv.dlg@40tude.net...
...
> This does not answer my question. Is file manager a typical application?
> How can it be designed in Ada using Ada.Directories? Let us ignore GUI
> issues.

IMHO, no, it is not a typical application. You serve no one by reinventing 
the wheel, and file managers are an integral part of every modern OS, and 
commonly available on lots of non-modern OSes. Let the user use what they 
are familar with. If you did write one with Ada.Directories (and you surely 
can, you just have to use some OS-specific way of finding roots), it would 
necessarily be a poor imitation of the provided one -- it couldn't handle 
anything unusual (such as network connections that need authentication) or 
anything newly added (imagine a new Windows version that supported accessing 
files over the internet using URLs).

Tom's application (making the video catalog from a known directory) or my 
most recent one (finding partially processed [but fully received] e-mail 
messages on mail filter startup [for crash and reboot recovery]) seem far 
more typical to me.

                        Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Thu, 3 Sep 2009 17:22:44 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:17qw45cbpv4r.1rcmhhpnxv3dv.dlg@40tude.net...
> ...
>> This does not answer my question. Is file manager a typical application?
>> How can it be designed in Ada using Ada.Directories? Let us ignore GUI
>> issues.
> 
> IMHO, no, it is not a typical application.

Criterion?

1. Frequency of use
2. Number of implementations per OS
3. Number of implementations per language

> You serve no one by reinventing 
> the wheel, and file managers are an integral part of every modern OS, and 
> commonly available on lots of non-modern OSes.

So? Calculator program is available on all these OSes. Is it an argument
against Ada numeric types having operation "+"?

> Let the user use what they 
> are familar with. If you did write one with Ada.Directories (and you surely 
> can, you just have to use some OS-specific way of finding roots), it would 
> necessarily be a poor imitation of the provided one

Ada.Directories *is* a poor imitation of OS-specific file search. Why is it
in the standard? You cannot apply this logic while keeping Ada.Directories.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:10he0wbmken48$.1q24z0xzfg8ob.dlg@40tude.net...
> On Thu, 3 Sep 2009 17:22:44 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:17qw45cbpv4r.1rcmhhpnxv3dv.dlg@40tude.net...
>> ...
>>> This does not answer my question. Is file manager a typical application?
>>> How can it be designed in Ada using Ada.Directories? Let us ignore GUI
>>> issues.
>>
>> IMHO, no, it is not a typical application.
>
> Criterion?
>
> 1. Frequency of use
> 2. Number of implementations per OS
> 3. Number of implementations per language
>
>> You serve no one by reinventing
>> the wheel, and file managers are an integral part of every modern OS, and
>> commonly available on lots of non-modern OSes.
>
> So? Calculator program is available on all these OSes. Is it an argument
> against Ada numeric types having operation "+"?
>
>> Let the user use what they
>> are familar with. If you did write one with Ada.Directories (and you 
>> surely
>> can, you just have to use some OS-specific way of finding roots), it 
>> would
>> necessarily be a poor imitation of the provided one
>
> Ada.Directories *is* a poor imitation of OS-specific file search. Why is 
> it
> in the standard? You cannot apply this logic while keeping 
> Ada.Directories.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de 

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:10he0wbmken48$.1q24z0xzfg8ob.dlg@40tude.net...
> On Thu, 3 Sep 2009 17:22:44 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:17qw45cbpv4r.1rcmhhpnxv3dv.dlg@40tude.net...
>> ...
>>> This does not answer my question. Is file manager a typical application?
>>> How can it be designed in Ada using Ada.Directories? Let us ignore GUI
>>> issues.
>>
>> IMHO, no, it is not a typical application.
>
> Criterion?

Likelyhood of wanting to write it in Ada, of course. (Which ought to be 
never, as I said below). What other criterion could possibly make sense??

>> You serve no one by reinventing
>> the wheel, and file managers are an integral part of every modern OS, and
>> commonly available on lots of non-modern OSes.
>
> So? Calculator program is available on all these OSes. Is it an argument
> against Ada numeric types having operation "+"?

False analogy: "+" is useful for lots of things, not just writing a 
calculator. You are talking about functionality that is *only* useful for 
writing a file manager or equivalent. (And I'd argue that it isn't even 
useful for that, but YMMV.)

>> Let the user use what they
>> are familar with. If you did write one with Ada.Directories (and you 
>> surely
>> can, you just have to use some OS-specific way of finding roots), it 
>> would
>> necessarily be a poor imitation of the provided one
>
> Ada.Directories *is* a poor imitation of OS-specific file search. Why is 
> it
> in the standard? You cannot apply this logic while keeping 
> Ada.Directories.

I totally disagree. You can write quite useful programs using 
Ada.Directories without depending on anything OS-specific beyond whether or 
not the package is supported at all. (Some OSes don't have directories, so 
Ada.Directories could not usefully do anything in such an environment.) For 
instance, Pattern => "" always matches everything in a directory. It's only 
a problem if you want to go beyond the intended uses for the package. And, 
of course, if some predefined package doesn't do the job for you, then don't 
use it! The predefined stuff cannot do everything for everyone. (One obvious 
example: we couldn't come up with a portable way to define a package that 
could start other programs. Every compiler has this functionality, but it 
isn't amenable to describing in Standards terms.)

                              Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Fri, 4 Sep 2009 21:08:49 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:10he0wbmken48$.1q24z0xzfg8ob.dlg@40tude.net...
>> On Thu, 3 Sep 2009 17:22:44 -0500, Randy Brukardt wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:17qw45cbpv4r.1rcmhhpnxv3dv.dlg@40tude.net...
>>> ...
>>>> This does not answer my question. Is file manager a typical application?
>>>> How can it be designed in Ada using Ada.Directories? Let us ignore GUI
>>>> issues.
>>>
>>> IMHO, no, it is not a typical application.
>>
>> Criterion?
> 
> Likelyhood of wanting to write it in Ada, of course. (Which ought to be 
> never, as I said below).

90% of any program that provides user interface dealing with files. You
cannot implement file open/save/list without it.

>>> You serve no one by reinventing
>>> the wheel, and file managers are an integral part of every modern OS, and
>>> commonly available on lots of non-modern OSes.
>>
>> So? Calculator program is available on all these OSes. Is it an argument
>> against Ada numeric types having operation "+"?
> 
> False analogy: "+" is useful for lots of things, not just writing a 
> calculator. You are talking about functionality that is *only* useful for 
> writing a file manager or equivalent. (And I'd argue that it isn't even 
> useful for that, but YMMV.)

The analogy is right. The functionality of any file being reachable is
essential to use a file system.

Programs dealing with one or two files  don't need Ada.Directories at all.
Similarly, if there are only two numbers, make them named constants and
forget about addition.

>>> Let the user use what they
>>> are familar with. If you did write one with Ada.Directories (and you 
>>> surely can, you just have to use some OS-specific way of finding roots), it 
>>> would necessarily be a poor imitation of the provided one
>>
>> Ada.Directories *is* a poor imitation of OS-specific file search. Why is 
>> it in the standard? You cannot apply this logic while keeping 
>> Ada.Directories.
> 
> I totally disagree. You can write quite useful programs using 
> Ada.Directories without depending on anything OS-specific beyond whether or 
> not the package is supported at all.

This is just untrue. I already have pointed out that Ada.Directories cannot
be used without OS-specific programming. You cannot get file names without
using string literals which *are* OS-specific. In fact not a single
operation there can be used without OS-specific programming around it,
unless the file name is entered from the keyboard and then used as-is,
which Ada.Text_IO already does. If you put file name into a string literal,
that is OS-specific. To let the user choose files from a list is
OS-specific/impossible. To filter files by names is OS-specific. To compare
files for identity is OS-specific. To compare file names is OS-specific.

> (One obvious 
> example: we couldn't come up with a portable way to define a package that 
> could start other programs. Every compiler has this functionality, but it 
> isn't amenable to describing in Standards terms.)

No problem with that, except the false conception, that such a package
(Ada.Directories is among such) should reflect properties of the underlying
OS. All Ada DB bindings suffer this same illness, which limits their
usefulness but multiplies the count of. This is trivially wrong. You cannot
be OS-specific and portable.

Instead of that, Ada packages should provide an abstraction layer, a model
OS, independent on the target. Note that all modern GUI and other
middleware libraries follow this path. No problem, you can spawn a process
using Glib in an OS-independent way. It would be perfectly possible to
introduce Ada library for spawning processes with three pipes (represented
by Ada streams). I wrote a similar thing for GtkAda based on the Glib
functionality.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Enumeration of network shared under Windows (was: Interpretation of extensions different from Unix/Linux?)

[Dmitry A. Kazakov]

On Thu, 20 Aug 2009 19:08:31 -0500, Randy Brukardt wrote:

> I disagree with everything you wrote on this topic. And there will be a way 
> to enumerate roots over my dead body, because it is not reliably 
> implementable on Windows (no matter how you define the roots).

Here is complete Ada program that enumerates Windows shares:

with Ada.Text_IO;           use Ada.Text_IO;
with Interfaces.C.Strings;  use Interfaces.C.Strings;
with Win32;                 use Win32;
with Win32.Windef;          use Win32.Windef;
with Win32.Winnetwk;        use Win32.Winnetwk;
with Win32.Winnt;           use Win32.Winnt;
with Win32.Winerror;        use Win32.Winerror;
with System;                use System;

with System.Address_To_Access_Conversions;

procedure Net_Share is
   Result      : DWORD;
   Count       : aliased DWORD;
   Size        : aliased DWORD;
   Enumeration : aliased HANDLE;
   Buffer      : String (1..10_000);
   use type DWORD;

   function WNetOpenEnumA             -- The standard version is
            (  dwScope       : DWORD; -- unusable for our purpose
               dwType        : DWORD;
               dwUsage       : DWORD;
               lpNetResource : Address;
               lphEnum       : access HANDLE
            )  return DWORD;
   pragma Import (Stdcall, WNETOPENENUMA, "WNetOpenEnumA");

   package Conversions is
      new System.Address_To_Access_Conversions (NETRESOURCEA);

begin
   Result :=
      WNetOpenEnumA
      (  RESOURCE_CONNECTED,
         RESOURCETYPE_DISK,
         0,
         Null_Address,
         Enumeration'Access
      );
   if Result /= NO_ERROR then
      Put_Line ("Error in WNetOpenEnumA" & DWORD'Image (Result));
   end if;
   loop
      Count  := 1;
      Size   := Buffer'Size / 8;
      Result :=
         WNetEnumResource
         (  Enumeration,
            Count'Unchecked_Access,
            Buffer'Address,
            Size'Unchecked_Access
         );
      exit when Result = ERROR_NO_MORE_ITEMS;
      if Result /= NO_ERROR then
         Put_Line ("Error in WNetEnumResource" & DWORD'Image (Result));
      end if;
      declare
         Resource : LPNETRESOURCEA :=
            Conversions.To_Pointer
            (  Buffer'Address
            ) .all'Unchecked_Access;
      begin
         Put_Line
         (  Value (To_Chars_Ptr (Resource.lpLocalName))
         &  " "
         &  Value (To_Chars_Ptr (Resource.lpRemoteName))
         );
      end;
   end loop;
   Result := WNetCloseEnum (Enumeration);
   if Result /= NO_ERROR then
      Put_Line ("Error in WNetCloseEnum" & DWORD'Image (Result));
   end if;
end Net_Share;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Vadim Godunko]

On Aug 15, 3:54 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> You mean, "Ada cannot provide this optimally". As far as the ARG is
> concerned, a UTF-8 encoded string is a String. We looked at other options
> and decided they weren't worth the effort.
>
> Indeed, we approved the encoding package at the last ARG meeting, so it is
> in the current working draft of the Ada Standard:http://www.adaic.com/standards/1zrm/html/RM-A-4-11.html.
>
> So clearly Ada can do this, just not the way you would like to see it done.
> Not the first time. ;-)
>
All times we are talking about safety of Ada applications, and now...
Now, we mix two abstractions - stream of octets and String - in C-like
style! I can say it is possible assumption for the concrete
application, but not for the Standard Library!

Re: Interpretation of extensions different from Unix/Linux?

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Indeed, we approved the encoding package at the last ARG meeting, so it is 
> in the current working draft of the Ada Standard: 
> http://www.adaic.com/standards/1zrm/html/RM-A-4-11.html.

I think there's an inconsistency in that package.

20/3 says:

    The Encode functions do put BOM sequences in the result.

23/3 Notes says:

    14 ... An explicit concatenation
    is needed to include a BOM in an encoded entity (it is not added
    automatically). ...

Also, 13/3 is confusing. It seems to imply there is no function that
encodes a Wide_Wide_String in a String, but there is.

At http://www.ada-auth.org/ais.html, I couldn't find an AI that covers
this. Is there one?

-- 
-- Stephe

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:hxhovb1olmcc.wemymiiulni8$.dlg@40tude.net...
...
> 1. It assumes Latin-1 encoding of the file paths

True,

> 2. It assumes singe root of the file system

Surely not true; it's not true for Windows, for instance, where there are 
pretty much an infinite number of possible roots.

> 3. Even so it provides no way to get the name of the root

I've got an action item to fix this and a number of other problems. Not very 
pressing, though.

> 4. It assumes that directory name can be composed from simple names
> (Compose is broken for the systems where the syntax of a directory name
> differs from the name of a plain file.)

True. We couldn't find any such systems, so we didn't worry about it. (Note 
that Compose can rearrange text if need be; that's enough to handle VMS, for 
one example.)

> 5. It totally ignores devices, file versions, mount points, URL, URI

Not quite true (that's the meaning of "special file"), but it surely doesn't 
try to do anything with such things. There is no real commonality between 
them for the different OSes, so there isn't much point in abstracting them.

> 6. It does not eliminate OS-specific pseudo names, e.g "." and ".."

Those are real names on every OS that I've tried. So it doesn't make sense 
to eliminate them.

> 7. It does not provide any means to compare and canonize file names in an
> OS-independent way

This is not possible to do in general (there is a long Windows developer 
article on such things - the conclusion is to design your programs so that 
you never try to compare file names). I've found that out the hard way -- a 
few functions in Janus/Ada depend on normalization of file names, and they 
fail in unusual ways periodically (usually getting confused between long and 
short versions of names). It's definitely not possible to do it on Windows 
in a bullet-proof fashion, so it would be a bad idea to require Ada 
compilers to do so!

                              Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Thu, 13 Aug 2009 23:46:11 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:hxhovb1olmcc.wemymiiulni8$.dlg@40tude.net...
> ...
>> 6. It does not eliminate OS-specific pseudo names, e.g "." and ".."
> 
> Those are real names on every OS that I've tried. So it doesn't make sense 
> to eliminate them.

Either it should remove them or mark as things breaking the DAG abstraction
(by having special values of File_Kind to indicate non-children). To remove
is IMO simpler for the user.
 
>> 7. It does not provide any means to compare and canonize file names in an
>> OS-independent way
> 
> This is not possible to do in general (there is a long Windows developer 
> article on such things - the conclusion is to design your programs so that 
> you never try to compare file names). I've found that out the hard way -- a 
> few functions in Janus/Ada depend on normalization of file names, and they 
> fail in unusual ways periodically (usually getting confused between long and 
> short versions of names). It's definitely not possible to do it on Windows 
> in a bullet-proof fashion, so it would be a bad idea to require Ada 
> compilers to do so!

This decision automatically implies that file names must be incomparable,
since "=", "<" etc cannot be reasonably implemented.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[vlc]

On Aug 4, 9:18 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Ada is OS independent, and tries to be OS neutral. It's if you assume otherwise
> that you'll cause yourself trouble.

It seems that functionality was designed with MS-DOS / Windows in
mind:

C:\Test> dir
 Datenträger in Laufwerk C: ist WINDOWS
 Volumeseriennummer: 9C47-6BDE

 Verzeichnis von C:\Test

04.08.2009  23:07    <DIR>          .
04.08.2009  23:07    <DIR>          ..
04.08.2009  23:07                 0 .c
04.08.2009  23:07                 0 a.c
04.08.2009  23:07                 0 b.c
               3 Datei(en)              0 Bytes
               2 Verzeichnis(se),    528.986.112 Bytes frei

C:\Test> dir *.c
 Datenträger in Laufwerk C: ist WINDOWS
 Volumeseriennummer: 9C47-6BDE

 Verzeichnis von C:\Test

04.08.2009  23:07                 0 .c
04.08.2009  23:07                 0 a.c
04.08.2009  23:07                 0 b.c
               3 Datei(en)              0 Bytes
               0 Verzeichnis(se),    528.986.112 Bytes frei

C:\Test>

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"vlc" <just.another.spam.account@googlemail.com> wrote in message 
news:8a5f3b98-1c5a-4d47-aca7-e106d1223fa9@a26g2000yqn.googlegroups.com...
...
>If the specifications are different, the utilities in Ada.Directories
>are quite unusable for UNIX/Linux.

I think you are seriously confused about how this stuff works in Unix. 
(Either that, or I'm getting senile... ;-)

> In case I want to process all *.c files in a given directory, I could code 
> something like
>
>with Ada.Directories; use Ada.Directories;
>
>procedure Parse is
>   procedure Do_It (Directory_Entry : Directory_Entry_Type) is
>   begin
>      -- Do something
>   end Do_It;
>begin
>   Ada.Directories.Search (".", "*.c", (others => True), Do_It'Access);
>end Parse;
>
>If I want to ensure me what files will be processed, I would call e.g.
>
>ls -A *.c
>
>first. But if there would be a file ".c" in the current directory, it
>would not be listed by the "ls" command, but processed by my program.

But "ls" does not display all of the files by default! You need an option (I 
don't recall which one; I used to always use "ls -al" but I no longer 
remember why) to see the files that start with a ".". That doesn't mean that 
they don't match the wildcard, it just means that "ls" doesn't display them.

If you did an "ls *.", that wouldn't display ".", either, but there still is 
a file with that name in the directory.

Ada.Directories.Search does "display" all filenames, of course, as there is 
no filter to match the goofy behavior of "ls". So you see this file that 
"ls" does not show.

My recollection (mostly from the CSH on Unix, SCO, and Sun OS, which 
admittedly is a long time ago) is that this is a feature of "ls" only. That 
is, if you write your own program "wobble" and then call it

    wobble *.c

you would in fact get the file ".c" in the list of files passed. After all, 
"*.c" is just a regular expression, and one that clearly matches the string 
".c" (since '*' means match 0 or more arbitrary characters).

If that's not true, then the implementation in question probably has a bug 
(it really ought to match what the shell does, although there can be no 
*requirement* of that). But I suspect the problem here is that you are 
confusing the partial list of files that "ls" displays by default with the 
meaning of wildcard file expressions.

                               Randy.

P.S. I recall that I programmed my csh to include a number of options on all 
calls to "ls" (and a number of the other predefined utilities) so that I 
didn't have to type them all the time. Which may be why I don't remember 
which ones they were...

Wilcards in Linux (was: Interpretation of extensions different from Unix/Linux?)

[stefan-lucks]

On Fri, 14 Aug 2009, Randy Brukardt wrote:

> "vlc" <just.another.spam.account@googlemail.com> wrote in message 
> news:8a5f3b98-1c5a-4d47-aca7-e106d1223fa9@a26g2000yqn.googlegroups.com...
> ...
> >If the specifications are different, the utilities in Ada.Directories
> >are quite unusable for UNIX/Linux.
> 
> I think you are seriously confused about how this stuff works in Unix. 
> (Either that, or I'm getting senile... ;-)

I wouldn't suggest that. I am working on a linux computer, and I thought 
you where right. But when trying out (Suse Linux 11.0), I was cought by 
suprise. 

First, the behaviour of "rm *.c":

--> start

stef@linux-3fdp:~/Post/TEST> ls -a
.  ..
stef@linux-3fdp:~/Post/TEST> touch x.c
stef@linux-3fdp:~/Post/TEST> touch y.c
stef@linux-3fdp:~/Post/TEST> touch .c
stef@linux-3fdp:~/Post/TEST> ls
x.c  y.c
stef@linux-3fdp:~/Post/TEST> ls -a
.  ..  .c  x.c  y.c
stef@linux-3fdp:~/Post/TEST> rm *.c
stef@linux-3fdp:~/Post/TEST> ls -a
.  ..  .c

<-- stop

Oops, ".c" hasn't been removed! 

Is there something special with predefined or builtin commands, such as 
"rm"? Just write a little command yourself:

--> start

with Ada.Command_Line; with Ada.Text_IO; 
use Ada;

procedure Repeat_Command is
begin
   Text_IO.Put_Line(Natural'Image(Command_Line.Argument_Count));
   for I in 1 .. Command_Line.Argument_Count loop
      Text_IO.Put_Line(Command_Line.Argument(I));
   end loop;
   Text_IO.Put_Line("----------");
end Repeat_Command;
 
<-- stop

Now, call this program with "*.c":

--> start

stef@linux-3fdp:~/Post/TEST> touch x.c
stef@linux-3fdp:~/Post/TEST> touch y.c
linux-3fdp:~/Post/TEST> ./repeat_command
 0
----------
linux-3fdp:~/Post/TEST> ./repeat_command *.c
 2
x.c
y.c
----------

<--stop

The file ".c" was still there, but the shell just called 
"repeat_command x.c y.c", ignoring the file ".c". 

I tried with different shells, including csh and sh. It was the same, 
everywhere. Apparently, "vlc" is right. 

On the other hand, I wonder where this feature has been documented -- the 
docs I found clearly defined the "*" wildcard to represent a string of any 
length, including zero. 

There appears to be a special rule if the zero-string is followed by a 
".", but where is it documented?

Just to verify that "*" _can_ represent a zero-length string:

--> start

linux-3fdp:~/Post/TEST> ./repeat_command repeat_command*
 5
repeat_command
repeat_command.adb
repeat_command.adb~
repeat_command.ali
repeat_command.o
----------

<--stop

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Wilcards in Linux (was: Interpretation of extensions different from Unix/Linux?)

[stefan-lucks]

I wrote:

> There appears to be a special rule if the zero-string is followed by a 
> ".", but where is it documented?

Found it in <http://www.apl.jhu.edu/Misc/Unix-info/shells/bourne.html>:

File Name Substitution

The Bourne shell provides a sophisticated pattern matching and file name 
substitution ability. To match any string, including the null string, use 
the asterisk (*). The question mark (?) can be used to match a single 
character. Characters enclosed within square brackets can signify a set of 
characters to match. Placing an exclamation point after the open bracket 
will signify a pattern that matches none of the characters specified with 
the brackets. A hyphen between letters that are located in brackets 
signifies a pattern to match all characters included in the specified 
range. For example the pattern .[A-Z]* matches all files whose first two 
characters are a period and a capital letter.

There is an exception to the filename substitution rules. Any file that 
begins with a period will not match a pattern. In other words, to see a 
list of all files that begin with a period, you would have to use the 
pattern .* . If the pattern does not match any file names, the pattern is 
returned. Infinite recursion can occur if files have names that include 
any of the special pattern characters.

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Wilcards in Linux

[Markus Schoepflin]

stefan-lucks@see-the.signature wrote:

> On the other hand, I wonder where this feature has been documented -- the 
> docs I found clearly defined the "*" wildcard to represent a string of any 
> length, including zero. 
> 
> There appears to be a special rule if the zero-string is followed by a 
> ".", but where is it documented?

See 
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_03

Markus

Re: Wilcards in Linux

[Ludovic Brenta]

Markus Schoepflin wrote on comp.lang.ada:
> Stefan Lucks wrote:
>> On the other hand, I wonder where this feature has been documented -- the
>> docs I found clearly defined the "*" wildcard to represent a string of any
>> length, including zero.
>
>> There appears to be a special rule if the zero-string is followed by a
>> ".", but where is it documented?
>
> Seehttp://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.ht...

This documents the "Shell Command Language" so does not apply to
programs that want to process the wildcards themselves. The reason why
it is so easy to mistakenly assume that this globbing grammar applies
to all programs is because, on Unix, programs do not normally expand
any wildcards; the shell does that and passes the expanded file names
to the programs.

I'm curious to know how BUSH handles filename patterns.

--
Ludovic Brenta.

Re: Wilcards in Linux

[Tero Koskinen]

Ludovic Brenta kirjoitti:
> This documents the "Shell Command Language" so does not apply to
> programs that want to process the wildcards themselves. The reason why
> it is so easy to mistakenly assume that this globbing grammar applies
> to all programs is because, on Unix, programs do not normally expand
> any wildcards; the shell does that and passes the expanded file names
> to the programs.

Mr. Brenta is right in here. The filename expansion is handled by
unix shells and is called "globbing". The behaviour can be controlled
via shells' options or environment variables, so it _depends_ on
the used shell.

For example in zsh:
> $ mkdir example
> $ cd example
> $ touch a.c b.c .c
> $ ls -lA
> total 0
> -rw-r--r--  1 tkoskine  tkoskine  0 Aug 14 21:05 .c
> -rw-r--r--  1 tkoskine  tkoskine  0 Aug 14 21:05 a.c
> -rw-r--r--  1 tkoskine  tkoskine  0 Aug 14 21:05 b.c
> $ ls *.c
> a.c b.c
> $ setopt NO_GLOB
> $ ls *.c
> ls: *.c: No such file or directory
> $ setopt GLOB;setopt GLOB_DOTS
> $ ls *.c
> .c  a.c b.c
> $ setopt NULL_GLOB;setopt GLOB
> $ setopt NO_GLOB_DOTS
> $ ls -a *.c
> a.c b.c
> $ ls *.c
> a.c b.c
> $ touch d.ada
> $ ls *.pascal
> a.c   b.c   d.ada
> $

Notice how "ls *.pascal" lists those *.c and *.ada files!

-Tero Koskinen

Re: Interpretation of extensions different from Unix/Linux?

[Keith Thompson]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> "vlc" <just.another.spam.account@googlemail.com> wrote in message 
> news:8a5f3b98-1c5a-4d47-aca7-e106d1223fa9@a26g2000yqn.googlegroups.com...
> ...
>>If the specifications are different, the utilities in Ada.Directories
>>are quite unusable for UNIX/Linux.
>
> I think you are seriously confused about how this stuff works in Unix. 
> (Either that, or I'm getting senile... ;-)
>
>> In case I want to process all *.c files in a given directory, I could code 
>> something like
>>
>>with Ada.Directories; use Ada.Directories;
>>
>>procedure Parse is
>>   procedure Do_It (Directory_Entry : Directory_Entry_Type) is
>>   begin
>>      -- Do something
>>   end Do_It;
>>begin
>>   Ada.Directories.Search (".", "*.c", (others => True), Do_It'Access);
>>end Parse;
>>
>>If I want to ensure me what files will be processed, I would call e.g.
>>
>>ls -A *.c
>>
>>first. But if there would be a file ".c" in the current directory, it
>>would not be listed by the "ls" command, but processed by my program.
>
> But "ls" does not display all of the files by default! You need an option (I 
> don't recall which one; I used to always use "ls -al" but I no longer 
> remember why) to see the files that start with a ".". That doesn't mean that 
> they don't match the wildcard, it just means that "ls" doesn't display them.
>
> If you did an "ls *.", that wouldn't display ".", either, but there still is 
> a file with that name in the directory.

A lot of this has already been covered, but I'll summarize.

The ls command, like most Unix commands, doesn't handle wildcards.
Wildcards are expanded by the shell before ls is invoked.  If the
current directory contains just foo.c and bar.c, then the ls command
can't tell the difference between "ls *.c" and "ls bar.c foo.c"; it
receives exactly the same arguments in both cases.

Wildcard expansion does not include files whose names start with '.',
unless the pattern actually starts with a '.' character.  Different
shells may differ in how they handle wildcards, but on this particular
point I think all the common shells consistent.

The ls command, if invoked with no arguments or with a directory
argument, lists the files in current or specified directory, excluding
files whose names start with '.'.  The "-a" option to ls overrides
this, and tells it to list all files including dot files.  The "-A"
option (which may not exist in all versions of ls) includes dot files
but excludes "." and "..".

So the exclusion of files whose names start with '.' is done in two
different places: by wildcard expansion (handled by the shell) and in
a directory listing without the "-a" or "-A" option (handled by the ls
command).

Suppose the current directory contains "foo.c", "bar.c", and ".c".

% ls
bar.c  foo.c
% ls -a
.  ..  .c  bar.c  foo.c
% ls *.c
bar.c  foo.c
% ls -a *.c
bar.c  foo.c

"ls -a" causes the ls command to read the directory and list all
files, including those whose names start with '.'.

In "ls -a *.c", the *.c wildcard is expanded by the shell, so the ls
command sees the arguments "-a bar.c foo.c".  It doesn't list ".c"
because it wasn't asked to do so.

> Ada.Directories.Search does "display" all filenames, of course, as there is 
> no filter to match the goofy behavior of "ls". So you see this file that 
> "ls" does not show.
>
> My recollection (mostly from the CSH on Unix, SCO, and Sun OS, which 
> admittedly is a long time ago) is that this is a feature of "ls" only. That 
> is, if you write your own program "wobble" and then call it
>
>     wobble *.c
>
> you would in fact get the file ".c" in the list of files passed. After all, 
> "*.c" is just a regular expression, and one that clearly matches the string 
> ".c" (since '*' means match 0 or more arbitrary characters).

No, "wobble *.c" will not cause the wobble command to see ".c".
Neither ls nor wobble does anything special with wildcards; neither is
a built-in command.

[...]

Note that if you invoke the ls command other than from a shell, for
example in Perl:

    system('ls', '*.c');

then no wildcard expansion is done, and the ls command receives the
string "*.c" as an argument.  This will result in an error message,
unless there happens to be a file in the current directory whose name
is "*.c" (which is perfectly legal, but can cause problems).  You can
achieve the same effect from the shell by quoting the argument:

    % ls '*.c'

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Interpretation of extensions different from Unix/Linux?

[Robert A Duff]

Keith Thompson <kst-u@mib.org> writes:

> So the exclusion of files whose names start with '.' is done in two
> different places: by wildcard expansion (handled by the shell) and in
> a directory listing without the "-a" or "-A" option (handled by the ls
> command).

Thank you, Keith, for explaining and summarizing all these details.
It matches my understanding of Unix behavior.  Unix shell's behavior,
that is -- it's not built in to the Unix OS, except by convention and
culture.

Of course, it's all ridiculous: hiding file names that start with "." is
a stupid idea.  Expanding wildcards on the command line and then passing
separate args as strings is a stupid idea.  This is one of the (few)
areas where Windows does it right, compared to Unix.  Sigh.

Whether Ada.Directories ought to mimic these strange behaviors of Unix
shell(s), I don't know.

- Bob

Re: Interpretation of extensions different from Unix/Linux?

[Jacob Sparre Andersen]

Robert A Duff wrote:

> Thank you, Keith, for explaining and summarizing all these details.
> It matches my understanding of Unix behavior.  Unix shell's
> behavior, that is -- it's not built in to the Unix OS, except by
> convention and culture.

A unix system has to have a "/bin/sh" program which works like this,
to be a unix system.  It is simply a part of the standard.

> Of course, it's all ridiculous: hiding file names that start with
> "." is a stupid idea.  Expanding wildcards on the command line and
> then passing separate args as strings is a stupid idea.  This is one
> of the (few) areas where Windows does it right, compared to Unix.
> Sigh.

Expanding wildcards on the command line centralises that feature, so
the users don't have to worry about how the individual applications
have decided to implement wildcard expansion.  I would definitely not
be happy with a system, where each and every program had a slightly
different interpretation of a wildcard.

Given how anarchistic most "unix programmers" are, this is definitely
a more user friendly solution.

Greetings,

Jacob
-- 
Photo of the day:
                       http://billeder.jacob-sparre.dk/dagens/2009-08-15

Re: Interpretation of extensions different from Unix/Linux?

[Adam Beneschan]

On Aug 20, 12:49 am, Jacob Sparre Andersen <spa...@nbi.dk> wrote:

> > Of course, it's all ridiculous: hiding file names that start with
> > "." is a stupid idea.  Expanding wildcards on the command line and
> > then passing separate args as strings is a stupid idea.  This is one
> > of the (few) areas where Windows does it right, compared to Unix.
> > Sigh.
>
> Expanding wildcards on the command line centralises that feature, so
> the users don't have to worry about how the individual applications
> have decided to implement wildcard expansion.  I would definitely not
> be happy with a system, where each and every program had a slightly
> different interpretation of a wildcard.

That wouldn't need to be the case.  On VMS, for example, wildcards are
passed to the program and not expanded by the command-line
interpreter.  But VMS also provides standard services that take a
wildcard and return the matching file names, one at a time.
Presumably every program that needs to expand wildcards would use
these routines, rather than reinvent the wheel.  So they would be
consistent.

Furthermore, suppose you wrote an interactive program that takes its
own commands, some of which may refer to wildcarded file names.  How
would the shell's expansion of wildcards help make things consistent
in that case?  Wouldn't it be more centralized to have an OS or
standard library routine to do the expansion, that would work the same
on both the wildcards you specify when running the program, and the
wildcards you specify in the program's own interactive command line
(or in a text box in a GUI, or whatever)?

I don't see any advantage to doing it the way Unix did it.  Besides
the above disadvantages, you can't write a Unix command that does
something like

   rename *.ada *.adb

as is available on other OS's.  (All right, you could, but you'd have
to require quote marks around the wildcards.)


> Given how anarchistic most "unix programmers" are, this is definitely
> a more user friendly solution.

User-friendly, until you have a user that has a large number of files,
and then can't do an operation on all of them because the shell that
expands the wildcards on the command line finds that it can't fit all
the file names in its command-line buffer.  I've been there FAR too
many times.  I don't consider this to be a friendly feature.

                                        -- Adam

Re: Interpretation of extensions different from Unix/Linux?

[sjw]

On Aug 20, 4:56 pm, Adam Beneschan <a...@irvine.com> wrote:

> User-friendly, until you have a user that has a large number of files,
> and then can't do an operation on all of them because the shell that
> expands the wildcards on the command line finds that it can't fit all
> the file names in its command-line buffer.  I've been there FAR too
> many times.  I don't consider this to be a friendly feature.

To make all files in this and subdirectories read-only, no matter how
may there are (typically 19,000 in our usage)

find . -type f -print0 | xargs -0 chmod 444

What could be easier or friendlier than that?!

Re: Interpretation of extensions different from Unix/Linux?

[Robert A Duff]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> Robert A Duff wrote:
>> Of course, it's all ridiculous: hiding file names that start with
>> "." is a stupid idea.  Expanding wildcards on the command line and
>> then passing separate args as strings is a stupid idea.  This is one
>> of the (few) areas where Windows does it right, compared to Unix.
>> Sigh.
>
> Expanding wildcards on the command line centralises that feature, so
> the users don't have to worry about how the individual applications
> have decided to implement wildcard expansion.

Yes, that is an advantage of having the shell do it,
(although "centralized" is somewhat dubious.  It's centralized
in 'sh'.  And 'csh'.  And 'bash'.  And 'find'.  And dozens of others.)
However, there are so many disadvantages, that I think
this part of Unix is just plain broken:

Note that I said, "passing separate args as strings", and I think that's
the worst part of it.  Defining the semantics of a language in terms of
textual manipulations is a Bad Idea.  That's why C macros are evil.  And
why pretty much the entire 'sh' language is such a horror.  And all the
other Unix shells are just as bad.  This is why 'make' is such a mess.
In Ada, the semantics of "X, Y: array ...;" are defined in terms of
textual substition, which leads to various surprises.  At least this
design mistake doesn't permeate Ada.

Textual substition is a simple rule (just change "*.ada" to
"foo.ada bar.ada baz.ada", or whatever).  But it leads to
complicated and surprising consequences.

If I say, "cp *.ada backup", it means copy all the *.ada files
into the backup directory.  Suppose I accidentally hit <enter>
before typing "backup", so I say, "cp *.ada".  On a reasonable
system, I'd get an error -- one argument passed, but 'cp' is
expecting two.  On Unix, I usually get an error, but it's
something nonsensical, like "zoo.ada is not a directory".
And if it just so happens that there are exactly two files
matching *.ada, I get no error -- instead of backing up
my files, it destroys one of them!

Here's another stupidity:

% grep somethingorother *.ada
Arguments too long
% grep somethingorother `find some-directory -name '*.ada'`
Too many words from ``

The idea that all the file names have to be stored in memory during the
search is just plain broken.  What if I wanted to search all the files
on my huge disk?  (Side issue: Unix doesn't have a standard wildcard
that means "a certain directory, and all subdirectories underneath that
in the tree".  You have to use 'find' -- yuck.)  (Another side issue:
grep takes it arguments in backwards order, because of the way
wildcards work in Unix.)

Unix exacerbates this problem by using a fixed-size buffer for the
command line.  No matter how big it is, it is always both too big and
too small.

(Why is the "search" command called "grep"?  For that matter, why is the
"help" command called "man"?)

>...I would definitely not
> be happy with a system, where each and every program had a slightly
> different interpretation of a wildcard.

Agreed.

But it doesn't have to be that way.  On VMS, wildcards are treated in a
completely uniform manner.  The OS provides a service to iterate through
the files corresponding to a given wildcard, and all programs use it.
No problem.  Same is true on other OS'es I've used.

The problem you describe did exist on MS-DOS, and on Windows
(although I think it's not as bad as it used to be) -- which is
surprising, since DOS provided a similar service to VMS.
I admit that the Unix design prevents this problem.
But even if you insist on having the shell expand wildcards,
"cp *.ada backup" should pass exactly 2 arguments to 'cp' --
a list of file names, and a directory name.

> Given how anarchistic most "unix programmers" are, this is definitely
> a more user friendly solution.

Sigh.  No language/OS design can prevent incompetent programmers from
making a mess.  To me, it seems sufficient to have a (standard!) service
that says "Apply so-and-so procedure to each file (or file name) that
matches such-and-such wildcard."  I don't know why it worked well on
VMS, but not on MS-DOS.

Sorry for the mostly off-topic rant.  The Ada question is: to what
extent should Ada.Directories mimic all this foolishness?

- Bob

Re: Interpretation of extensions different from Unix/Linux?

[Adam Beneschan]

On Aug 20, 12:44 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:

> If I say, "cp *.ada backup", it means copy all the *.ada files
> into the backup directory.  Suppose I accidentally hit <enter>
> before typing "backup", so I say, "cp *.ada".  On a reasonable
> system, I'd get an error -- one argument passed, but 'cp' is
> expecting two.  On Unix, I usually get an error, but it's
> something nonsensical, like "zoo.ada is not a directory".
> And if it just so happens that there are exactly two files
> matching *.ada, I get no error -- instead of backing up
> my files, it destroys one of them!

Yup.  That last feature can be a bit of a blessing, though, at least
when you throw curly braces into the mix.  A file name like abc
{def,ghi,jkl}mno.ada is expanded by the shell to "abcdefmno.ada
abcghimno.ada abcjklmno.ada", which is helpful if you want to refer to
a set of files that differ only in parts of the names (or if you want
to specify a set of files in some other directory, so that you don't
have to type the path name repeatedly).  But I often abuse that
feature with commands like

   cp test1.ada{,.save}

The shell expands the latter to "test1.ada test1.ada.save" and doesn't
know that the two files it's expanding are going to have different
purposes in the command.  This is a little different from *, though,
in that it's not exactly a wild card, and will be expanded in the same
way with no regard to what files actually exist on your system.


> (Why is the "search" command called "grep"?  For that matter, why is the
> "help" command called "man"?)

Well, the second should be obvious---if you can't figure out how to do
what you want, you say, "Oh MAN, how do I use this *&^#@$*^
command???"

                                 -- Adam

Re: Interpretation of extensions different from Unix/Linux?

[(see below)]

> On Aug 20, 12:44�pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
> 
> (Why is the "search" command called "grep"? �For that matter, why is the
> "help" command called "man"?)

A file is displayed with cat, edited with vi, and renamed with mv.
C is compiled with cc. Is Pascal compiled with cp or with pc?
Is Ada compiled with ac?

You get used to it. I certainly would not trade it for the massively clunky
VMS command language(s).

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Interpretation of extensions different from Unix/Linux?

[tmoran]

> when you throw curly braces into the mix.  A file name like abc
> {def,ghi,jkl}mno.ada is expanded by the shell to "abcdefmno.ada
> abcghimno.ada abcjklmno.ada", which is helpful if you want to refer to
 It's truly marvelous that after 30 years of database development
"files" are still stored in a simple tree structure and the way
to specify a set of files is with weird character juggling of names.

Re: Interpretation of extensions different from Unix/Linux?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccljlei82j.fsf@shell01.TheWorld.com...
...
> Sigh.  No language/OS design can prevent incompetent programmers from
> making a mess.  To me, it seems sufficient to have a (standard!) service
> that says "Apply so-and-so procedure to each file (or file name) that
> matches such-and-such wildcard."  I don't know why it worked well on
> VMS, but not on MS-DOS.

It didn't work in MS-DOS because the original MS-DOS facility only supported 
the '?' wildcard; processing of '*' had to be done by the operation - 
expanding to the correct number of '?' to fill an 8.3 name. (That was 
inherited from CP/M.) By the time that a proper facility was available, 
everyone had written there own, slightly different versions.

Win32 never had this problem, however, the search facility there always 
properly (modulo bugs) supported wildcards. But I think a lot of those old 
cobbled solutions came over initially -- although they're probably gone by 
now.

End of history lesson. :-)

                                Randy.

Re: Interpretation of extensions different from Unix/Linux?

[Keith Thompson]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
[...]
> (Why is the "search" command called "grep"?  For that matter, why is the
> "help" command called "man"?)
[...]

Why not?

The original Unix text editor (or at least one of the earliest ones)
was "ed", a line-oriented editor.  In ed, the way to print all the
lines in the current buffer (file) matching a specified pattern is

g/RE/p

where "RE" is a regular expression.  Somebody has the bright idea of
extracting this functionality into a separate program.

"man" is short for "manual".

Unix is flexible enough that you can change all this if you like.
The shell is just another program.  It would be easy enough to
create a new shell, or even a set of aliases for an existing shell,
that remaps all the command names to something more "sensible", so
"man" is called "help" and "grep" is called "search".

I find it interesting that nobody bothers to do this.  Once you
get used to the odd names, they're really not a problem.

You also mentioned that the arguments grep are "backwards".
It's true that the argument order is imposed by wildcard expansion,
but what's backwards about putting the search terms first and
file name(s) last?  I think it's just a matter of what you're
accustomed to.

The Ada-relevant point, I suppose, is that Unix behavior is just
as valid as, say, VMS behavior -- or at least Ada needs to treat it
that way.  If Ada is going to provide functionality for things that
differ from one OS to another, it needs to accomodate different
systems, even the subset that I think is stupid, as well as the
differing subset that you think is stupid.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Interpretation of extensions different from Unix/Linux?

[Dmitry A. Kazakov]

On Fri, 21 Aug 2009 10:58:47 -0700, Keith Thompson wrote:

> Unix is flexible enough that you can change all this if you like.
> The shell is just another program.  It would be easy enough to
> create a new shell, or even a set of aliases for an existing shell,
> that remaps all the command names to something more "sensible", so
> "man" is called "help" and "grep" is called "search".
> 
> I find it interesting that nobody bothers to do this.  Once you
> get used to the odd names, they're really not a problem.

That is because it is rather a burden than an advantage. You pay for a
system and then have to redesign it to fit your needs. You just do not do
it. Compare it with MS-Office. You can reconfigure all its buttons etc. But
you would never do it seriously. No more that 90% of Unix users would do
their shells. Some rudimentary redefinitions like dir = ls -FCa in .bashrc,
that's all.

So-called "flexibility" is laziness of developers to supply a usable and
comfortable interface. Design of such an interface is a huge work, even if
you have all necessary functionality. They just tell you - do it yourself.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interpretation of extensions different from Unix/Linux?

[Jeffrey R. Carter]

Keith Thompson wrote:
> 
> The original Unix text editor (or at least one of the earliest ones)
> was "ed", a line-oriented editor.  In ed, the way to print all the
> lines in the current buffer (file) matching a specified pattern is
> 
> g/RE/p
> 
> where "RE" is a regular expression.  Somebody has the bright idea of
> extracting this functionality into a separate program.

I had heard that grep came from General Regular Expression Pattern matcher, or 
something like that.

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail
19

Re: Interpretation of extensions different from Unix/Linux?

[Robert A Duff]

Keith Thompson <kst-u@mib.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> [...]
>> (Why is the "search" command called "grep"?  For that matter, why is the
>> "help" command called "man"?)
> [...]
>
> Why not?

Because it's stupid.  ;-)

Yeah, I know all the history mentioned below.
And I'm used to it.  I still think it's stupid.

Please explain to my Grandmother why it's "grep" and "man".

> The original Unix text editor (or at least one of the earliest ones)
> was "ed", a line-oriented editor.  In ed, the way to print all the
> lines in the current buffer (file) matching a specified pattern is
>
> g/RE/p
>
> where "RE" is a regular expression.  Somebody has the bright idea of
> extracting this functionality into a separate program.
>
> "man" is short for "manual".

I know.

And the Linux 'man' pages tell you to use 'info' if you want
the real story.  ;-)

> Unix is flexible enough that you can change all this if you like.

Yeah, please explain to my Grandmother how to "change all this"
if she likes.

> The shell is just another program.

Yeah, that's an elegant feature of Unix.  But now we have dozens of
shells, and each one stinks more than all the others put together.

>...It would be easy enough to
> create a new shell, or even a set of aliases for an existing shell,
> that remaps all the command names to something more "sensible", so
> "man" is called "help" and "grep" is called "search".
>
> I find it interesting that nobody bothers to do this.  Once you
> get used to the odd names, they're really not a problem.

I'm used to the odd names.  They're not a problem for me,
except when I get in a ranting mood.

But I do alias 'ls' to show all the sort-of hidden files.
Hiding files that start with "." is just plain stupid.

> You also mentioned that the arguments grep are "backwards".
> It's true that the argument order is imposed by wildcard expansion,
> but what's backwards about putting the search terms first and
> file name(s) last?  I think it's just a matter of what you're
> accustomed to.

I'm accustomed to grep, and I use it every day, but I still think
"search so-and-so files for such-and-such string" is more intuitive
(to me) than the other way 'round.  Matter of taste, I suppose.

> The Ada-relevant point, I suppose, is that Unix behavior is just
> as valid as, say, VMS behavior -- or at least Ada needs to treat it
> that way.  If Ada is going to provide functionality for things that
> differ from one OS to another, it needs to accomodate different
> systems, even the subset that I think is stupid, as well as the
> differing subset that you think is stupid.

Yes, indeed.

I don't like the attitude that says, "Ada should provide nothing at all,
because different systems are different."  I once worked on a system
where all directories were numbers (1 to 100), and there were no
subdirectories.  That doesn't mean Ada can't provide decent support
for hierarchical directories.

- Bob

P.S. Note that when I gripe about Unix/Linux, I'm griping against some
imaginary ideal.  The truth is, I'm happier in Linux than Windows or
MS-DOS or VMS or ...

Re: Interpretation of extensions different from Unix/Linux?

[Hyman Rosen]

Robert A Duff wrote:
> Because it's stupid.  ;-)

Isn't it a little late in the day to be arguing about
UNIX command-line tools? The 'grep' command has been
around since 1973, so it predates Ada by a number of
years. <http://www.columbia.edu/~rh120/ch001j.c11>

Anyway, the notion that meaningful names would be
better by some metric needs to be tested, not just
assumed. After all, a more rationally named 'grep'
might be called 'find', 'search', 'lookfor', 'probe',
'examine', 'locate', and a thesaurus-full of other
words. Any of these might be a program which searches
for files by name, rather than for files containing
such content. Perhaps the command does both, as in
the Windows graphical search facility.

In the end, you have to learn what you need to know,
and then you just know it.

Re: Interpretation of extensions different from Unix/Linux?

[Keith Thompson]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> [...]
>>> (Why is the "search" command called "grep"?  For that matter, why is the
>>> "help" command called "man"?)
>> [...]
>>
>> Why not?
>
> Because it's stupid.  ;-)
>
> Yeah, I know all the history mentioned below.
> And I'm used to it.  I still think it's stupid.
>
> Please explain to my Grandmother why it's "grep" and "man".
>
>> The original Unix text editor (or at least one of the earliest ones)
>> was "ed", a line-oriented editor.  In ed, the way to print all the
>> lines in the current buffer (file) matching a specified pattern is
>>
>> g/RE/p
>>
>> where "RE" is a regular expression.  Somebody has the bright idea of
>> extracting this functionality into a separate program.
>>
>> "man" is short for "manual".
>
> I know.
>
> And the Linux 'man' pages tell you to use 'info' if you want
> the real story.  ;-)
>
>> Unix is flexible enough that you can change all this if you like.
>
> Yeah, please explain to my Grandmother how to "change all this"
> if she likes.

There shouldn't be any need for your Grandmother to change anything.
If there's a better set of names for the basic commands ("search"
rather than "grep", and so on), it's easy enough for someone to
do all that work *once* and let everyone else, including your
Grandmother, take advantage of it.

The trend for user-friendly Unix-like systems seems to be to do
everything through a GUI environment, where the command-line tools
aren't visible at all unless you ask for them.  That's what I'd
expect someone's stereotypical Grandmother to do.  A non-programmer
user probably needs a way to avoid the command-line shell altogether,
not just a more friendly command line.  (Personally, I think GUIs
are great for running shells.)

If there were enough of a market consisting of users who (a) are
comfortable using a command line, but (b) aren't comfortable with
names like "grep" and "man", surely someone would have catered to
that market by now.  (Perhaps Midnight Commander comes close, but
I don't use it myself.)

[snip]

> But I do alias 'ls' to show all the sort-of hidden files.
> Hiding files that start with "." is just plain stupid.

So do I.  (Actually, I alias "l" to "ls -AF".)

But the idea is that there needs to be *some* mechanism for hiding
files that users normally shouldn't concern themselves with.  Unix
chose the convention of giving such files names starting with '.'.
Personally, I like to see everything that's there (and I trust myself
not to clobber anything I shouldn't).

The alternative to hiding "." files is either always to show
everything (which is likely to confuse some users), or to use a
different mechanism (maybe a metadata bit in the filesystem).  It
would be nice if the mechanism were more uniform, and distinguished
"." and ".." (which are fundamental to the structure of the file
system) vs. other dot files.

[snip]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Interpretation of extensions different from Unix/Linux?

[Robert A Duff]

Keith Thompson <kst-u@mib.org> writes:

> There shouldn't be any need for your Grandmother to change anything.
> If there's a better set of names for the basic commands ("search"
> rather than "grep", and so on), it's easy enough for someone to
> do all that work *once* and let everyone else, including your
> Grandmother, take advantage of it.
>
> The trend for user-friendly Unix-like systems seems to be to do
> everything through a GUI environment, where the command-line tools
> aren't visible at all unless you ask for them.  That's what I'd
> expect someone's stereotypical Grandmother to do.  A non-programmer
> user probably needs a way to avoid the command-line shell altogether,
> not just a more friendly command line.  (Personally, I think GUIs
> are great for running shells.)

OK, you're right, please let me withdraw my "Grandmother" comment.  ;-)

I still think "grep" is a stupid name.  But I don't want to change it.

Of course I know how to change it.  I can add an 'alias' or a script
that's called "search" or something.  But then we have two names for the
same thing -- that adds complexity.  And I still need to understand
shell scripts that call "grep".  Better to have one stupid name than two
names.  Or I could "mv /bin/grep /bin/search".  That would be even
stupider -- there's only one name, and my new scripts can use it, but my
old scripts, and everybody else's scripts, would be broken.

So I'm not seriously suggesting that "grep" should be renamed now.
Nonetheless, I claim it was a stupid decision to call it "grep"
in the first place.

> If there were enough of a market consisting of users who (a) are
> comfortable using a command line, but (b) aren't comfortable with
> names like "grep" and "man", surely someone would have catered to
> that market by now.  (Perhaps Midnight Commander comes close, but
> I don't use it myself.)

No idea what "Midnight Commander" is.

>> But I do alias 'ls' to show all the sort-of hidden files.
>> Hiding files that start with "." is just plain stupid.
>
> So do I.  (Actually, I alias "l" to "ls -AF".)
>
> But the idea is that there needs to be *some* mechanism for hiding
> files that users normally shouldn't concern themselves with.

Hmm.  I have a file called ".cshrc" (another stupid name, by the way),
which I certainly DO need to concern myself with.  I'm annoyed that "ls"
doesn't show it, which is why I have (similarly to you):

    alias ls ls -AFC
    alias l ls

Anyway, I think the whole idea of sort-of-hidden files is broken and
unnecessary.  Sure, if I accidentally delete .cshrc, I'll mess things
up.  But the same is true of many non-hidden files (such as the
system.ads in my GNAT distribution, or the /etc/passwd file, or...).
Other mechanisms (file protections, backups, for ex.) protect me from
that sort of thing.

- Bob

Re: Interpretation of extensions different from Unix/Linux?

[Anders Wirzenius]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

>
> I still think "grep" is a stupid name.  But I don't want to change it.
>
> Of course I know how to change it.  I can add an 'alias' or a script
> that's called "search" or something.  But then we have two names for the
> same thing -- that adds complexity.  And I still need to understand
> shell scripts that call "grep".  Better to have one stupid name than two
> names.  Or I could "mv /bin/grep /bin/search".  That would be even
> stupider -- there's only one name, and my new scripts can use it, but my
> old scripts, and everybody else's scripts, would be broken.
>
> So I'm not seriously suggesting that "grep" should be renamed now.
> Nonetheless, I claim it was a stupid decision to call it "grep"
> in the first place.
>

FWIW (2 cents, perhaps):
There is a Swedish word: greppa, which translates to grasp or
grab in English. For a Swedish speaking person the 'grep' does
not sound then that stupid.

-- 
Anders

Re: Interpretation of extensions different from Unix/Linux?

[Robert A Duff]

Anders Wirzenius <anders@no.email.thanks.invalid> writes:

> FWIW (2 cents, perhaps):
> There is a Swedish word: greppa, which translates to grasp or
> grab in English. For a Swedish speaking person the 'grep' does
> not sound then that stupid.

Interesting.  ;-)

- Bob

Re: Interpretation of extensions different from Unix/Linux?

[Stephen Leake]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> Robert A Duff wrote:
>
>> Thank you, Keith, for explaining and summarizing all these details.
>> It matches my understanding of Unix behavior.  Unix shell's
>> behavior, that is -- it's not built in to the Unix OS, except by
>> convention and culture.
>
> A unix system has to have a "/bin/sh" program which works like this,
> to be a unix system.  It is simply a part of the standard.

Which standard is that?

Maybe you mean POSIX. Windows is POSIX compliant, according to
Microsoft. Otherwise they wouldn't be able to sell it to the US
government.

Gnu bash provides a POSIX mode, and it runs on many operating systems.

"unix" is _not_ a standard.

-- 
-- Stephe