Re: Interpretation of extensions different from Unix/Linux?

"Randy Brukardt" <randy@xxxxxxxxxxxxxx> writes:
"vlc" <just.another.spam.account@xxxxxxxxxxxxxx> wrote in message
news:8a5f3b98-1c5a-4d47-aca7-e106d1223fa9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...
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@xxxxxxx <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"
.

Relevant Pages

  • Re: Ada.Command_Line and wildcards
    ... Shell uses some special characters to make it ... parameters, than to force expansion. ... It is wrong because it does not clearly define what is a "command line," ... The wildcard expansion is a service provided by ...
    (comp.lang.ada)
  • Re: find command usage quotes
    ... so findsees a command line such ... Wildcard pattern hidden from the shell, but any environment variables ...
    (linux.redhat)
  • Re: Lisp/Unix impedance [a programming challenge]
    ... >> I don't think you even have any idea what Unix is. ... nice if using a command shell under Windows didn't feel like working ... with blinders on a command line that's been made deliberately hard to ... An Emacs over a *nix shell is pretty usable at controlling ...
    (comp.lang.lisp)
  • Re: vi horizontal split screen
    ... Command line recall and edit, which I had on DOS, was worth the price of admission by itself. ... The script language was designed to look like C for the benefit of C programmers working on *nix, but you still needed to know Bourne syntax, because all the scripts that controlled Unix itself were in the Bourne shell language. ... Emacs is not it. ... The default Emacs keystrokes have the same basic characteristic as the default vi keystrokes and the default WordStar command set: they are keyboard independent. ...
    (comp.editors)
  • Re: "Under z/OS Unix"
    ... task is running under have UNIX credentials. ... Unix command binaries can be invoked by BPXBATCH/COZBATCH (see ... The former is then referring to the shell built in commands and the ... I'd prefer "The shell can be run interactively, via TSO OMVS..." ...
    (bit.listserv.ibm-main)