Ada.Command_Line and wildcards

Ada.Command_Line and wildcards

[Gautier]

Hello!
I was surprised to see Ada.Command_Line in GNAT (3.15p and 2006 GPL) serving 
the command-line argument "*.adb" indeed as N arguments, the list of files 
with an "adb" extension!
ObjectAda gives the argument as-is.
Who is right then ?
It's a annoying if the wildcard expansion is done a priori, because I would 
like to have it done by Ada.Directories, for a generic command-line tool...
Here, the test program:

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

procedure Args is
begin
   for I in 1..Argument_Count loop
     Put_Line(Integer'Image(I) & " [" & Argument(I) & ']');
   end loop;
   Put("Press Enter"); Skip_Line;
end;
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Ada.Command_Line and wildcards

[(see below)]

On 21/2/07 20:43, in article 45dcaed8_6@news.bluewin.ch, "Gautier"
<gautier@fakeaddress.nil> wrote:

> Hello!
> I was surprised to see Ada.Command_Line in GNAT (3.15p and 2006 GPL) serving
> the command-line argument "*.adb" indeed as N arguments, the list of files
> with an "adb" extension!
> ObjectAda gives the argument as-is.
> Who is right then ?

This is an OS (shell) issue, surely?

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

Re: Ada.Command_Line and wildcards

[Dr. Adrian Wrigley]

On Wed, 21 Feb 2007 21:43:41 +0100, Gautier wrote:

> Hello!
> I was surprised to see Ada.Command_Line in GNAT (3.15p and 2006 GPL) serving 
> the command-line argument "*.adb" indeed as N arguments, the list of files 
> with an "adb" extension!

Try:

Args "*.adb"

does this give what you expect?
--
Adrian

Re: Ada.Command_Line and wildcards

[Marc A. Criley]

(see below) wrote:

> On 21/2/07 20:43, in article 45dcaed8_6@news.bluewin.ch, "Gautier"
> <gautier@fakeaddress.nil> wrote:
> 
>> Hello!
>> I was surprised to see Ada.Command_Line in GNAT (3.15p and 2006 GPL)
>> serving the command-line argument "*.adb" indeed as N arguments, the list
>> of files with an "adb" extension!
>> ObjectAda gives the argument as-is.
>> Who is right then ?
> 
> This is an OS (shell) issue, surely?

I was surprised as well, and I took it to be a shell issue as well.

I found that just wrapping the wildcard in quotes as Adrian suggested passes
it in as typed (with tcsh on Linux, anyway).  I've got Avatox able to
accept either the wildcard or the list of files.

-- 
-- Marc A. Criley
-- www.mckae.com
-- Avatox - DTraq - XIA - XML EZ Out

Re: Ada.Command_Line and wildcards

[Adam Beneschan]

On Feb 21, 12:59 pm, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
> On 21/2/07 20:43, in article 45dcaed...@news.bluewin.ch, "Gautier"
>
> <gaut...@fakeaddress.nil> wrote:
> > Hello!
> > I was surprised to see Ada.Command_Line in GNAT (3.15p and 2006 GPL) serving
> > the command-line argument "*.adb" indeed as N arguments, the list of files
> > with an "adb" extension!
> > ObjectAda gives the argument as-is.
> > Who is right then ?
>
> This is an OS (shell) issue, surely?

If it were a shell issue, how could ObjectAda possibly get it right?
(The shell would expand the *.adb and ObjectAda would never see an
asterisk.)

                   -- Adam

Re: Ada.Command_Line and wildcards

[(see below)]

On 22/2/07 02:08, in article
1172110094.571778.6600@k78g2000cwa.googlegroups.com, "Adam Beneschan"
<adam@irvine.com> wrote:

> On Feb 21, 12:59 pm, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>> On 21/2/07 20:43, in article 45dcaed...@news.bluewin.ch, "Gautier"
>> 
>> <gaut...@fakeaddress.nil> wrote:
>>> Hello!
>>> I was surprised to see Ada.Command_Line in GNAT (3.15p and 2006 GPL) serving
>>> the command-line argument "*.adb" indeed as N arguments, the list of files
>>> with an "adb" extension!
>>> ObjectAda gives the argument as-is.
>>> Who is right then ?
>> 
>> This is an OS (shell) issue, surely?
> 
> If it were a shell issue, how could ObjectAda possibly get it right?
> (The shell would expand the *.adb and ObjectAda would never see an
> asterisk.)

Different shell? 
We have not been told which OS was used in each case.

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

Re: Ada.Command_Line and wildcards

[gautier_niouzes]

> This is an OS (shell) issue, surely?

Alas, no.
I forgot to mention: I tested both programs on both Windows 98 and XP.
In both systems, the OA-compiled program gives "*.adb" and the GNAT-
compiled the list of files with ".adb" extension.
To Adrian, enclosing with '"' works, thanks, but then the syntax
differs from the usual one for a command-line tool...
I am just suprised by the GNAT behaviour, for two reasons:
 - I did not find (or missed) something about it in the RM (95)
 - there is also a GNAT.Command_Line that explicitely intends to do
wildcard expansions; so why also GNAT's Ada.Command_Line should do it,
silently ?

G.

Re: Ada.Command_Line and wildcards

[Simon Wright]

gautier_niouzes@hotmail.com writes:

> To Adrian, enclosing with '"' works, thanks, but then the syntax
> differs from the usual one for a command-line tool...

That does depend on your OS/shell! On any Unix-like system, using any
reasonable shell, one would expect *.adb to be expanded by the shell
and variously "*.adb" '*.adb' \*.adb not to be. Indeed, the standard
Unix 'find' command is often used like this ..

  $ find . -name \*.o

Re: Ada.Command_Line and wildcards

[Alex R. Mosteo]

gautier_niouzes@hotmail.com wrote:

>> This is an OS (shell) issue, surely?
> 
> Alas, no.
> I forgot to mention: I tested both programs on both Windows 98 and XP.

It would be in unix. There, wildcard expansion is a shell matter. Windows only
half-faked it.

What I mean is that if your code is to be run outside of a windows platform,
you'll not see wildcards in your arguments (unless you quote them, as someone
else has pointed elsethread).

But if gnat is deliberately doing expansion to emulate unix behavior, I guess
that should be documented in windows platforms...

> In both systems, the OA-compiled program gives "*.adb" and the GNAT-
> compiled the list of files with ".adb" extension.
> To Adrian, enclosing with '"' works, thanks, but then the syntax
> differs from the usual one for a command-line tool...
> I am just suprised by the GNAT behaviour, for two reasons:
>  - I did not find (or missed) something about it in the RM (95)
>  - there is also a GNAT.Command_Line that explicitely intends to do
> wildcard expansions; so why also GNAT's Ada.Command_Line should do it,
> silently ?
> 
> G.

Re: Ada.Command_Line and wildcards

[Jean-Pierre Rosen]

gautier_niouzes@hotmail.com a �crit :
>> This is an OS (shell) issue, surely?
> 
> Alas, no.
> I forgot to mention: I tested both programs on both Windows 98 and XP.
> In both systems, the OA-compiled program gives "*.adb" and the GNAT-
> compiled the list of files with ".adb" extension.
> To Adrian, enclosing with '"' works, thanks, but then the syntax
> differs from the usual one for a command-line tool...
> I am just suprised by the GNAT behaviour, for two reasons:
>  - I did not find (or missed) something about it in the RM (95)
>  - there is also a GNAT.Command_Line that explicitely intends to do
> wildcard expansions; so why also GNAT's Ada.Command_Line should do it,
> silently ?
> 
I think it is a gcc feature. Because gcc is often used to port Unix 
applications to Windows, the gcc library emulates Unix behaviour on windows.

Too bad that Unix behaviour was wrong in the first place...

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada.Command_Line and wildcards

[Maciej Sobczak]

Jean-Pierre Rosen wrote:

> Too bad that Unix behaviour was wrong in the first place...

I don't understand. Shell uses some special characters to make it easier 
for the user to type commands [1]. Wildcards are just an example. 
Consider this:

$ cat *.ads *.adb | wc -l > loc.txt

If you claim that * above should be passed "as is" to the program (cat), 
so that the program can figure out on itself what to do with it, then 
you might as well argue that the program should figure out *everything* 
above. Obviously, that wouldn't be funny.


[1] Shells can compete on how well they do this job.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Ada.Command_Line and wildcards

[Jean-Pierre Rosen]

Maciej Sobczak a �crit :
> Jean-Pierre Rosen wrote:
> 
>> Too bad that Unix behaviour was wrong in the first place...
> 
> I don't understand. Shell uses some special characters to make it easier 
> for the user to type commands [1]. Wildcards are just an example. 
> Consider this:
> 
> $ cat *.ads *.adb | wc -l > loc.txt
> 
> If you claim that * above should be passed "as is" to the program (cat), 
> so that the program can figure out on itself what to do with it, then 
> you might as well argue that the program should figure out *everything* 
> above. Obviously, that wouldn't be funny.
> 
I claim it would be easier to provide a function that expands 
parameters, than to force expansion. Or maybe just provide another 
function that provides the raw parameters.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada.Command_Line and wildcards

[Larry Kilgallen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

In article <d59kre.p4q.ln@hunter.axlog.fr>, Jean-Pierre Rosen <rosen@adalog.fr> writes:
> Maciej Sobczak a �crit :
>> Jean-Pierre Rosen wrote:
>> 
>>> Too bad that Unix behaviour was wrong in the first place...
>> 
>> I don't understand. Shell uses some special characters to make it easier 
>> for the user to type commands [1]. Wildcards are just an example. 
>> Consider this:
>> 
>> $ cat *.ads *.adb | wc -l > loc.txt
>> 
>> If you claim that * above should be passed "as is" to the program (cat), 
>> so that the program can figure out on itself what to do with it, then 
>> you might as well argue that the program should figure out *everything* 
>> above. Obviously, that wouldn't be funny.
>> 
> I claim it would be easier to provide a function that expands 
> parameters, than to force expansion. Or maybe just provide another 
> function that provides the raw parameters.

That is what VMS provides, and what one calls from DEC Ada on VMS.
Using the OS-provided code is essential, as interpreting rooted
directory multivalued logical names is just too complex for
private implementations.

Re: Ada.Command_Line and wildcards

[Ludovic Brenta]

Jean-Pierre Rosen  writes:
> Maciej Sobczak a écrit :
>> Jean-Pierre Rosen wrote:
>>
>>> Too bad that Unix behaviour was wrong in the first place...
>>
>> I don't understand. Shell uses some special characters to make it
>> easier for the user to type commands [1]. Wildcards are just an
>> example. Consider this:
>>
>> $ cat *.ads *.adb | wc -l > loc.txt
>>
>> If you claim that * above should be passed "as is" to the program
>> (cat), so that the program can figure out on itself what to do with
>> it, then you might as well argue that the program should figure out
>> *everything* above. Obviously, that wouldn't be funny.
>>
> I claim it would be easier to provide a function that expands
> parameters, than to force expansion. Or maybe just provide another
> function that provides the raw parameters.

There are three such "other functions":

$ cat '*.ads *.adb' | wc -l > loc.txt
$ cat "*.ads *.adb" | wc -l > loc.txt
$ cat \*.ads \*.adb | wc -l > loc.txt

So could you please explain why you think the Unix behaviour is
"wrong"?

-- 
Ludovic Brenta.

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On Thu, 22 Feb 2007 16:15:40 +0100, Ludovic Brenta wrote:

> Jean-Pierre Rosen  writes:
>> Maciej Sobczak a �crit :
>>> Jean-Pierre Rosen wrote:
>>>
>>>> Too bad that Unix behaviour was wrong in the first place...
>>>
>>> I don't understand. Shell uses some special characters to make it
>>> easier for the user to type commands [1]. Wildcards are just an
>>> example. Consider this:
>>>
>>> $ cat *.ads *.adb | wc -l > loc.txt
>>>
>>> If you claim that * above should be passed "as is" to the program
>>> (cat), so that the program can figure out on itself what to do with
>>> it, then you might as well argue that the program should figure out
>>> *everything* above. Obviously, that wouldn't be funny.
>>>
>> I claim it would be easier to provide a function that expands
>> parameters, than to force expansion. Or maybe just provide another
>> function that provides the raw parameters.
> 
> There are three such "other functions":
> 
> $ cat '*.ads *.adb' | wc -l > loc.txt
> $ cat "*.ads *.adb" | wc -l > loc.txt
> $ cat \*.ads \*.adb | wc -l > loc.txt
> 
> So could you please explain why you think the Unix behaviour is
> "wrong"?

It is wrong because it does not clearly define what is a "command line,"
which makes almost impossible for an application to handle (parse) "command
lines." One could try to argue that there is no need to do it at all, but
that is clearly not the case.

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

Re: Ada.Command_Line and wildcards

[Jean-Pierre Rosen]

Ludovic Brenta a écrit :
> There are three such "other functions":
> 
> $ cat '*.ads *.adb' | wc -l > loc.txt
> $ cat "*.ads *.adb" | wc -l > loc.txt
> $ cat \*.ads \*.adb | wc -l > loc.txt
> 
> So could you please explain why you think the Unix behaviour is
> "wrong"?
> 
No, that's from the user's side, not from the program's side. It should 
be up to the program to decide whether "*" is to be interpreted as a 
wild-card or not.

For example, I have a utility where I pass Ada unit names (not file 
names), but wildcarding is allowed for the unit names (handled by the 
program). If by chance I have a file that matches the wildcard in the 
current directory, I get an absolutely useless parameter. And I hate 
having to tell the user (even if I am the only known user of the program 
:-) that the parameters must be quoted.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada.Command_Line and wildcards

[Adam Beneschan]

On Feb 22, 3:19 am, Jean-Pierre Rosen <r...@adalog.fr> wrote:
> gautier_niou...@hotmail.com a écrit :>> This is an OS (shell) issue, surely?
>
> > Alas, no.
> > I forgot to mention: I tested both programs on both Windows 98 and XP.
> > In both systems, the OA-compiled program gives "*.adb" and the GNAT-
> > compiled the list of files with ".adb" extension.
> > To Adrian, enclosing with '"' works, thanks, but then the syntax
> > differs from the usual one for a command-line tool...
> > I am just suprised by the GNAT behaviour, for two reasons:
> >  - I did not find (or missed) something about it in the RM (95)
> >  - there is also a GNAT.Command_Line that explicitely intends to do
> > wildcard expansions; so why also GNAT's Ada.Command_Line should do it,
> > silently ?
>
> I think it is a gcc feature. Because gcc is often used to port Unix
> applications to Windows, the gcc library emulates Unix behaviour on windows.

This sounds right to me, based on my experience with GCC and Windows.
I didn't want to say anything myself until I had a chance to test it
further---but yes, I think that somewhere in the GCC library, in
whatever startup code gets executed to set up argc and argv before
calling main(), something in there expands wildcards.


> Too bad that Unix behaviour was wrong in the first place...

Sigh... this has been one of my pet peeves with Unix for a long time.
With other operating systems I've worked with, you can enter a command
like

   rename *.ads *.ada

for instance, to rename a bunch of files.  Unix makes this difficult.
(Yes, I know how to use "foreach" in csh... but still...)

                       -- Adam

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

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

> On Thu, 22 Feb 2007 16:15:40 +0100, Ludovic Brenta wrote:
>
>> Jean-Pierre Rosen  writes:
>>> Maciej Sobczak a �crit :
>>>> Jean-Pierre Rosen wrote:
>>>>
>>>>> Too bad that Unix behaviour was wrong in the first place...
>>>>
>>>> I don't understand. Shell uses some special characters to make it
>>>> easier for the user to type commands [1]. Wildcards are just an
>>>> example. Consider this:
>>>>
>>>> $ cat *.ads *.adb | wc -l > loc.txt
>>>>
>>>> If you claim that * above should be passed "as is" to the program
>>>> (cat), so that the program can figure out on itself what to do with
>>>> it, then you might as well argue that the program should figure out
>>>> *everything* above. Obviously, that wouldn't be funny.
>>>>
>>> I claim it would be easier to provide a function that expands
>>> parameters, than to force expansion. Or maybe just provide another
>>> function that provides the raw parameters.
>> 
>> There are three such "other functions":
>> 
>> $ cat '*.ads *.adb' | wc -l > loc.txt
>> $ cat "*.ads *.adb" | wc -l > loc.txt
>> $ cat \*.ads \*.adb | wc -l > loc.txt

Case (1) and (2) don't differ in this case. The difference between
case (2) and (3) has nothing to do with file name (wildcard) expansion
but rather how a given string is parsed into word.


>> So could you please explain why you think the Unix behaviour is
>> "wrong"?
>
> It is wrong because it does not clearly define what is a "command line,"
> which makes almost impossible for an application to handle (parse) "command
> lines." 

This is, forgive me, wrong. The "commandline" in Unix is a an array of
pointers to zero-terminated strings which itself is terminated by a
null pointer. Every application is free to interpret the command line
arguments as it likes. The wildcard expansion is a service provided by
a shell and depends on the shell used. Dito parsing a command line in
words. For that reason most applications don't bother to do wildcard
interprestation of file arguments themselves, but exceptions exist.

Putting the language to describe sets of filenames into the shell
makes sense inasfar as (a) there are user specfic preferences and (b)
it guarantees that at least that syntax is homgenously "supported" by
all tools. 

The disadvantage is that for programs directly exec'ed by other
programs, this mechanism is not available.

The unix philosophy of handling the passing of command line parameters
to the programs is, I think, time tested, but people might prefer
other ways to do it. But calling it "wrong" is outright nonsense.

Regards -- Markus


> One could try to argue that there is no need to do it at all, but
> that is clearly not the case.
>
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Ludovic Brenta a �crit :
>> There are three such "other functions":
>> $ cat '*.ads *.adb' | wc -l > loc.txt
>> $ cat "*.ads *.adb" | wc -l > loc.txt
>> $ cat \*.ads \*.adb | wc -l > loc.txt
>> So could you please explain why you think the Unix behaviour is
>> "wrong"?
>>
> No, that's from the user's side, not from the program's side. It
> should be up to the program to decide whether "*" is to be interpreted
> as a wild-card or not.

Actually it ist. In 

  find . -name '*.txt' 

the program 'find' decides to do the wildcard expansion on '*'. The
wildcard expansion the shell does, is just an additional service. You
can just not use it, by enclosing every word on the command line in
"'".

>
> For example, I have a utility where I pass Ada unit names (not file
> names), but wildcarding is allowed for the unit names (handled by the
> program). If by chance I have a file that matches the wildcard in the
> current directory, I get an absolutely useless parameter. And I hate
> having to tell the user (even if I am the only known user of the
> program :-) that the parameters must be quoted.

That depends on the shell the user is using. Actually using a unix v5
or v6 shell will avoid the expansion :-). Seriously: If the user
doesn't know how his/her shell works and that the shell contains a
special sub-language to specify file sets it's not the program's nor
the shell's fault: The user simply doesn't know his tools. By the same
token we could forbid variable expansion in the shell, because the
user might want to use filenames with '$'s in the (like
my-$s-earned.tbl) and cannot be bother to learn to quote in this case.

For the real hard cases I suggest to write a specialized interactive
"shell" around you toolset (some modula compilers had such interactive
modes, I think). The the user than cannot by accident type e.g. 'cat'
and wait until infinity since he doesn't know what he did there.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

"Adam Beneschan" <adam@irvine.com> writes:

> On Feb 22, 3:19 am, Jean-Pierre Rosen <r...@adalog.fr> wrote:
>> gautier_niou...@hotmail.com a �crit :>> This is an OS (shell) issue, surely?
>>
>> > Alas, no.
>> > I forgot to mention: I tested both programs on both Windows 98 and XP.
>> > In both systems, the OA-compiled program gives "*.adb" and the GNAT-
>> > compiled the list of files with ".adb" extension.
>> > To Adrian, enclosing with '"' works, thanks, but then the syntax
>> > differs from the usual one for a command-line tool...
>> > I am just suprised by the GNAT behaviour, for two reasons:
>> >  - I did not find (or missed) something about it in the RM (95)
>> >  - there is also a GNAT.Command_Line that explicitely intends to do
>> > wildcard expansions; so why also GNAT's Ada.Command_Line should do it,
>> > silently ?
>>
>> I think it is a gcc feature. Because gcc is often used to port Unix
>> applications to Windows, the gcc library emulates Unix behaviour on windows.
>
> This sounds right to me, based on my experience with GCC and Windows.
> I didn't want to say anything myself until I had a chance to test it
> further---but yes, I think that somewhere in the GCC library, in
> whatever startup code gets executed to set up argc and argv before
> calling main(), something in there expands wildcards.
>
>
>> Too bad that Unix behaviour was wrong in the first place...
>
> Sigh... this has been one of my pet peeves with Unix for a long time.
> With other operating systems I've worked with, you can enter a command
> like
>
>    rename *.ads *.ada

I've seen tools for unix that worked like this, just use quoted or
different wildcards:

  xmove  foo/%.txt bar/baz/old-%.bak


(the name was not xmove). 

So you don't have a pet peeve with Unix, but just with the specific
way 'mv' works (it doesn't bothe with renaming rules, just takes N
sources and 1 destination and that's it).


> for instance, to rename a bunch of files.  Unix makes this difficult.
> (Yes, I know how to use "foreach" in csh... but still...)

The interesting thing is that most people need this function so rarely
that they don't bother to find the tool, or type 'man rename' (on
Debian that gives me a shell tool that works similarly ) but just use
a loop in the shell.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Niklas Holsti]

Markus E Leypold wrote:
> Jean-Pierre Rosen <rosen@adalog.fr> writes:
> 
> 
>>Ludovic Brenta a �crit :
>>
>>>There are three such "other functions":
>>>$ cat '*.ads *.adb' | wc -l > loc.txt
>>>$ cat "*.ads *.adb" | wc -l > loc.txt
>>>$ cat \*.ads \*.adb | wc -l > loc.txt
>>>So could you please explain why you think the Unix behaviour is
>>>"wrong"?
>>>
>>
>>No, that's from the user's side, not from the program's side. It
>>should be up to the program to decide whether "*" is to be interpreted
>>as a wild-card or not.
> 
> 
> Actually it ist. In 
> 
>   find . -name '*.txt' 
> 
> the program 'find' decides to do the wildcard expansion on '*'. The
> wildcard expansion the shell does, is just an additional service. You
> can just not use it, by enclosing every word on the command line in
> "'".

Moreover the shell's use of pathname expansion is usually optional and 
user-configurable. For example, under the "bash" shell the command "set 
-f" turns pathname expansion off, so all wildcard characters in later 
commands are passed unexpanded into command arguments even if not quoted.

I agree with Markus that the Unix-style division of command-line 
management between the shell and the program is sensible. Of course an 
application should also be able to scan directories to find files with 
names that match a given pattern. In Ada 2005 the new predefined package 
Ada.Directories provides the tools for this.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On Thu, 22 Feb 2007 19:26:56 +0100, Markus E Leypold wrote:

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

> Putting the language to describe sets of filenames into the shell
> makes sense inasfar as (a) there are user specfic preferences and (b)
> it guarantees that at least that syntax is homgenously "supported" by
> all tools. 
> 
> The disadvantage is that for programs directly exec'ed by other
> programs, this mechanism is not available.

So does it (a shell language) make sense or does it not? (:-))

> The unix philosophy of handling the passing of command line parameters
> to the programs is, I think, time tested,

Really? How does this philosophy apply to modern software? Let's take
internet browser, compiler IDE, office tools, database as typical
examples...

> but people might prefer
> other ways to do it. But calling it "wrong" is outright nonsense.

Let's say it is inconsistent. Wrong was to follow that philosophy.

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

Re: Ada.Command_Line and wildcards

[Gautier]

Jean-Pierre Rosen:

> I think it is a gcc feature. Because gcc is often used to port Unix 
> applications to Windows, the gcc library emulates Unix behaviour on 
> windows.

I seems so (after some search on the Web with keywords like "gcc argv command 
line wildcard expansion"). In that case a gcc executable also emulates a 
feature of a kind of a hypothetic, UNIX-like shell calling it... Bizarre.
Indeed, I have nothing against it, but if I want to call my tool that way:

mytool -r *.adb

(-r meaning recurse into directories)

it just won't work. But nothing to worry too much about. Thank to all for the 
comments, and please do not hurt each other in OS-holy wars about this little 
topic. Happy programming!
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Ada.Command_Line and wildcards

[Simon Wright]

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

> On Thu, 22 Feb 2007 19:26:56 +0100, Markus E Leypold wrote:

>> The unix philosophy of handling the passing of command line
>> parameters to the programs is, I think, time tested,
>
> Really? How does this philosophy apply to modern software? Let's
> take internet browser, compiler IDE, office tools, database as
> typical examples...

If they take command line parameters to launch -- and many of them do
-- they will at that point behave like any other command line
program. And after that their behaviour is surely irrelevant to
this discussion?

Re: Ada.Command_Line and wildcards

[Randy Brukardt]

"Markus E Leypold"
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in
message news:a7ps82yrax.fsf@hod.lan.m-e-leypold.de...
...
> Actually it ist. In
>
>   find . -name '*.txt'
>
> the program 'find' decides to do the wildcard expansion on '*'. The
> wildcard expansion the shell does, is just an additional service. You
> can just not use it, by enclosing every word on the command line in
> "'".

You're missing the point. The "Find" program can't decide anything; it has
to require the user to quote everything. If the user doesn't quote it,
they'll get garbage (precisely why I could never remember how find was
supposed to work on Unix - I ended up writing shell scripts to cover up this
obnoxious behavior.

It is never sensible to force clients to be aware of things that they should
not logically have to care about. Whether the shell or the program wants to
expand file names is completely irrelevant to the user - it simply should
not matter to the use of a program.

This is exactly the same reason that anonymous access types are not a usable
replacement 'in out' parameters in functions. Using them requires the client
to do various handstands (use 'Access, declare the object as aliased) for no
benefit at all to the client. That is silly; it breaks encapsulation.

Thus I conclude that the Unix shell behavior (especially as it is not
consistent, in that an exec'd program doesn't get the benefit, so the
application has to be prepared to handle wildcards anyway -- or be stupidly
fragile) is harmful, as it makes the user care about irrelevant
implementation details.

                               Randy.

Re: Ada.Command_Line and wildcards

[Robert A Duff]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Too bad that Unix behaviour was wrong in the first place...

I agree with JP Rosen, here.  The way wildcards work in Unix is
completely broken.  (Not that I'm advocating Windows instead!)

I type:

    grep -i blah *.ad?

and I get:

    Arguments too long.

Yuck -- bad design!

And there's no wildcard that means "all subdirectories, recursively".

So we're stuck with kludgery like "find" and "xargs".  Yuck.

If I meant to type:

    mv some_dir/*.ada .

But I forgot the ".", so I accidentally typed:

    mv some_dir/*.ada

I get an error message (OK).  Except in the case where there happen to
be exactly two files ending in .ada in that directory -- then the
command destroys one of them!  Yuck.

And I can't create a command that works like this:

    search *.ada "some string"

That's why the arguments of "grep" are backwards (search-string first,
then the file names -- I've gotten so used to it that I hardly remember
that it is indeed backwards).  Yuck.

If I type:

    rm *.junk blah.*

and there happens to be a file called blah.junk, I get an annoying error
message.  Why?  I asked to delete that file!

The problem is not so much that the shell does the wildcard expansions.
The problem is that it's all based on textual substition.  Semantics
based on textual substition is just plain confusing.  What looks like
one argument (e.g. *.ada) ought to be in fact one argument (albeit a
list of many files).

- Bob

Re: Ada.Command_Line and wildcards

[Jeffrey R. Carter]

Randy Brukardt wrote:
> 
> This is exactly the same reason that anonymous access types are not a usable
> replacement 'in out' parameters in functions. Using them requires the client
> to do various handstands (use 'Access, declare the object as aliased) for no
> benefit at all to the client. That is silly; it breaks encapsulation.

In other words, they're just like C!

-- 
Jeff Carter
"Your mother was a hamster and your father smelt of elderberries."
Monty Python & the Holy Grail
06

Re: Ada.Command_Line and wildcards

[Anders Wirzenius]

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

> 
> Thus I conclude that the Unix shell behavior (especially as it is not
> consistent, in that an exec'd program doesn't get the benefit, so the
> application has to be prepared to handle wildcards anyway -- or be stupidly
> fragile) is harmful, as it makes the user care about irrelevant
> implementation details.
> 
>                                Randy.

... so one can ask why the design was not done the opposite way:
If you want to have the shell to expand, use an option (like find
-x *.adb), else the parameter is passed as such to the
application.

-- 
Anders

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On Thu, 22 Feb 2007 20:38:37 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Thu, 22 Feb 2007 19:26:56 +0100, Markus E Leypold wrote:
> 
>>> The unix philosophy of handling the passing of command line
>>> parameters to the programs is, I think, time tested,
>>
>> Really? How does this philosophy apply to modern software? Let's
>> take internet browser, compiler IDE, office tools, database as
>> typical examples...
> 
> If they take command line parameters to launch -- and many of them do
> -- they will at that point behave like any other command line
> program. And after that their behaviour is surely irrelevant to
> this discussion?

Isn't it the behavior which is supposed to be controlled by the command
line? What else is the command line "philosophy" for?

(Obviously, any more or less complex behavior cannot be controlled by this
way. Secondly, that little what could, still does not fit into the pattern
of shell's parsing.)

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

Re: Ada.Command_Line and wildcards

[Jacob Sparre Andersen]

Randy Brukardt wrote:

> You're missing the point. The "Find" program can't decide anything;
> it has to require the user to quote everything.

That depends on the user's choice of shell.  But it is of course true
for a POSIX compliant shell.

> It is never sensible to force clients to be aware of things that
> they should not logically have to care about. Whether the shell or
> the program wants to expand file names is completely irrelevant to
> the user - it simply should not matter to the use of a program.

But if the programs do the expansion, you can be certain that the
expansion will differ from program to program.  Wouldn't that be
_much_ more inconsistent than having known, uniform rules?  (even if
you don't like them)

> Thus I conclude that the Unix shell behavior (especially as it is
> not consistent, in that an exec'd program doesn't get the benefit,
> so the application has to be prepared to handle wildcards anyway --
> or be stupidly fragile) is harmful, as it makes the user care about
> irrelevant implementation details.

But an exec'ed program is not started from a shell.  If you want to
start it from a shell, you use the system() function - and then you
_do_ get proper file name expansion.

Greetings,

Jacob

PS: I do agree that expanding patterns in Ada.Command_Line on
    non-POSIX operating systems, to emulate a POSIX shell is a bad
    idea.
-- 
�But you have to be a bit wary of a ship that collects
 snowflakes.�                                  -- Diziet Sma

Re: Ada.Command_Line and wildcards

[Jean-Pierre Rosen]

Markus E Leypold a �crit :
> That depends on the shell the user is using. 
That's exactly the problem. I'm just saying that the program should be 
able to decide how to interpret its parameters. You are perfectly 
welcome to not share that opinion.

> For the real hard cases I suggest to write a specialized interactive
> "shell" around you toolset (some modula compilers had such interactive
> modes, I think). The the user than cannot by accident type e.g. 'cat'
> and wait until infinity since he doesn't know what he did there.
> 
Did that, I have an interactive mode. I also have a command-line mode, 
and I would precisely prefer that they work the same!

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada.Command_Line and wildcards

[Jacob Sparre Andersen]

Robert A Duff wrote:

> And there's no wildcard that means "all subdirectories, recursively".

Not in POSIX, but at least one of the newer shells (Zsh) has it: **/*.ad[sb]

> So we're stuck with kludgery like "find" and "xargs".

And the untyped-ness of pipes.

> And I can't create a command that works like this:
>
>     search *.ada "some string"

Why not?

> If I type:
>
>     rm *.junk blah.*
>
> and there happens to be a file called blah.junk, I get an annoying
> error message.  Why?  I asked to delete that file!

I consider that a bug in "rm".  But it would be slightly less
efficient to make "rm" keep track of which files it already has
unlinked.

> The problem is not so much that the shell does the wildcard
> expansions.  The problem is that it's all based on textual
> substition.  Semantics based on textual substition is just plain
> confusing.  What looks like one argument (e.g. *.ada) ought to be in
> fact one argument (albeit a list of many files).

I think you may be right about this.  But who feels like creating a
better shell?  Preferably also with typed pipes.

Greetings,

Jacob
-- 
"I just might be wrong."

Re: Ada.Command_Line and wildcards

[Jacob Sparre Andersen]

Jean-Pierre Rosen wrote:

> Did that, I have an interactive mode. I also have a command-line
> mode, and I would precisely prefer that they work the same!

You can't get that.  That would require that _you_ controlled which
shells your users use to run your program from.  Even on a Microsoft
operating system, you haven't got that much control.

Actually it might be possible.  Isn't there some way to ask which
process is the parent of another process?  You could simply make the
program stop with an error message, if the parent process isn't a
conforming shell.

Greetings,

Jacob
-- 
"In space, no-one can press CTRL-ALT-DEL"
                                        -- An Ada programmer

Re: Ada.Command_Line and wildcards

[Rob Norris]

On 22 Feb 2007 09:07:52 -0800, "Adam Beneschan" <adam@irvine.com> wrote:


>Sigh... this has been one of my pet peeves with Unix for a long time.
>With other operating systems I've worked with, you can enter a command
>like
>
>   rename *.ads *.ada
>
>for instance, to rename a bunch of files.  Unix makes this difficult.
>(Yes, I know how to use "foreach" in csh... but still...)
>
>                       -- Adam

Going off topic a bit..

On my Debian system the rename command takes a perl command, then the files you want to apply it to.
rename s/ads/ada/ *ads

Redhat ones only have substition command so (i think):

rename ads ada *ads

Re: Ada.Command_Line and wildcards

[Jean-Pierre Rosen]

Jacob Sparre Andersen a �crit :
> But if the programs do the expansion, you can be certain that the
> expansion will differ from program to program.  
Why? Assume that your OS provides a function for doing the expansion.


-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada.Command_Line and wildcards

[brian.b.mcguinness]

On Feb 22, 12:07 pm, "Adam Beneschan" <a...@irvine.com> wrote:
> On Feb 22, 3:19 am, Jean-Pierre Rosen <r...@adalog.fr> wrote:
>
> Sigh... this has been one of my pet peeves with Unix for a long time.
> With other operating systems I've worked with, you can enter a command
> like
>
>    rename *.ads *.ada
>
> for instance, to rename a bunch of files.  Unix makes this difficult.
> (Yes, I know how to use "foreach" in csh... but still...)
>
>                        -- Adam

The Unix solution is more compliocated, but also more flexible.  For
example, I often do something like this:

for FILE in *; do mv "$FILE" $(echo $FILE | sed 's/ /_/g'); done

to replace blanks in file names with underscores.

I suppose that one could get the advantages of both the Unix and
Windows approaches by reversing the usual Unix approach and having
the user explicitly request expansions where desired, e.g.

mv @(*.txt) dest

to move all *.txt files to dest.

--- Brian

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Fri, 2007-02-23 at 05:28 -0800, brian.b.mcguinness@lmco.com wrote:

> for FILE in *; do mv "$FILE" $(echo $FILE | sed 's/ /_/g'); done

This fails in a case Bob has mentioned, viz. when the
*-expanded list gets too long for the shell. 

A "simple" alternative without wildcards is, in this case,

$ ls | while read FILE; do mv "$FILE" ... ; done

Re: Ada.Command_Line and wildcards

[Larry Kilgallen]

In article <wcc1wkhlln0.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Jean-Pierre Rosen <rosen@adalog.fr> writes:
> 
>> Too bad that Unix behaviour was wrong in the first place...
> 
> I agree with JP Rosen, here.  The way wildcards work in Unix is
> completely broken.  (Not that I'm advocating Windows instead!)

Why would we assume there was only a single alternative to Unix ?

Re: Ada.Command_Line and wildcards

[Adam Beneschan]

On Feb 22, 5:15 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Jean-Pierre Rosen <r...@adalog.fr> writes:
> > Too bad that Unix behaviour was wrong in the first place...
>
> I agree with JP Rosen, here.  The way wildcards work in Unix is
> completely broken.  (Not that I'm advocating Windows instead!)
>
> I type:
>
>     grep -i blah *.ad?
>
> and I get:
>
>     Arguments too long.
>
> Yuck -- bad design!

This problem has a simple solution, though...  Increase the size of
the shell buffer used to hold the expansion!!

Well, that's how they keep solving it.  I still keep breaking it,
partly because I try to do really silly things like grep'ing tens of
thousands of old mail messages for somebody's name.  So I guess the
Unix/Linux/***x authors need to go back to their drawing boards and
figure out how to tack another zero onto the size of the buffer
allocation.

It would have made so much sense to have grep call an OS function to
retrieve the file names one at a time and search them all, and then no
huge buffer would be needed to hold all the filenames.

                         -- Adam

Re: Ada.Command_Line and wildcards

[Adam Beneschan]

On Feb 23, 5:28 am, brian.b.mcguinn...@lmco.com wrote:

> The Unix solution is more compliocated, but also more flexible.  For
> example, I often do something like this:
>
> for FILE in *; do mv "$FILE" $(echo $FILE | sed 's/ /_/g'); done
>
> to replace blanks in file names with underscores.

Flexibility is good, but it's no excuse for not providing simple,
intuitive solutions to simple tasks.  And certainly, if Unix worked
the way some of us would prefer, that would not prevent Unix from also
providing commands sucb as the above to handle less-simple cases.
This is another of my pet peeves, i.e. somebody trying to excuse a
hard-to-use user interface by talking about its "flexibility" or how
powerful it is.  That doesn't cut it, because there's no reason not to
provide both.  Other than laziness, that is.

                          -- Adam

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

On Feb 22, 8:15 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Yuck -- bad design!

The designers of UNIX didn't feel that it was necessary for every
program to incorporate a wildcard expander when that could be done
externally. Back then keeping programs small and simple was a virtue.

> And there's no wildcard that means "all subdirectories, recursively".

And no wildcard that means "all files that have changed since
yesterday".

There are an infinite number of things that you might want to specify.
Many of them won't have been thought of when the programs which could
benefit from them are written. That's why it's better to do these
things
externally, and just have one program to modify when you come up with
your new wildcards.

> So we're stuck with kludgery like "find" and "xargs".  Yuck.

I don't understand. Doesn't "find" have exactly the interface that you
claim to want?

> And I can't create a command that works like this:
>     search *.ada "some string"

Huh? Why in the world not? The program knows how many arguments it
has,
and it can get to the last one as easily as the first!

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

On Feb 23, 11:58 am, "Adam Beneschan" <a...@irvine.com> wrote:
> This problem has a simple solution, though...  Increase the size of
> the shell buffer used to hold the expansion!!

No, that's incorrect. Many versions of UNIX have an absolute limit on
the total size of the arguments that can be passed to a process about
to execute, and will fail the exec... system calls with an E2BIG error
if that size is exceeded. That's why "xargs" exists.

Re: Ada.Command_Line and wildcards

[Adam Beneschan]

On Feb 23, 11:12 am, "Hyman Rosen" <hyman.ro...@gmail.com> wrote:
> On Feb 23, 11:58 am, "Adam Beneschan" <a...@irvine.com> wrote:
>
> > This problem has a simple solution, though...  Increase the size of
> > the shell buffer used to hold the expansion!!
>
> No, that's incorrect. Many versions of UNIX have an absolute limit on
> the total size of the arguments that can be passed to a process about
> to execute, and will fail the exec... system calls with an E2BIG error
> if that size is exceeded.

No, what I meant is that they (the OS developers) increase this
absolute limit in the next version of Unix.  That's been my
experience.  Some time ago, I found that I couldn't use commands that
operate on N files in a certain directory.  Later, we'd get a new
version of the OS, and I found that I could now use those commands I
couldn't use before---but I couldn't use commands that operate on 4N
files, or 5N or whatever---I don't know the exact factor.  And this
pattern has repeated itself several times.  And it's still the same.
I can now include more files than I ever have before, but the number
still isn't infinite and still isn't large enough sometimes.

                         -- Adam

Re: Ada.Command_Line and wildcards

[Adam Beneschan]

On Feb 23, 11:04 am, "Hyman Rosen" <hyman.ro...@gmail.com> wrote:
> On Feb 22, 8:15 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>
> > Yuck -- bad design!
>
> The designers of UNIX didn't feel that it was necessary for every
> program to incorporate a wildcard expander when that could be done
> externally. Back then keeping programs small and simple was a virtue.
>
> > And there's no wildcard that means "all subdirectories, recursively".
>
> And no wildcard that means "all files that have changed since
> yesterday".
>
> There are an infinite number of things that you might want to specify.
> Many of them won't have been thought of when the programs which could
> benefit from them are written. That's why it's better to do these
> things
> externally, and just have one program to modify when you come up with
> your new wildcards.

But as has been said several times before, the OS could have provided
a service that could have been called iteratively to return the file
names, one at a time.  That's how VMS does it.  This arrangement would
solve both the problems you mention above---keeping the applications
small and simple, and allowing for new types of wildcards without
having to change the application.

                        -- Adam

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On 23 Feb 2007 11:30:22 -0800, Adam Beneschan wrote:

> But as has been said several times before, the OS could have provided
> a service that could have been called iteratively to return the file
> names, one at a time.  That's how VMS does it.  This arrangement would
> solve both the problems you mention above---keeping the applications
> small and simple, and allowing for new types of wildcards without
> having to change the application.

Even better it would be an OO (ADT) OS. The parameter of the application is
either a character string (command line) or a container of files (or other
objects). It cannot be both as in Unix, else it is a mess.

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

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

"Adam Beneschan" <adam@irvine.com> writes:

> On Feb 23, 11:04 am, "Hyman Rosen" <hyman.ro...@gmail.com> wrote:
>> On Feb 22, 8:15 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
>> wrote:
>>
>> > Yuck -- bad design!
>>
>> The designers of UNIX didn't feel that it was necessary for every
>> program to incorporate a wildcard expander when that could be done
>> externally. Back then keeping programs small and simple was a virtue.
>>
>> > And there's no wildcard that means "all subdirectories, recursively".
>>
>> And no wildcard that means "all files that have changed since
>> yesterday".
>>
>> There are an infinite number of things that you might want to specify.
>> Many of them won't have been thought of when the programs which could
>> benefit from them are written. That's why it's better to do these
>> things
>> externally, and just have one program to modify when you come up with
>> your new wildcards.
>
> But as has been said several times before, the OS could have provided
> a service that could have been called iteratively to return the file
> names, one at a time.  

Well, it does. It's called 'find' and pipe like this:

  find dir1 dir2 -name '*.ada' -size -5000 | command_that_reads_its_files_from_stdarg

It depends on the tool wether it supports reading its arguments from
stdin. You can always roll your own by providing an appropriate shell
script wrapper if it doesn't.

And if everything fails: Nobody _forbids_ your tool to expand the
command line arguments on its own.

> That's how VMS does it.  

So?

> This arrangement would solve both the problems you mention
> above---keeping the applications small and simple, and allowing for
> new types of wildcards without having to change the application.

See the solution with find and the option(s) to pass arguments and
lists in temporary files.

Regards -- Markus

typed pipes (was: Ada.Command_Line and wildcards)

[Björn Persson]

Jacob Sparre Andersen wrote:

> But who feels like creating a
> better shell?  Preferably also with typed pipes.

How do you want typed pipes to work? Do you mean that if the writing program
treats its standard output stream as a file of records, where each record
contains two signed 16-bit integers and an array of five booleans, then the
shell should force the reading program to treat its standard input stream
the same way?

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Ada.Command_Line and wildcards

[Björn Persson]

Adam Beneschan wrote:

> But as has been said several times before, the OS could have provided
> a service that could have been called iteratively to return the file
> names, one at a time.  That's how VMS does it.  This arrangement would
> solve both the problems you mention above---keeping the applications
> small and simple, and allowing for new types of wildcards without
> having to change the application.

It would keep applications small only with the help of dynamic linking,
which early Unix didn't have.

And I can assure you that there wouldn't be just one wildcard expansion
library. Different Unix vendors would have slightly different syntaxes,
making the same program behave differently on different Unixes. Then a
number of free software people would want to extend the syntax in various
ways, and would write their own alternate libraries. Programmers would
start using these alternate libraries, not only on Gnu based systems but on
all Unixes, and then the users would have zero chance of keeping track of
which pattern syntax to use for which program.

When the expansion is done in the shell, a user can choose one shell and
learn its syntax. If it were done in each application, all users would have
to use all the syntaxes. Command line syntaxes differ enough as it is.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Ada.Command_Line and wildcards

[Björn Persson]

Adam Beneschan wrote:

> It would have made so much sense to have grep call an OS function to
> retrieve the file names one at a time and search them all, and then no
> huge buffer would be needed to hold all the filenames.

grep --recursive 'some string' .

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Ada.Command_Line and wildcards

[Adam Beneschan]

On Feb 23, 5:19 pm, Björn Persson <spam-a...@nowhere.nil> wrote:
> Adam Beneschan wrote:
> > It would have made so much sense to have grep call an OS function to
> > retrieve the file names one at a time and search them all, and then no
> > huge buffer would be needed to hold all the filenames.
>
> grep --recursive 'some string' .

Well, that's intuitive.  To do a grep on a large number of files, use
--recursive.  I suppose that to solve Bob's problem where he would
like to go recursively into directories, he should try --lots-of-
files.

Of course there are solutions.  As it is, since all my mail message
file names are six-digit numbers, it's really easy to solve the
problem with "foreach".  The point isn't that we don't know how to do
it; the point is that some of us think that the fact that we have to
resort to kludges like "foreach" or "xargs" or "grep --recursive"
indicates that the design was inadequate in the first place.

                              -- Adam

Re: Ada.Command_Line and wildcards

[Martin Krischik]

Alex R. Mosteo wrote:

>> Alas, no.
>> I forgot to mention: I tested both programs on both Windows 98 and XP.
> 
> It would be in unix. There, wildcard expansion is a shell matter. Windows
> only half-faked it.

No, The VMS also won't expand wildcard. In fact Unix shells are pretty alone
here. And they got it wrong. Bot Dos and VMS will warn you on:

DEL *.*

but not on

DEL Some_File.Txt

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: typed pipes

[Dmitry A. Kazakov]

On Sat, 24 Feb 2007 01:18:50 GMT, Bj�rn Persson wrote:

> Jacob Sparre Andersen wrote:
> 
>> But who feels like creating a
>> better shell?  Preferably also with typed pipes.
> 
> How do you want typed pipes to work?

I don't know what Jacob meant, but a typed pipe in Ada terms would be a
protected object. The type of the object identifies which
functions/procedures/entries it has and the types of the parameters of.

> Do you mean that if the writing program
> treats its standard output stream as a file of records, where each record
> contains two signed 16-bit integers and an array of five booleans, then the
> shell should force the reading program to treat its standard input stream
> the same way?

No the shell should check if both participants use the pipe of the same
type [or same class, OK, Ada does not have classes of protected types, but
it obviously should]. When types are same the shell creates the pipe,
spawns both processes and passes the pipe to them.

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

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

"Adam Beneschan" <adam@irvine.com> writes:

> problem with "foreach".  The point isn't that we don't know how to do
> it; 

Wonderful. After some of your complaints about the Unix shell I
actually wondered if you really know how to use it.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Martin Krischik <krischik@users.sourceforge.net> writes:

> here. And they got it wrong. Bot Dos and VMS will warn you on:
            ^^^^^^^^^^^^^^^^^^^

Well, Martin, since you're so sure about that: On which criteria did
"they get it wrong"? Where are the specs against which the predicate
"right" can be tested?

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Larry Kilgallen]

In article <1495406.QZvfpqijrQ@linux1.krischik.com>, Martin Krischik <krischik@users.sourceforge.net> writes:
> Alex R. Mosteo wrote:
> 
>>> Alas, no.
>>> I forgot to mention: I tested both programs on both Windows 98 and XP.
>> 
>> It would be in unix. There, wildcard expansion is a shell matter. Windows
>> only half-faked it.
> 
> No, The VMS also won't expand wildcard. In fact Unix shells are pretty alone
> here. And they got it wrong. Bot Dos and VMS will warn you on:
> 
> DEL *.*
> 
> but not on
> 
> DEL Some_File.Txt

Actually, VMS will warn you about either of those, because the warning
is not about wildcards but about not having specified which version(s)
of the files should be deleted.  Adding ;* will avoid the warning.

In VMS the program calls a standard expansion routine to get each
relevant filespec one at a time, only if wildcard filespecs are the
goal.  The command:

	$ SEARCH MY_TEXT.DAT *.*

looks for the explicit string *.* in the file MY_TEXT.DAT without
any (misguided) attempt to expand wildcards.

Re: typed pipes

[Jacob Sparre Andersen]

Bj�rn Persson wrote:
> Jacob Sparre Andersen wrote:

>> Preferably also with typed pipes.
>
> How do you want typed pipes to work? Do you mean that if the writing
> program treats its standard output stream as a file of records,
> where each record contains two signed 16-bit integers and an array
> of five booleans, then the shell should force the reading program to
> treat its standard input stream the same way?

I am not sure if I would want the system to _force_ both ends of the
pipe to agree, but I would definitely want the reading end to be
_informed_ of what the writing end is doing.

But doing the Unchecked_Conversion once the data are inside the
reading process is probably the correct solution.

This could probably not be done on the shell level, since pipes are an
operating system feature, and not just a shell feature.

Greetings,

Jacob
-- 
�When Roman engineers built a bridge, they had to stand under it while
 the first legion marched across. If programmers today worked under
 similar ground rules, they might well find themselves getting much more
 interested in Ada!�                                     -- Robert Dewar

Re: Ada.Command_Line and wildcards

[Jacob Sparre Andersen]

Jean-Pierre Rosen skriva�i:
> Jacob Sparre Andersen a �crit :

>> But if the programs do the expansion, you can be certain that the
>> expansion will differ from program to program.
>
> Why? Assume that your OS provides a function for doing the
> expansion.

Because some programmers will prefer one of the available functions
for doing the expansion, and other programmers will prefer some of the
other available functions for doing the expansion.

Jacob
-- 
No trees were killed in the sending of this message.
However a large number of electrons were terribly inconvenienced.

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Sat, 2007-02-24 at 12:46 +0100, Markus E Leypold wrote:
> Martin Krischik <krischik@users.sourceforge.net> writes:
> 
> > here. And they got it wrong. Bot Dos and VMS will warn you on:
>             ^^^^^^^^^^^^^^^^^^^
> 
> [...] On which criteria did
> "they get it wrong"? Where are the specs against which the predicate
> "right" can be tested?

One criterion is the number of wildcard expansion surprises.
Not having to mark patterns as patterns (untyped, no syntax)
creates an immensely flexible and powerful ... mess.

$ echo *.ads   # argument text is a pattern
*.ads          #   output text is a pattern

$ echo *.adb   # argument text is a pattern
main.adb       #   output text is a file name

$ ls *.ads
ls: *.ads: No such file or directory

$ ls *.adb
main.adb

(On the surface, ls(1) and echo(1) aren't consistently
interpreting *.ads, one is reporting an error, the other
is reproducing input. "But that's as defined, you ...
If you can't be bothered to RTFM!")

Since Unix shells use mostly text to represent almost all 
information, the user is advised to remember text substitution
pitfalls like the one above. Shell programming, for all its
power, is like using Unchecked_Conversion by default, so to
speak. In case of errors then, keeping track can be quite tricky,
even more so when there is indirection, for example through
popular backtick evaluation, as in

$ foo=`echo .[a-z]*` ; some_cmd $foo ...

(run in a directory where there aren't any hidden files.)

Caveat scriptor, the computer isn't programmed to help us
here with type checking, OOD, etc..

That said, I'm looking forward to running Plan 9 again, on a
virtual machine :)

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <1495406.QZvfpqijrQ@linux1.krischik.com>, Martin Krischik <krischik@users.sourceforge.net> writes:
>> Alex R. Mosteo wrote:
>> 
>>>> Alas, no.
>>>> I forgot to mention: I tested both programs on both Windows 98 and XP.
>>> 
>>> It would be in unix. There, wildcard expansion is a shell matter. Windows
>>> only half-faked it.
>> 
>> No, The VMS also won't expand wildcard. In fact Unix shells are pretty alone
>> here. And they got it wrong. Bot Dos and VMS will warn you on:
>> 
>> DEL *.*
>> 
>> but not on
>> 
>> DEL Some_File.Txt
>
> Actually, VMS will warn you about either of those, because the warning
> is not about wildcards but about not having specified which version(s)
> of the files should be deleted.  Adding ;* will avoid the warning.
>
> In VMS the program calls a standard expansion routine to get each
> relevant filespec one at a time, only if wildcard filespecs are the
> goal.  The command:
>
> 	$ SEARCH MY_TEXT.DAT *.*
>
> looks for the explicit string *.* in the file MY_TEXT.DAT without
> any (misguided) attempt to expand wildcards.

So will

 grep '*.*' 'MY_TEXT.DAT'

(with the Bourne shell).

Understand that: This is no question of "how Unix handles the command
line" ore something like this, but simply a question of a specific
choice of syntax for "expand this as a wildcard against the file
system before passing the arguments" taken by the developers of a
specific (though rather standard) shell, the Bourne shell.

  '*.*' -> don't expand
  'abc' -> don't expand

   abc  -> expand
   *.*  -> expand

The confusion for people who don't know about the Bourne shell has it's
origin in 2 circumstances:

 (a) The syntax has been chosen in a way that the _absence_ of
     "quoting" indicates the desire to do wildcard expansion.

 (b) The expansion of abc is abc (which gives the impression to some
     people that expansion happens only under certain circumstances
     (like presence of *) and they complain about the necessity to
     quote under these circumstances. Wrong: They should quote always
     :-), if they don't desire expansion, it just happens that the
     expansion is often the identity.

[ There is a catch here, but I won't tell, yet :-) ]

Another possible choice would have been, to always quote (to hold
strings together, even if the contain spaces and such) and use special
syntax to force expansion

       "abc"  -> don't expand
       "a b"  -> don't expand
       "*.*"  -> don't expand

  glob("abc") -> expand
  glob("a b") -> expand
  glob("*.*") -> expand

This is what usual programming languages do, and perhaps would have
resulted in less confusion, but on the other side its awkward to type.

Actually I think it is exactly what scheme shell (scsh) does.


Regards -- Markus

Re: typed pipes

[Björn Persson]

Jacob Sparre Andersen wrote:

> I am not sure if I would want the system to _force_ both ends of the
> pipe to agree, but I would definitely want the reading end to be
> _informed_ of what the writing end is doing.
> 
> But doing the Unchecked_Conversion once the data are inside the
> reading process is probably the correct solution.
> 
> This could probably not be done on the shell level, since pipes are an
> operating system feature, and not just a shell feature.

No, it definitely couldn't be done in a Unix shell. It would require very
deep changes to how the kernel handles files, including changes to the
system calls. And if you had it for pipes you'd want it for disk files too,
which would affect the filesystems. I suspect that the resulting operating
system would be almost, but not quite, entirely unlike Unix.

And how could you make it work for all programming languages? Types are very
much a programming language concept. I suppose you could design it so that
an Ada program could communicate "type File_Record is -18 .. 7000;" to
another Ada program, while a C program would see "int16_t", but how would
you explain tagged types, discriminants and stuff to C? And then there are
other languages with types that can't be expressed in Ada.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Ada.Command_Line and wildcards

[Simon Wright]

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

> ... so one can ask why the design was not done the opposite way: If
> you want to have the shell to expand, use an option (like find -x
> *.adb), else the parameter is passed as such to the application.

That sounds a very odd design. The shell would have to parse the
command line to see if there was an option requiring expansion. And
what if -x already had a meaning to the program?

The Unix shell design seems quite clear -- unescaped wildcards get
expanded. Of course, it's not just '*' wildcards; expressions such as
*.ad[bs] or foo.{adb,ads} also have their place.

I think we ought to live with the shells the way they are -- it's true
of Ada, after all.

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Dear Georg, Dear all,

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Sat, 2007-02-24 at 12:46 +0100, Markus E Leypold wrote:
>> Martin Krischik <krischik@users.sourceforge.net> writes:
>> 
>> > here. And they got it wrong. Bot Dos and VMS will warn you on:
>>             ^^^^^^^^^^^^^^^^^^^
>> 
>> [...] On which criteria did
>> "they get it wrong"? Where are the specs against which the predicate
>> "right" can be tested?
>
> One criterion is the number of wildcard expansion surprises.
> Not having to mark patterns as patterns (untyped, no syntax)
> creates an immensely flexible and powerful ... mess.
>
> $ echo *.ads   # argument text is a pattern
> *.ads          #   output text is a pattern
>
> $ echo *.adb   # argument text is a pattern
> main.adb       #   output text is a file name
>
> $ ls *.ads
> ls: *.ads: No such file or directory
>
> $ ls *.adb
> main.adb
>
> (On the surface, ls(1) and echo(1) aren't consistently
> interpreting *.ads, one is reporting an error, the other
> is reproducing input. "But that's as defined, you ...
> If you can't be bothered to RTFM!")

Exactly ... that is as defined. I take it you're not overly familiar
with the Unix shell? Since this has nothing to do with " ls(1) and
echo(1) aren't consistently interpreting" but with exactly on quirk
the expansion (in the shell!) has:

 1. Expansion does always take place if the word is not quoted.
 
 2. If there is no file corresponding to the pattern, the result of the expansion
    is not '', but rather the pattern itself.

Thus we have

 echo *.ads --> echo '*.ads'    --> output: *.ads
 echo *.adb --> echo 'main.adb' --> output: main.adb

 ls *.ads   --> ls '*.ads'      --> try to stat() '*.ads', doesn't exist
 ls *.adb   --> ls 'main.adb'   --> try to stat() 'main.adb', output result

So ls and echo just act differently because they simply try to do
different things with the data they get passed: echo doesn't tell you
an error, because (as specified) it just has to echo it's arguments.

If you would have quoted, you'd have got the following results (note: no expansion takes place in all cases):

 echo '*.ads' --> output: *.ads
 echo '*.adb' --> output: *.adb

 ls '*.ads' --> try to stat() '*.ads', doesn't exist
 ls '*.adb' --> try to stat() '*.adb', doesn't exist

You see: Everything uniform, no heterogeneous behaviour at all.

I'm thus happy to note that your analysis seems to be based on a
certain lack of understanding how Unix or the Unix shells work. I'd
also like to insinuate that for a number of other contributions to
this thread. That can happen and certainly is no sin, but I humbly
suggest it might be advantageous to understand a thing before
asserting "it's all done wrong". At least it helps to get applicable
arguments instead of a bunch of misconceptions.

There is one point in what I elaborated where the Bourne shell might be
open to criticism: Point (2): If there is no file corresponding to the
pattern, the result of the expansion is not '', but rather the pattern
itself.

This has been a deliberate design choice to allow omitting the quotes
in many cases for convenience -- at the price of making it difficult
in some cases to assert wether the argument passed is a non-matching
pattern or the result of a successful expansion (this is hardly ever a
problem, not in interactive mode and good shell programmers know how
to handle that case).

But again this is no "as Unix handles arguments to programs" issue,
but rather choice taken in the design of specific shell language which
should provide enough power to start, stop, connect programs and at
the same time be easy to use interactively (i.e. without too much
typing).


> Since Unix shells use mostly text to represent almost all 
> information, the user is advised to remember text substitution
> pitfalls like the one above. Shell programming, for all its
> power, is like using Unchecked_Conversion by default, so to
> speak. In case of errors then, keeping track can be quite tricky,
> even more so when there is indirection, for example through
> popular backtick evaluation, as in
>
> $ foo=`echo .[a-z]*` ; some_cmd $foo ...

Well -- backtick is "out" anyway for the more complicated
cases. Especially when writing scripts I suggest to use $(...) --
which gets the nesting right.

>
> (run in a directory where there aren't any hidden files.)
>
> Caveat scriptor, the computer isn't programmed to help us
> here with type checking, OOD, etc..

Just use the scheme shell if you don't like Bourne shell. :-) 

But it is something you have to get used to, to properly quote ANY
arguments.


> That said, I'm looking forward to running Plan 9 again, on a
> virtual machine :)

Last time I checked (rather a bit ago that was) it couldn't run on
vmware or bochs: Has that changed?


Regards -- Markus

Re: Ada.Command_Line and wildcards

[Martin Krischik]

Markus E Leypold wrote:

> 
> Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>> here. And they got it wrong. Bot Dos and VMS will warn you on:
>             ^^^^^^^^^^^^^^^^^^^
> 
> Well, Martin, since you're so sure about that: On which criteria did
> "they get it wrong"? Where are the specs against which the predicate
> "right" can be tested?

Georg Does

rm -rf /tmp/*

work? Allways? What happen when the sum of all fileneames exceed 48kb -
which is the current limit for commandlines. On the other hand 

DELETE /noConfirm sys$scratch:[...]*.*;*

on VMS or 

DEL /SEXY %TEMP%\*.*

using 4NT on Windows will work fine no matter how many files are in the temp
directory. Just make sure that  sys$scratch: is not your home directory!

Neither the Dos/Windows etc nor the VMS Shell expand wildcard. Expanding
wildcard is done by a library under control of the program called. This is
why

$ SEARCH MY_TEXT.DAT *.*

works so well. Or a better example would be:

$ SEARCH *.TXT *HELLO*

SEARCH knows that the first parameter is filename and should be expanded and
the 2nd is a search pattern and does not. The program know more about the
parameters then the shell and therefore the shell expansion in unix might
be convenient at first but does not scale all that well when thinks become
more compicated.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada.Command_Line and wildcards

[Robert A Duff]

"Hyman Rosen" <hyman.rosen@gmail.com> writes:

> On Feb 22, 8:15 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>> Yuck -- bad design!
>
> The designers of UNIX didn't feel that it was necessary for every
> program to incorporate a wildcard expander when that could be done
> externally. Back then keeping programs small and simple was a virtue.

The way they did it simply doesn't work.  I shouldn't have to use a
different method (e.g. xargs) to pass a lot of file names to a command
than to pass a small number.  It's not that hard to design it so it
works for any number of files, no matter how big disk drives get in the
future.  And still keep things small and simple.

And xargs doesn't work, either.  It works for 'grep', but doesn't work
for 'wc'.  So much for the alleged simplicity of doing everything in
the shell.

> I don't understand. Doesn't "find" have exactly the interface that you
> claim to want?

Certainly not.  I use find all the time, and I hate it.

>> And I can't create a command that works like this:
>>     search *.ada "some string"
>
> Huh? Why in the world not? The program knows how many arguments it
> has,
> and it can get to the last one as easily as the first!

Yeah, I guess you're right about that.  Sorry.

- Bob

Re: Ada.Command_Line and wildcards

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> In article <wcc1wkhlln0.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> Jean-Pierre Rosen <rosen@adalog.fr> writes:
>> 
>>> Too bad that Unix behaviour was wrong in the first place...
>> 
>> I agree with JP Rosen, here.  The way wildcards work in Unix is
>> completely broken.  (Not that I'm advocating Windows instead!)
>
> Why would we assume there was only a single alternative to Unix ?

Sorry, Larry, I haven't used VMS in years.  ;-)

There's lots of stuff I don't like about VMS, but it does handle
wildcards without overflowing some buffer than can never be
the right size.  And it doesn't suffer from the windows problem
of every program having it's own notion of wildcards.

- Bob

Re: Ada.Command_Line and wildcards

[Jacob Sparre Andersen]

Markus E Leypold wrote:

> Exactly ... that is as defined. I take it you're not overly familiar
> with the Unix shell?

Maybe what Georg et al really need is "dossh" and "vmssh", shells
which work like those in DOS and VMS.  I don't think it would be too
much work to write them, since there doesn't seem to be much need for
the more interesting features of POSIX compatible shells.  The hard
work will be to copy all the programs which have to do globbing,
paging, etc. on their own.

> Just use the scheme shell if you don't like Bourne shell. :-)

Is that sort of like the DOS and VMS command lines?

Greetings,

Jacob
-- 
Trusted third party: Someone whom you know can violate your
                     security policy without getting caught.

Re: typed pipes

[Jacob Sparre Andersen]

Bj�rn Persson wrote:

> No, it definitely couldn't be done in a Unix shell. It would require
> very deep changes to how the kernel handles files, including changes
> to the system calls. And if you had it for pipes you'd want it for
> disk files too, which would affect the filesystems. I suspect that
> the resulting operating system would be almost, but not quite,
> entirely unlike Unix.

;-)

> And how could you make it work for all programming languages?

The first time I discussed it my suggestion was to use MIME types.  I
am not sure that is the correct solution, but it should definitely be
on a higher level than just Ada.Sequential_IO (Character).  Do we have
something better than MIME types to give a short, but reasonably
consistent description of a data stream?

Greetings,

Jacob
-- 
"This page inadvertently left blank."

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On Sat, 24 Feb 2007 14:22:07 -0500, Robert A Duff wrote:

> "Hyman Rosen" <hyman.rosen@gmail.com> writes:
> 
>> On Feb 22, 8:15 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
>> wrote:

>>> And I can't create a command that works like this:
>>>     search *.ada "some string"
>>
>> Huh? Why in the world not? The program knows how many arguments it
>> has, and it can get to the last one as easily as the first!
> 
> Yeah, I guess you're right about that.  Sorry.

Nope, you were right in principle. What about:

   search *.adb and *.ads but b~*.adb "some string" 

(I hate those b~*.adb files GNAT keeps on creating... (:-))

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

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Sat, 2007-02-24 at 17:45 +0100, Markus E Leypold wrote:

This discussion _is_ (also) about the quirks of the Unix shells,
and about their consequences...

> > One criterion is the number of wildcard expansion surprises.
> > Not having to mark patterns as patterns (untyped, no syntax)
> > creates an immensely flexible and powerful ... mess.
> >
> > $ echo *.ads   # argument text is a pattern
> > *.ads          #   output text is a pattern
> >
> > $ echo *.adb   # argument text is a pattern
> > main.adb       #   output text is a file name
> >
> > $ ls *.ads
> > ls: *.ads: No such file or directory
> >
> > $ ls *.adb
> > main.adb
> >
> > (On the surface, ls(1) and echo(1) aren't consistently
> > interpreting *.ads, one is reporting an error, the other
> > is reproducing input. 
 [...]
>  Since this has nothing to do with " ls(1) and
> echo(1) aren't consistently interpreting" but with exactly on quirk
> the expansion (in the shell!) has:

It is important to understand the premise here: I wrote: "On the
surface, ls(1) and echo(1) aren't consistently..." *On the surface*,
i.e. at the visible user interface of the command! Understanding why
this inconsistency is not an inconsistency forces the Unix
user to learn about what is happening under the hood. It is
always good to know something about the internal working
of your tools. But still, the same text (a pattern) can trigger
different behavior for the same pattern. The behavior *appears* to
depend on context (the command name, among other things).
Doesn't matter that, technically, Unix/libc/sh is always
consistent with its own, "hidden" workings.

(BTW, if I write

cmd=echo
$cmd *.ad? | while read fname
 do case $fname in
   *.ads) echo "'"$fname"'" is spec;;
   *.adb) echo "'"$fname"'" is body;;
 esac
done

I create yet another quirky situation, and Unix can tell me, again,
"What makes you think that you can iterate over the results of
echo(1) as if each name were on a line by its own, like if you had
been using ls(1) (uh, without -x) ?" Unix is right, technically.
But from a user's point of view, how is this all consistent?
In Makefiles, you list files side by side, and make(1) will deal
with them one by one (at least by the user-visible AS-IF rules).
When I write
cmd=ls
above, I get what I might have expected. Otherwise I have to know why
and how the results of "echo *.adb" all end up in $fname together as
one string---which then happens to match *.adb) . This _is_ all logical,
but I think there are better design choices. Here, it all depends
on things being listed top-down or left-right, and nothing obvious
tells you what to expect. Here, the programmer has to think about very
many aspects *without* being able to express them. They are all implicit
in the rules of sh, exec*, the assignment conventions of the built-in
read function, etc. ...)

Context dependence, echo vs. ls, may be technically interesting but
it sure makes proper sh scripting less uniform and more difficult
and error prone.


BTW, pertinent to the OP's problem, to find out what is actually
passed to some executable program on some OS running some shell,
a nice tool like Unix's strace(1) will do:

$ strace /bin/echo *.ads
execve("/bin/echo", ["/bin/echo", "*.ads"], [/* 34 vars */]) = 0
...

$ strace /bin/echo *.adb
execve("/bin/echo", ["/bin/echo", "main.adb"], [/* 34 vars */]) = 0
...


>  2. If there is no file corresponding to the pattern, the result of the expansion
>     is not '', but rather the pattern itself.

This is what I have been trying to say. The one quirk you concede
is a crucial example. It is a design choice. It has consequences.
It is very much like a null pointer in a pointer-heavy language:
Pointing is flexible and powerful. Terminate arrays using nulls...
You can always try to make sure you don't accidentally
run into a null (pointer)... By analogy, you can always try to
make sure you are properly quoting on the command line for the
selected combination of shell, shell functions, and program so
that there won't be pattern surprises.


>  it might be advantageous to understand a thing before
> asserting "it's all done wrong".

It is equally advantageous to understand what is being criticized
before addressing a different subject. ---I agree that "all wrong"
is probably too much when comparing sh to JCL, say, which was
another design choice at the time, I think.


>  Point (2): If there is no file corresponding to the
> pattern, the result of the expansion is not '', but rather the pattern
> itself.

Exactly. Design choice. A compromise that is bound to have
consequences.


>  good shell programmers know how
> to handle that case).

See?

What if good shell programmers could spend their time working
on the problem instead of avoiding shell mishaps? (Reminds me of:
Good C programmers don't need an Ada style compiler. Not surprisingly,
sh and C  and other languages with quirky syntax have roots in
the Bell Labs :-). I had tried to avoid saying so. For example, SNOBOL4,
a jewel in the treasure trove of PLs, has the "white space operator":

* read lines until user types q(uit)

again   input Any('qQ')		:s(end)f(again)
end

Dewar et al. have replaced the "white space operator" with ?
(and extended matching opportunities) in his implementation SPITBOL.
This was explicitly pointed out as an important change by Griswold at
a PL conference.

again   input ? Any('qQ')	:s(end)f(again)
end

Good SNOBOL4 programmers know how to handle normal pattern matching
without '?' ...?


> > $ foo=`echo .[a-z]*` ; some_cmd $foo ...
> 
> Well -- backtick is "out" anyway for the more complicated
> cases. Especially when writing scripts I suggest to use $(...) --
> which gets the nesting right.

Using $(...) in place of `...` (which I do, but we were talking about
the original Unix design choices) doesn't remove the effects outlined.
When there is no hidden file in the current directory that matches
the pattern, the next command will read ".[a-z]*" in argv. This is
to be expected in Unix which by design assumes that

- you known well how the Unix shell normally works,
- you have thought of this possibility,
- you know how to add a check that "${foo}" != ".[a-z]*"
- you known another way as TIMTOWTDI


> > Caveat scriptor, the computer isn't programmed to help us
> > here with type checking, OOD, etc..
> 
> Just use the scheme shell if you don't like Bourne shell. :-) 

Aren't we talking about the original design choices in Unix
shells, i.e. Bourne Shell and Csh? Not about what we could do to
improve the situation?  (Like, replace bash/auto*/fixincludes 
in GCC? :-)

> > That said, I'm looking forward to running Plan 9 again, on a
> > virtual machine :)
> 
> Last time I checked (rather a bit ago that was) it couldn't run on
> vmware or bochs: Has that changed?

Work has been done on Xen + Plan9.

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Sat, 2007-02-24 at 21:08 +0100, Jacob Sparre Andersen wrote:
> Markus E Leypold wrote:
> 
> > Exactly ... that is as defined. I take it you're not overly familiar
> > with the Unix shell?
> 
> Maybe what Georg et al really need is "dossh" and "vmssh",

I can only speak for myself, and I consider the Unix toolbox(!)
far superior to DOS cmd.exe with or without extensions.
This doesn't stop me from complaining. (Hey, my superiors
asked me to both write simple shell scripts, and provide
detailed error reporting by email. Two requirements not always
easy to reconcile.)

(For NT cmd.exe, you can actually write assembly language style
programs in .bat files, manipulate the call stack, and use goto.
It's fun, NT also comes with some POSIX programs like
findstr and pax, so basically there is a lot one can do,
technically... )


> Is that sort of like the DOS and VMS command lines?

No, scsh is a Unix shell merged with Scheme (Scheme48).
http://www.scsh.net/

Other interesting shells include rc (of Plan 9, flexible
pipes, BTW), and es (a "functional" shell with higher order
functions).

If you have an opportunity, install rc, 9term, sam, and wily.
It might change the way you look at OS interfaces, including
the way of working with text :-)

Re: Ada.Command_Line and wildcards

[Björn Persson]

Georg Bauhaus wrote:

> flexible pipes

You mean hoses? ;-)

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: typed pipes

[Björn Persson]

Jacob Sparre Andersen wrote:

> The first time I discussed it my suggestion was to use MIME types.  I
> am not sure that is the correct solution, but it should definitely be
> on a higher level than just Ada.Sequential_IO (Character).  Do we have
> something better than MIME types to give a short, but reasonably
> consistent description of a data stream?

Yes, MIME types seems a lot better than trying to describe complex data
types in detail. A MIME type is just a name for the file type, not a
description, but that's enough. If the program can handle the file type
then it already knows the structure and doesn't need a description, and if
it's an unknown file type then the program won't know what to do with the
file no matter how detailed the structure is described.

MIME types can be stored as extended attributes in some file systems. I
don't really know how feasible it would be to add them to pipes.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

Robert A Duff wrote:
> without overflowing some buffer than can never be the right size

Oddly enough, when newbies ask how to read input in Ada,
the general response here is to read lines into a fixed-
size buffer which too can never be the right size.

Re: typed pipes

[Jacob Sparre Andersen]

Bj�rn Persson wrote:

> MIME types can be stored as extended attributes in some file
> systems. I don't really know how feasible it would be to add them to
> pipes.

It would require a hack on the memory structure storing the pipe, and
a uniform interface for querying a File_Descriptor about its type.

Greetings,

Jacob
-- 
Stop the proliferation of weapons of maths instruction!

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

Robert A Duff wrote:
> The way they did it simply doesn't work.

That's fine. UNIX follows the "worse is better" philosophy
(<http://en.wikipedia.org/wiki/Worse_is_better>). The UNIX
way is simple and works most of the time. Most lists of
files are small enough. Most files have only short lines.

>> I don't understand. Doesn't "find" have exactly the interface that you
>> claim to want?
> Certainly not.  I use find all the time, and I hate it.

I meant that "find" takes a pattern as an argument.

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

Markus E Leypold wrote:
>> $ echo *.ads   # argument text is a pattern
>> *.ads          #   output text is a pattern

Not if you use csh:
 >> % echo *.ads
 >> echo: No match
 >> % ls *.ads
 >> No match

This is hardly new - in fact there's a classic UNIX joke:
 >> % Got a match?
 >> No match

Re: Ada.Command_Line and wildcards

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
>> without overflowing some buffer than can never be the right size
>
> Oddly enough, when newbies ask how to read input in Ada,
> the general response here is to read lines into a fixed-
> size buffer which too can never be the right size.

Indeed, that is a serious flaw in the design of Ada.

By the way, Ada 2005 has a function Get_Line that returns type String.

- Bob

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Sun, 2007-02-25 at 07:46 +0000, Hyman Rosen wrote:
> Markus E Leypold wrote:
> >> $ echo *.ads   # argument text is a pattern
> >> *.ads          #   output text is a pattern
> 
> Not if you use csh:
>  >> % echo *.ads
>  >> echo: No match

Yes, but the absence of a match prevents the whole
thing from being run. That is, zero args is very different
from 1 .. n args. Yet another philosophy.
   

>  >> % ls *.ads
>  >> No match
> 
> This is hardly new -

Yes.

Re: Ada.Command_Line and wildcards

[Larry Kilgallen]

In article <6w7iu7a5ur.fsf@hod.lan.m-e-leypold.de>, Markus E Leypold writes:

> Understand that: This is no question of "how Unix handles the command
> line" ore something like this, but simply a question of a specific
> choice of syntax for "expand this as a wildcard against the file
> system before passing the arguments" taken by the developers of a
> specific (though rather standard) shell, the Bourne shell.
> 
>   '*.*' -> don't expand
>   'abc' -> don't expand
> 
>    abc  -> expand
>    *.*  -> expand


But whether a parameter is a filespec that should be expanded is
something known to the program, and the program should make the
decision in the absence of user override.

Saying the user must specify in all cases is insufficient automation,
analogous to weak typing.

Re: Ada.Command_Line and wildcards

[Pascal Obry]

Robert A Duff a �crit :
> Indeed, that is a serious flaw in the design of Ada.
> 
> By the way, Ada 2005 has a function Get_Line that returns type String.

Which is a dubious feature if you asked me as you do not control the
amount of stack space used by the returned object. This can easily lead
to stack overflow, strange for Ada which aim to be on the safe side.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada.Command_Line and wildcards

[Martin Krischik]

Georg Bauhaus wrote:

>> > Exactly ... that is as defined. I take it you're not overly familiar
>> > with the Unix shell?
>> 
>> Maybe what Georg et al really need is "dossh" and "vmssh",
> 
> I can only speak for myself, and I consider the Unix toolbox(!)
> far superior to DOS cmd.exe with or without extensions.

That is indeed true - over time bash has been extended and extended over and
over again and it is dam powerfull now.

Admitting that does not stop me from from saying that some fundamental
design philosophies where short sighted.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

wildcards with unix shells

[Martin Krischik]

Markus E Leypold wrote:

> This is, forgive me, wrong. The "commandline" in Unix is a an array of
> pointers to zero-terminated strings which itself is terminated by a
> null pointer.

With a total length of 8k on Windows and 48k on current Linux version -
as "./confiure" will be glad to tell you. Which is the reason why

rm -rf /tmp/*

might not work. Really one should allways use find and xarg...

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada.Command_Line and wildcards

[Martin Krischik]

Simon Wright wrote:

> Anders Wirzenius <anders@no.email.thanks.invalid> writes:
> 
>> ... so one can ask why the design was not done the opposite way: If
>> you want to have the shell to expand, use an option (like find -x
>> *.adb), else the parameter is passed as such to the application.
> 
> That sounds a very odd design. The shell would have to parse the
> command line to see if there was an option requiring expansion. And
> what if -x already had a meaning to the program?

Actually the VMS *could* have done that as foreign commands or symbols are
defined using a meta language called CLD (Command Language Definition) [1].

Great design but never fully exploited - like most of VMS :-( .

Martin

[1] http://en.wikipedia.org/wiki/DIGITAL_Command_Language
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On Sun, 25 Feb 2007 17:22:02 +0100, Pascal Obry wrote:

> Robert A Duff a �crit :
>> Indeed, that is a serious flaw in the design of Ada.
>> 
>> By the way, Ada 2005 has a function Get_Line that returns type String.
> 
> Which is a dubious feature if you asked me as you do not control the
> amount of stack space used by the returned object. This can easily lead
> to stack overflow, strange for Ada which aim to be on the safe side.

That should be no problem under two conditions:

1. A failure to allocate the result shall not destroy the program and the
task. Get_Line should propagate an exception which could be handled in a
reasonable way.

2. The failure should leave the file in a definite state and the data
already read should be recoverable.

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

Re: Ada.Command_Line and wildcards

[Martin Krischik]

Jacob Sparre Andersen wrote:

> But if the programs do the expansion, you can be certain that the
> expansion will differ from program to program. ï¿œWouldn't that be
> much more inconsistent than having known, uniform rules? ￜ(even if
> you don't like them)

Well, all VMS programs I know of - apart from GNV [1] applications - expand
the same way including [...]*.TXT expanding recursively. Something you
won't get in unix where you need to guess which  -r, -R, --recursive option
gets you recursive behaviour. Actually: none - you will need:

find . -iname "*.TXT" -print0 | xargs  --null --no-run-if-empty my_command

(did you allways remember to use: "--no-run-if-empty").

Again: the unix way is convenient at start but does not scale all that well
for more complex problems.

Martin

[1] Note: GNAT for VMS is GNV application :-/ .

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada.Command_Line and wildcards

[Martin Krischik]

Bjï¿œrn Persson wrote:

> Adam Beneschan wrote:
> 
>> It would have made so much sense to have grep call an OS function to
>> retrieve the file names one at a time and search them all, and then no
>> huge buffer would be needed to hold all the filenames.
> 
> grep --recursive 'some string' .

But that will search all files including meta files like .directory,
CVS, .svn and what else there might be.

May I suggest:

ffind is a function
ffind ()
{
    find . -iname "${2}" | xargs grep -l "${1}" 2>/dev/null
}

and having learned about basename and dirname I will soon improve that
function.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada.Command_Line and wildcards

[Martin Krischik]

Adam Beneschan wrote:

> On Feb 23, 11:12 am, "Hyman Rosen" <hyman.ro...@gmail.com> wrote:
>> On Feb 23, 11:58 am, "Adam Beneschan" <a...@irvine.com> wrote:
>>
>> > This problem has a simple solution, though...  Increase the size of
>> > the shell buffer used to hold the expansion!!
>>
>> No, that's incorrect. Many versions of UNIX have an absolute limit on
>> the total size of the arguments that can be passed to a process about
>> to execute, and will fail the exec... system calls with an E2BIG error
>> if that size is exceeded.
> 
> No, what I meant is that they (the OS developers) increase this
> absolute limit in the next version of Unix.  That's been my
> experience.  Some time ago, I found that I couldn't use commands that
> operate on N files in a certain directory.  Later, we'd get a new
> version of the OS, and I found that I could now use those commands I
> couldn't use before---but I couldn't use commands that operate on 4N
> files, or 5N or whatever---I don't know the exact factor.  And this
> pattern has repeated itself several times.  And it's still the same.
> I can now include more files than I ever have before, but the number
> still isn't infinite and still isn't large enough sometimes.

Next time you use ./configure pipe and grep the output for "commandline".

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Ada.Command_Line and wildcards

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> By the way, Ada 2005 has a function Get_Line that returns type String.

Finally.

How to do this was 1st published in

Carter, J. R., �Variable-Length String Input in Ada,� /Ada Letters/, 
1989 May/Jun

(Ada 83) and available as part of the PragmAda Reusable Components since 
about 1990, though I presume many people had figured it out before I did.

-- 
Jeff Carter
"When Roman engineers built a bridge, they had to stand under it
while the first legion marched across. If programmers today
worked under similar ground rules, they might well find
themselves getting much more interested in Ada!"
Robert Dewar
62

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Get_Line should propagate an exception which could be handled in a
> reasonable way.

That's not really good enough. That is, your program is to going to
tell you "I can't do that" when you ask "give me the next line".
Fine, you're not crashing, but you really want that line!

There ought to be a Get_Line which returns an Unbounded_String (did
I get that right?), so that space for it comes from the heap instead
of the stack. And yes, I know it's a security issue because someone
can feed the program unbounded input and have it chew up large chunks
of RAM, but sometimes you really do need unbounded lengths on your
input lines. I've often posted the example of a .newsrc file I had
where a line of interest was well over 100,000 characters long.

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On Mon, 26 Feb 2007 05:03:26 GMT, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> Get_Line should propagate an exception which could be handled in a
>> reasonable way.
> 
> That's not really good enough. That is, your program is to going to
> tell you "I can't do that" when you ask "give me the next line".
> Fine, you're not crashing, but you really want that line!

There are numerous other reasons why Get_Line might fail. So you cannot
"really" want it, only conditionally.
 
> There ought to be a Get_Line which returns an Unbounded_String (did
> I get that right?), so that space for it comes from the heap instead
> of the stack.

Which can fail either.

Further, why do you presume that heap is larger than stack? AFAIK, nothing
in RM requires or implies that.

> And yes, I know it's a security issue because someone
> can feed the program unbounded input and have it chew up large chunks
> of RAM, but sometimes you really do need unbounded lengths on your
> input lines.

That depends on the underlying OS and its resources sharing schema.
Theoretically, it is not the programmer's business, but practically, yes,
it is a DoS concern.

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

Re: Ada.Command_Line and wildcards

[Anders Wirzenius]

Simon Wright <simon.j.wright@mac.com> writes:

> Anders Wirzenius <anders@no.email.thanks.invalid> writes:
> 
> > ... so one can ask why the design was not done the opposite way: If
> > you want to have the shell to expand, use an option (like find -x
> > *.adb), else the parameter is passed as such to the application.
> 
> That sounds a very odd design. The shell would have to parse the
> command line to see if there was an option requiring expansion. And
> what if -x already had a meaning to the program?
> 

Sorry, I was unclear. I meant a design where The option (-x, -y,
whatever) goes to the application (find, loose, whatever) which
will parse the command line and then decide how to call shell
services. Not the other way around: command line first to shell
and then the result to the application.


> The Unix shell design seems quite clear -- unescaped wildcards get
> expanded. Of course, it's not just '*' wildcards; expressions such as
> *.ad[bs] or foo.{adb,ads} also have their place.
> 
> I think we ought to live with the shells the way they are -- it's true
> of Ada, after all.

Yes, we live and discuss. ;)

-- 
Anders

Re: Ada.Command_Line and wildcards

[Larry Kilgallen]

In article <uwt256sfq.fsf@no.email.thanks.invalid>, Anders Wirzenius <anders@no.email.thanks.invalid> writes:

> Simon Wright <simon.j.wright@mac.com> writes:

>> I think we ought to live with the shells the way they are -- it's true
>> of Ada, after all.
> 
> Yes, we live and discuss. ;)

Some of us live without Unix, particularly in light of these remarks
about inadequacies.

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

On Feb 26, 3:44 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Further, why do you presume that heap is larger than stack?
> AFAIK, nothing in RM requires or implies that.

Past experience. If that's not the case for some implementation then
fine, but I suspect it's more often the case then not. I'm pretty sure
we've seen newbie examples on the newsgroup where they create
unconstrained objects (is that the right term?) on the stack and then
wonder why their program doesn't work.

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

"Hyman Rosen" <hyman.rosen@gmail.com> writes:

> On Feb 26, 3:44 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Further, why do you presume that heap is larger than stack?
>> AFAIK, nothing in RM requires or implies that.
>
> Past experience. If that's not the case for some implementation then
> fine, but I suspect it's more often the case then not. I'm pretty sure
> we've seen newbie examples on the newsgroup where they create
> unconstrained objects (is that the right term?) on the stack and then
> wonder why their program doesn't work.

I'm also pretty sure that in most of those cases creating them on the
heap wouldn't work either. Especially if the unconstrained parameter
was determining an array size and was of type Natural or Positive.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On 26 Feb 2007 09:11:53 -0800, Hyman Rosen wrote:

> On Feb 26, 3:44 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Further, why do you presume that heap is larger than stack?
>> AFAIK, nothing in RM requires or implies that.
> 
> Past experience. If that's not the case for some implementation then
> fine, but I suspect it's more often the case then not. I'm pretty sure
> we've seen newbie examples on the newsgroup where they create
> unconstrained objects (is that the right term?) on the stack and then
> wonder why their program doesn't work.

But this is an compiler implementation artefact which cannot serve as a
guideline for the standard library design.

P.S. Surely there should be a Get_Line for all string types, but not
because GNAT has heap larger than stack. The reason is language regularity.

P.P.S. For Unbounded_String Append_Line could be a useful complement to
Get_Line.

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

Re: Ada.Command_Line and wildcards

[Simon Wright]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Actually the VMS *could* have done that as foreign commands or
> symbols are defined using a meta language called CLD (Command
> Language Definition) [1].

Actually you used CLD _or_ foreign commands. I forget why I used
foreign commands almost exclusively -- I guess the CLD compiler wasn't
available or wasn't obviously documented when I started programming on
VMS (1982, I think).

Re: Ada.Command_Line and wildcards

[Björn Persson]

Martin Krischik wrote:

> Again: the unix way is convenient at start but does not scale all that
> well for more complex problems.

Right. The primary purpose of a command shell is to be convenient for
everyday interactive use. A fakir might enjoy solving complex problems with
shell scripts. I tend to switch to a better programming language when the
problem gets complex.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Ada.Command_Line and wildcards

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:yStEh.6202$iF.2036@trndny03...
...
> There ought to be a Get_Line which returns an Unbounded_String (did
> I get that right?), so that space for it comes from the heap instead
> of the stack.

There is such a Get_Line (see A.10.12). But I don't think that really helps.

> And yes, I know it's a security issue because someone
> can feed the program unbounded input and have it chew up large chunks
> of RAM, but sometimes you really do need unbounded lengths on your
> input lines. I've often posted the example of a .newsrc file I had
> where a line of interest was well over 100,000 characters long.

...and you know why. Note that a regular unconstrained String returned from
a function is allocated from the heap in Janus/Ada (we only allocate
static-sized things on the stack). But that doesn't help either. The problem
is that if it doesn't fit, you can't recover because there is no way to know
how much of the file was read before you ran out of memory. Of course, if
you don't want to recover, it's not an issue - so it makes sense to have
both possibilities.

And in neither case (String or Unbounded_String) is the memory going to
disappear - it will get recovered quickly. (There is a danger that the
momentary lack of memory could cause some other task in the program to
fail - so again you do have to think about the consequences.)

                           Randy.

Re: Ada.Command_Line and wildcards

[Martin Krischik]

Simon Wright schrieb:
> Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>> Actually the VMS *could* have done that as foreign commands or
>> symbols are defined using a meta language called CLD (Command
>> Language Definition) [1].
> 
> Actually you used CLD _or_ foreign commands. I forget why I used
> foreign commands almost exclusively -- I guess the CLD compiler wasn't
> available or wasn't obviously documented when I started programming on
> VMS (1982, I think).

Maybe because:

$ foo :== $sys$sysexe:foo.exe

is easier to begin with then:

$ DEFINE VERB FOO
$    IMAGE "SYS$SYSEXE:FOO.EXE"
$    QUALIFIER BAR

However the 2nd option will tell the command line processor that an 
option /BAR exists.

Sadly VMS never really used CLD to it's full potential. Just imagine CLD 
combined with bash'es advanced comandline completion! Not only commands 
and files could be completed - options as well.

Working with VMS always makes me sad - for all the missed opportunities 
the great VMS foundation could have made possible.

Martin

Re: Ada.Command_Line and wildcards

[Martin Krischik]

Bj�rn Persson schrieb:
> Martin Krischik wrote:
> 
>> Again: the unix way is convenient at start but does not scale all that
>> well for more complex problems.
> 
> Right. The primary purpose of a command shell is to be convenient for
> everyday interactive use. A fakir might enjoy solving complex problems with
> shell scripts. I tend to switch to a better programming language when the
> problem gets complex.

I still on the lookout for a better programming language with pipes in 
general and the special "A=$(...)" and "<<EOF ..... EOF" pipes in 
particular. I tried to replicate the feast in AdaCL but it did not work 
out all that well.

Martin

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

On Feb 26, 7:34 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> The problem is that if it doesn't fit, you can't recover

Granted, but that's not really the point. On a modern computer system,
given that it's reading input from a file or standard input, the
programmer can reasonably expect that there are at least many tens of
megabytes available to be allocated. Sure there can be inputs that
will exceed that, but then you're really in a different domain.

Think of it this way - when you decide to sort data, you need to
choose between internal and external sorts. You can't do that without
a notion of a threshold size. Clearly that size has increased over the
years. Reading input is similar. Many programs can now very reasonably
expect to read in their entire input into memory at once before
processing any of it, and if that's not going to work because of
allocation on the stack then there should be an alternative.

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Mon, 2007-02-26 at 18:34 +0100, Markus E Leypold wrote:
> "Hyman Rosen" <hyman.rosen@gmail.com> writes:
> 
> > On Feb 26, 3:44 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> Further, why do you presume that heap is larger than stack?
> >> AFAIK, nothing in RM requires or implies that.
> >
> > Past experience. If that's not the case for some implementation then
> > fine, but I suspect it's more often the case then not. I'm pretty sure
> > we've seen newbie examples on the newsgroup where they create
> > unconstrained objects (is that the right term?) on the stack and then
> > wonder why their program doesn't work.
> 
> I'm also pretty sure that in most of those cases creating them on the
> heap wouldn't work either.

IIRC, two non-GNAT Ada compilers had no trouble whatsoever
allocating objects of type array (1 .. N) of Something,
N <= available_heap_memory, independent of the OS stack size.

Also, I think Hyman remembers correctly: rewriting Ada programs
to use explicit heap allocation for dynamically sized arrays
can make GNAT-translated Ada programs work.

I understand that Janus/Ada allocates on the heap, too,
so there shouldn't be a problem either for any N below
available heap memory.

Really, isn't this an issue of how to best use GNAT
for Ada programs when they have potentially large objects.

GNAT:
$ ./big
Enter size: 50_000_000
size is 50000000

raised STORAGE_ERROR : big.ada:6 object too large
$

AppletMagic:
$ java big
Enter size: 50_000_000
size is 50000000
Enter Q: q
$

For the same quick and dirty program,

with Ada.Text_IO;

procedure big is

   procedure make(n: NATURAL) is
       local: array(1 .. n) of Character;
   begin
       if local'length > 0
       then local(local'last) := local(local'length / 2);
       end if;
   end make;

   buffer: String(1 .. 20);
   last: Natural; -- dual use
begin
   Ada.Text_IO.put("Enter size: ");
   Ada.Text_IO.Get_line(buffer, last);
   last := Integer'value(buffer(1 .. last));
   Ada.Text_IO.put_line("size is" & Integer'image(last));
   make(last);
   Ada.Text_IO.put("Enter Q: ");
   Ada.Text_IO.Get_Line(buffer, last);
end;


>  Especially if the unconstrained parameter
> was determining an array size and was of type Natural or Positive.
> 
> Regards -- Markus
> 
> 
> 

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Mon, 2007-02-26 at 18:34 +0100, Markus E Leypold wrote:
>> "Hyman Rosen" <hyman.rosen@gmail.com> writes:
>> 
>> > On Feb 26, 3:44 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> > wrote:
>> >> Further, why do you presume that heap is larger than stack?
>> >> AFAIK, nothing in RM requires or implies that.
>> >
>> > Past experience. If that's not the case for some implementation then
>> > fine, but I suspect it's more often the case then not. I'm pretty sure
>> > we've seen newbie examples on the newsgroup where they create
>> > unconstrained objects (is that the right term?) on the stack and then
>> > wonder why their program doesn't work.
>> 
>> I'm also pretty sure that in most of those cases creating them on the
>> heap wouldn't work either.

> Really, isn't this an issue of how to best use GNAT
> for Ada programs when they have potentially large objects.

Yes, that's because I said "in most of those cases". _Those_ cases.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Tue, 2007-02-27 at 17:19 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > On Mon, 2007-02-26 at 18:34 +0100, Markus E Leypold wrote:
> >> "Hyman Rosen" <hyman.rosen@gmail.com> writes:
> >> 
> >> > On Feb 26, 3:44 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> >> > wrote:
> >> >> Further, why do you presume that heap is larger than stack?
> >> >> AFAIK, nothing in RM requires or implies that.
> >> >
> >> > Past experience. If that's not the case for some implementation then
> >> > fine, but I suspect it's more often the case then not. I'm pretty sure
> >> > we've seen newbie examples on the newsgroup where they create
> >> > unconstrained objects (is that the right term?) on the stack and then
> >> > wonder why their program doesn't work.
> >> 
> >> I'm also pretty sure that in most of those cases creating them on the
> >> heap wouldn't work either.
> 
> > Really, isn't this an issue of how to best use GNAT
> > for Ada programs when they have potentially large objects.
> 
> Yes, that's because I said "in most of those cases". _Those_ cases.

But in most of those cases creating the array on the heap explicitly
_has_ worked.
Or am I missing something? I recall array sizes of some 10M.

> Regards -- Markus
> 

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Tue, 2007-02-27 at 17:19 +0100, Markus E Leypold wrote:
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>> > On Mon, 2007-02-26 at 18:34 +0100, Markus E Leypold wrote:
>> >> "Hyman Rosen" <hyman.rosen@gmail.com> writes:
>> >> 
>> >> > On Feb 26, 3:44 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> >> > wrote:
>> >> >> Further, why do you presume that heap is larger than stack?
>> >> >> AFAIK, nothing in RM requires or implies that.
>> >> >
>> >> > Past experience. If that's not the case for some implementation then
>> >> > fine, but I suspect it's more often the case then not. I'm pretty sure
>> >> > we've seen newbie examples on the newsgroup where they create
>> >> > unconstrained objects (is that the right term?) on the stack and then
>> >> > wonder why their program doesn't work.
>> >> 
>> >> I'm also pretty sure that in most of those cases creating them on the
>> >> heap wouldn't work either.
>> 
>> > Really, isn't this an issue of how to best use GNAT
>> > for Ada programs when they have potentially large objects.
>> 
>> Yes, that's because I said "in most of those cases". _Those_ cases.
>
> But in most of those cases creating the array on the heap explicitly
> _has_ worked.
> Or am I missing something? I recall array sizes of some 10M.

Then you remember other cases. No problem. The case I have been
referring to -- an array where the upper bound in the unconstraint
case would have been Positive'Last -- it would not have worked to
allocate on the heap. And that seems to be mistake made most
frequently by beginners (I think we had the word beginner somehwere in
this thread), but YMMV.

I just find it equivalent to the reading of tea leafes to assume this:

>> >> >> AFAIK, nothing in RM requires or implies that.
>> >> >
>> >> > Past experience. If that's not the case for some implementation then
>> >> > fine, but I suspect it's more often the case then not. I'm pretty sure
>> >> > we've seen newbie examples on the newsgroup where they create
>> >> > unconstrained objects (is that the right term?) on the stack and then
>> >> > wonder why their program doesn't work.

a conclusion that is still lacking the last step too, since he assumed
that it worked when allocating on the heap (but doesn't say so).


Regards -- Markus

Re: Ada.Command_Line and wildcards

[Randy Brukardt]

"Georg Bauhaus" <bauhaus@futureapps.de> wrote in message
news:1172592793.6285.13.camel@localhost...
...
> I understand that Janus/Ada allocates on the heap, too,
> so there shouldn't be a problem either for any N below
> available heap memory.

Right, I tried your program and it works fine on Janus/Ada (although I had
to replace Natural with Long_Integer as Integer is still 16-bit on
Janus/Ada).

                  Randy.

Re: Ada.Command_Line and wildcards

[Randy Brukardt]

"Hyman Rosen" <hyman.rosen@gmail.com> wrote in message
news:1172587938.237094.134530@m58g2000cwm.googlegroups.com...
> On Feb 26, 7:34 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> > The problem is that if it doesn't fit, you can't recover
>
> Granted, but that's not really the point. On a modern computer system,
> given that it's reading input from a file or standard input, the
> programmer can reasonably expect that there are at least many tens of
> megabytes available to be allocated. Sure there can be inputs that
> will exceed that, but then you're really in a different domain.
>
> Think of it this way - when you decide to sort data, you need to
> choose between internal and external sorts. You can't do that without
> a notion of a threshold size. Clearly that size has increased over the
> years. Reading input is similar. Many programs can now very reasonably
> expect to read in their entire input into memory at once before
> processing any of it, and if that's not going to work because of
> allocation on the stack then there should be an alternative.

True, but recovery *is* the point if you're at all worried about security.
These days, you have to assume that all files and all other user input are
corrupted in some way. Ignoring the possibility is only legitimate for
programs only used in tightly controlled circumstances (and there are not
many of those).

It is OK to let the program run out of memory if that case can only cause a
DoS to the attacker. (Who cares if the attacker is served?) But running out
of memory can cause a DoS to *all* tasks in the program, and that could
cause a DoS to all users of the program.

Take our web server. It uses a fixed size buffer to read commands from the
Internet. Because of the behavior of the procedure Get_Line, if the command
is too long, it will merely be truncated (and the fact that that happened
can be detected). So even if the case isn't handled explicitly, nothing bad
could happen to anyone other than the attacker (and if it is handled
explicitly, the attacker simply will be given an error message). OTOH, the
function Get_Line would use an arbitrary amount of memory in that case. So,
if an attacker fed a sufficiently large command to the server, it could
cause the server to run out of memory and thus disrupt the other tasks
handling commands from other clients. That could result in a general DoS,
and that's not acceptable.

Thus, its really only safe to use function Get_Line in single-tasking
programs for which the failure to handle user input does not cause
corruption. There are of course many such programs, which is why we included
a function Get_Line. But it has to be used with care _ I worry that it will
not be, and thus some of Ada's security will be compromised.

In any case, current Ada supports what you want. So further griping on this
subject is uncalled for... (There are plenty of other subjects where you
could find a legitimate gripe...I recommend complaining about one of them.
;-)

                                                Randy.

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On 27 Feb 2007 06:52:18 -0800, Hyman Rosen wrote:

> On Feb 26, 7:34 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
>> The problem is that if it doesn't fit, you can't recover
> 
> Granted, but that's not really the point. On a modern computer system,
> given that it's reading input from a file or standard input, the
> programmer can reasonably expect that there are at least many tens of
> megabytes available to be allocated. Sure there can be inputs that
> will exceed that, but then you're really in a different domain.
> 
> Think of it this way - when you decide to sort data, you need to
> choose between internal and external sorts. You can't do that without
> a notion of a threshold size. Clearly that size has increased over the
> years. Reading input is similar. Many programs can now very reasonably
> expect to read in their entire input into memory at once before
> processing any of it, and if that's not going to work because of
> allocation on the stack then there should be an alternative.

But Pascal's point still apply here. The size you are talking about, is it
just a programmer's expectation or a fact derived from the domain?

This nice-looking feature could provoke false expectations resulting in
poorly designed programs. I am undecided here.

P.S. Reading files into memory is a plague of modern programs. I remember a
problem of reading 3-4GB log file under Windows. Most of editors just
crashed after 20 minutes of hard work. And those rare who survived blocked
UI until reading the file to the end.

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

Re: Ada.Command_Line and wildcards

[Björn Persson]

Martin Krischik wrote:

> Sadly VMS never really used CLD to it's full potential. Just imagine CLD
> combined with bash'es advanced comandline completion! Not only commands
> and files could be completed - options as well.

I recently discovered that Bash can do that if you define completion
specifications. I had thought that only the Z shell had that feature. Look
for "Programmable Completion" in the Bash manual.

The problem is of course to keep the completion specification in sync with
the command line parser in the actual program. Some day I'll write an
extension to Orto that will take the same Parameter_Spec that Orto uses and
output a completion specification for Bash or Zsh.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Tue, 2007-02-27 at 21:32 +0000, Björn Persson wrote:
> Martin Krischik wrote:
> 
> > Sadly VMS never really used CLD to it's full potential. Just imagine CLD
> > combined with bash'es advanced comandline completion! Not only commands
> > and files could be completed - options as well.
> 
> I recently discovered that Bash can do that if you define completion
> specifications. I had thought that only the Z shell had that feature. Look
> for "Programmable Completion" in the Bash manual.

Can be unnerving if you come across completion AI uninitiated ;-)
For example, recent Bash setups recognise "darcs" as a known command
name. Then bash tries to discover what file name I might have wanted 
to type and somehow starts scanning the repository!

Please, turn that off! :-) :-)

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Tue, 2007-02-27 at 21:32 +0000, Bj�rn Persson wrote:
>> Martin Krischik wrote:
>> 
>> > Sadly VMS never really used CLD to it's full potential. Just imagine CLD
>> > combined with bash'es advanced comandline completion! Not only commands
>> > and files could be completed - options as well.
>> 
>> I recently discovered that Bash can do that if you define completion
>> specifications. I had thought that only the Z shell had that feature. Look
>> for "Programmable Completion" in the Bash manual.

> Can be unnerving if you come across completion AI uninitiated ;-)
> For example, recent Bash setups recognise "darcs" as a known command
> name. Then bash tries to discover what file name I might have wanted 
> to type and somehow starts scanning the repository!
>
> Please, turn that off! :-) :-)

The completion rules are not "compiled into" the bash. They are
usually sourced during shell setup from somewhere in /etc. If you're
not root you can turn them off with

  complete -r darcs  - only for darcs

or

  complete -r        - remove all completion rules

in your .bashrc or .bash_login.

Shall I say, reading the manual has it's advantages somtimes? But of
course that will only contribute more towards your ideas that Unix
does everything wrong, since it is too complicated and people cannot
be bothered to read manuals :-(.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Tue, 2007-02-27 at 23:53 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:

> > Please, turn that off! :-) :-)

[extensive completion *presets* in fresh installations that is]


> Shall I say, reading the manual has it's advantages somtimes?

An even bigger advantage is recognizing an attempt at a joke.
You think I have full shell candy supply still turned on?

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Tue, 2007-02-27 at 23:53 +0100, Markus E Leypold wrote:
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>
>> > Please, turn that off! :-) :-)
>
> [extensive completion *presets* in fresh installations that is]
>
>
>> Shall I say, reading the manual has it's advantages somtimes?
>
> An even bigger advantage is recognizing an attempt at a joke.

Fine. I didn't get the joke. Perhaps understandable in the light of
all that misconceptions that turned up in this thread, that I take it
at face value when you talk as if you seem to think this is a builtin
function of bash.

> You think I have full shell candy supply still turned on?

So why complain? BTW Debian still hasn't turned it on and since you
are calling for turning off "extensive completion *presets* in fresh
installations" you could just use a distro where it is turned off (or
live with the necessity that you have to tune fresh installation to
your taste, since I doubt that there are enough distributions to meet
everyones taste out of the box, with all the presets, that is).

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Brian May]

>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:

    Martin> No, The VMS also won't expand wildcard. In fact Unix
    Martin> shells are pretty alone here. And they got it wrong. Bot
    Martin> Dos and VMS will warn you on:

    Martin> DEL *.*

    Martin> but not on

    Martin> DEL Some_File.Txt

I realize this thread is old, but if I type "rm *", my shell (zsh) asks:

zsh: sure you want to delete all the files in /tmp/a [yn]?


DOS *still* has this broken special case *.* wildcard? That is dated
from 8.3 filenames. Under Unix this will not list files that don't
contain a full-stop.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada.Command_Line and wildcards

[Brian May]

>>>>> "Georg" == Georg Bauhaus <bauhaus@futureapps.de> writes:

    Georg> $ echo *.ads

Get a real shell !

I get:

zsh: no matches found: *.ads

which forces you to quote the value if thats what you really wanted:

> echo "*.ads"
*.ads

or set NULLGLOB:

> setopt NULLGLOB
> echo *.ads

which expands *.ads into nothing.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Brian May <bam@snoopy.apana.org.au> writes:

>>>>>> "Georg" == Georg Bauhaus <bauhaus@futureapps.de> writes:
>
>     Georg> $ echo *.ads
>
> Get a real shell !
>
> I get:
>
> zsh: no matches found: *.ads

You get the same with bash and most bourne shells if you set the
appropriate flags here. Instead of answering to any (IMHO) mistaken
contribution in this thread here, I was planning to write a little
essay "And Unix does it bloody right after all!" (in which I correct
all those misconception, write useful things about Unix shell usage
and philosophy and post a link here). Alas -- it will not be done
soon, as I can already see: I got bogged down in other things.

Basically we're back to the old bone of contention (I think we had
that at least another time recently about FPLs) between me an Georg:
Can a user be bothered to know his/her tools or is the answer (he,
Georg, too often gets) to RTM just bloody cheek?

I think that cannot be answered finally, but I certainly prefer to
have a powerful tool and read the manual and usually I prefer to work
with users that can need not be babied through everything and after
years of using a "GUI" still do not know about a hierarchical
filesystem (not even about the concept, not about the name) and are
still absolutely confused about all the things they see on windows
explorer. makes finding anything again a bit difficult for them if the
"default" directory of an application changed ...

Regards -- Markus


> which forces you to quote the value if thats what you really wanted:
>
>> echo "*.ads"
> *.ads
>
> or set NULLGLOB:
>
>> setopt NULLGLOB
>> echo *.ads
>
> which expands *.ads into nothing.
> -- 
> Brian May <bam@snoopy.apana.org.au>

Re: Ada.Command_Line and wildcards

[Martin Krischik]

Brian May schrieb:

>>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>     Martin> No, The VMS also won't expand wildcard. In fact Unix
>     Martin> shells are pretty alone here. And they got it wrong. Bot
>     Martin> Dos and VMS will warn you on:
> 
>     Martin> DEL *.*
> 
>     Martin> but not on
> 
>     Martin> DEL Some_File.Txt
> 
> I realize this thread is old, but if I type "rm *", my shell (zsh) asks:
> 
> zsh: sure you want to delete all the files in /tmp/a [yn]?

Others pointed out Z Shell as well which got me to give Z Shell a try. 
And you know what: I like it!

> 
> DOS *still* has this broken special case *.* wildcard? That is dated
> from 8.3 filenames.

DOS is not the only one, VMS got that as well - only VMS has 32.32 file 
names (unless you use the POSIX compliant ODS5 file system).

As for windows Yes and no! *.* and * will both delete the same file list:

-----------------------------------------
 >del *
C:\Temp\temp\* : Are you sure (Y/N)? Y
Deleting C:\Temp\temp\x
Deleting C:\Temp\temp\x.x
      2 files deleted
-----------------------------------------
 >del *.*
C:\Temp\temp\*.* : Are you sure (Y/N)? Y
Deleting C:\Temp\temp\x
Deleting C:\Temp\temp\x.x
      2 files deleted
-----------------------------------------

Dos and Windows are of course a mess - my quote was more in the 
direction of VMS. The VMS shell has very good foundations but is lacking 
in eye candy, syntactic sugar and bells&whistles. - Sufficiently lacking 
that working with it is unpleasant.

Martin

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Mon, 2007-03-05 at 12:07 +1100, Brian May wrote:
> >>>>> "Georg" == Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
>     Georg> $ echo *.ads
> 
> Get a real shell !

Sure. Point is, we had been talking about Unix design choices
not about what I am seemingly doing (doing according to you
and others, that is, which is not what I'm doing :).

Many essential shell scripts are built around Unix shell details.
E.g. software configuration scripts tend to stubbornly use a mix
of bash (sic, not sh, not ksh, not SUN sh), m4, sed, C helpers,
etc etc. In particular, they require the Unix process model.

See the current difficulties in translating recent GCC in a
MinGW environment.

Suppose you want to port some piece of Unix software to some other
system, a text processing tool, say. The C source is in fact
perfectly portable ANSI C. But it can be real hard to get the C source
through the configure stage only because configuration _depends_
on original style Unix shells and the Unix process model (e.g. piped
processes "within" a backtick (yes, I know $(), not the point), result
to be assigned to some variable. The GNU "standard" config.guess is
such a thing.)

On occasions like these the choice of a shell matters. It is less
relevant what you or I would choose, because we don't have a choice!
(Other than occasionally ask the developers to consider the
consequences of a larger Unix dependence graph when they claim
their program is portable to non-Unix systems.)

> or set NULLGLOB:
> 
> > setopt NULLGLOB
> > echo *.ads

Yes, certainly. Now for contrast, if I log into a system where
I participate in a *shared* account and where system defaults *must*
not be changed, and find a huge list of predefined aliases.
I wasn't amused once when I found out that "unzip" was an alias,
setting a number of options. And yes, I know how to disable aliases.
Having to debug shell setups isn't an argument in favor of typical
Unix environments in my book, in particular if these are "immutable"
system settings. But these seem to be the new Unix hackers' favorites.

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Mon, 2007-03-05 at 12:07 +1100, Brian May wrote:
>> >>>>> "Georg" == Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>>     Georg> $ echo *.ads
>> 
>> Get a real shell !
>
> Sure. Point is, we had been talking about Unix design choices
> not about what I am seemingly doing (doing according to you
> and others, that is, which is not what I'm doing :).


Hi Georg, 

As long as your arguments are heavily based on your experience and
practice we have to talk about what you're doing or we can stop
discussing.



> Many essential shell scripts are built around Unix shell details.
> E.g. software configuration scripts tend to stubbornly use a mix
> of bash (sic, not sh, not ksh, not SUN sh), m4, sed, C helpers,
> etc etc. In particular, they require the Unix process model.
>
> See the current difficulties in translating recent GCC in a
> MinGW environment.
>
> Suppose you want to port some piece of Unix software to some other
> system, a text processing tool, say. The C source is in fact
> perfectly portable ANSI C. But it can be real hard to get the C source
> through the configure stage only because configuration _depends_
> on original style Unix shells and the Unix process model (e.g. piped
> processes "within" a backtick (yes, I know $(), not the point), result
> to be assigned to some variable. The GNU "standard" config.guess is
> such a thing.)

Most (auto-) configuration concepts are really bad hacks. They are
hardly Unix design choices. The wrong place to fix that is to change
the shell or the prcess model. The right way to do it, is, to rethink
the way one produces platform specific sources from the common source
corpus.


> Yes, certainly. Now for contrast, if I log into a system where
> I participate in a *shared* account and where system defaults *must*

> not be changed, and find a huge list of predefined aliases.
> I wasn't amused once when I found out that "unzip" was an alias,
> setting a number of options. And yes, I know how to disable aliases.

Really bad practice (shared accounts, changing definition of known
names) does not make a good argument against Unix design choices.

> Having to debug shell setups isn't an argument in favor of typical
> Unix environments in my book, in particular if these are "immutable"

No. I want to be able to define short cuts in MY account. And I want
to be able to change setups in a controlled way, since it make a
difference in which toolset/world I'm working -- and sometimes one
needs multiple (conflicting) toolset at the same machine.

> system settings. But these seem to be the new Unix hackers' favorites.

new Unix hacker?

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Simon Wright]

Martin Krischik <krischik@users.sourceforge.net> writes:

> DOS is not the only one, VMS got that as well - only VMS has 32.32
> file names (unless you use the POSIX compliant ODS5 file system).

39.39, I thought?

Re: Ada.Command_Line and wildcards

[Brian May]

>>>>> "Georg" == Georg Bauhaus <bauhaus@futureapps.de> writes:

    Georg> Suppose you want to port some piece of Unix software to
    Georg> some other system, a text processing tool, say. The C
    Georg> source is in fact perfectly portable ANSI C. But it can be
    Georg> real hard to get the C source through the configure stage
    Georg> only because configuration _depends_ on original style Unix
    Georg> shells and the Unix process model (e.g. piped processes
    Georg> "within" a backtick (yes, I know $(), not the point),
    Georg> result to be assigned to some variable. The GNU "standard"
    Georg> config.guess is such a thing.)

The topic seems to have changed to standards.

There are POSIX standards, that define standard features required by
shells.

The only problem is that the POSIX standard can be a bit restrictive
at times. As a result, shells like bash define extensions to the base
standard.

However, Debian has a policy that any script that requires non-POSIX
shell features but declare itself to use /bin/bash instead of /bin/sh.

It still is a problem though, but at least it is getting addressed by
some vendors.

Then we get to the topic of autoconf/automake - I think I am not alone
on this newsgroup when I think they are ugly.... Again, the reason
they are ugly is due to a lack of standards - the requirement is to be
able to compile an application on different platforms that can be very
different.

    Georg> Yes, certainly. Now for contrast, if I log into a system
    Georg> where I participate in a *shared* account and where system
    Georg> defaults *must* not be changed, and find a huge list of
    Georg> predefined aliases.  I wasn't amused once when I found out
    Georg> that "unzip" was an alias, setting a number of options. And
    Georg> yes, I know how to disable aliases.  Having to debug shell
    Georg> setups isn't an argument in favor of typical Unix
    Georg> environments in my book, in particular if these are
    Georg> "immutable" system settings. But these seem to be the new
    Georg> Unix hackers' favorites.

This is a problem for any shared accounts, on any system, where it is
possible to adjust preferences. Different people will have different
preferences.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada.Command_Line and wildcards

[Brian May]

>>>>> "Markus" == Markus E Leypold <Markus> writes:

    Markus> was planning to write a little essay "And Unix does it
    Markus> bloody right after all!" (in which I correct all those
    Markus> misconception, write useful things about Unix shell usage
    Markus> and philosophy and post a link here). Alas -- it will not

To be fair, Unix does have issues, e.g.

- lots of incompatible standards. "The problem with standards is that
there are so many to choose from!"

- easy to shoot yourself in the foot, especially for a beginner - but
even experienced people can do this too.

e.g


accidental space changes the meaning of the command:
> rm -rf / path/to/my/directory   


I thought the target directory was optional:
> mv ../file*                        

instead of "mv ../file* ." expanded into "mv ../file.c ../file.c.bak"
which wasn't what I wanted - fortunately, after studying the screen
for about five minutes (I was inexperienced) I suddenly realized I
hadn't lost *any* of my work (my tutor said I had lost everything).


on auto-pilot, typing in the wrong command:
> rm /etc/init.d/network

instead of
> vim /etc/init.d/network

whoops!


*don't* do this automatically from a script:
> deluser --remove-home abcd

For why, see: http://bugs.debian.org/190427 (deluser may have been
improved to make it more robust against this error).


- there are probably lots of shell scripts that break when given
filenames containing spaces, even though space is a legal filename
character. The POSIX shell standard doesn't always make it easy when
dealing with such files.

- the shell is often overused when spawning external commands from
non-shell languages in order to parse the command line (e.g. the only
way to spawn a command from PHP is via the shell) - this not only can
break filenames with spaces too (if not done correctly) but can result
in obscure security holes.


However, its what I am use to, what I like, and much better then
anything ever produced by Microsoft.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Mon, 2007-03-05 at 14:20 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > On Mon, 2007-03-05 at 12:07 +1100, Brian May wrote:
> >> >>>>> "Georg" == Georg Bauhaus <bauhaus@futureapps.de> writes:
> >> 
> >>     Georg> $ echo *.ads
> >> 
> >> Get a real shell !
> >
> > Sure. Point is, we had been talking about Unix design choices
> > not about what I am seemingly doing (doing according to you
> > and others, that is, which is not what I'm doing :).
> 
> 
> Hi Georg, 
> 
> As long as your arguments are heavily based on your experience and
> practice we have to talk about what you're doing or we can stop
> discussing.

Right, but my experience, while not based on thousand of observations
of Unix users, includes some of this. Moreover, some arguments
are purely technical, like the many "white space thingies" in
shell programming. Or the drastic semantic consequences of minor
changes in quoting-or-not-or-differently type-less text that have
been mentioned a while ago.

This is very much unlike Ada :-)

> Most (auto-) configuration concepts are really bad hacks. They are
> hardly Unix design choices. The wrong place to fix that is to change
> the shell or the prcess model.

Right. But don't you think that this kind of use of Unix tools
must be investigated such that the Unix design choices are taken
into account while doing so? What is the reason that the Unix
design choices do not help prevent complex, strongly coupled,
highly dependent pieces of shell programming? Will REXX programs
look the same?

Unlike Ada, Unix favors the *writer* over the reader. No surprise I
think. But damn right?

When it comes to echo *.ads, a decision was necessary as to what
should happen when there is no matching file name. The choice was
not: reflect this fact and produce the empty result. This might
have had other consequences somewhere else. Instead, it
was to produce the pattern itself--which is very different from
a file name. echo(1) is a highly overloaded function, so to speak,
very flexible. So flexible indeed that it takes some time to
learn how this one command interacts with all sort of things Unix.

That's unlike what ls produces. But it is consistent with ls and with
the other uses of echo by 1..* mental indirections. Now, what might
be an alternative design choice?

I wouldn't mind programs that just read their arguments unexpanded
and call the OS expansion service, an iteration device for example.
And if there is no matching thing, then *every* program consistently
produces empty results! One difference, then, is that an ls will
consistently produce nothing for no argument. This will require more
typing when you want something, for example ls -d "*".
I don't think any Unix programmer will see the benefits of more
typing. But having gone some way through the Ada experience I think
this the right thing.

Or with this change, if calls to the expansion service should not
be part of Unix programs, why not have

$ ls $(expand "*.ads")

It isn't more difficult to understand, and it doesn't work with
large directories either. It requires that shell commanders
say what they want, though. (I'm not a fan of large directories
when we do have a hierarchical filing system, but again, who
am I to suggest that a program be redesigned to use a hierarchy
of directories for file storage.)


> > system settings. But these seem to be the new Unix hackers' favorites.
> 
> new Unix hacker?

There was a time when you knew that logging into a Unix system (HP,
BSD, etc.) would give you a very basic setup. But you could use the
entire Unix Toolbox, without surprises. Reaping the benefits of some
shell programming would give you a productive environment.
  Today, the new Unix hackers try to give you a "productive" environment
by default. You may have to expect AI-driven completion, and lots
of aliases, and not only will learning some Unix shell programming
still be profitable, but in addition you have to learn how to bridle
typical default shell setups. Unix used to be configurable (after
mastering the design choices). Now it is pre-configured... I guess
the consequence is that many users think they won't need to learn
shell programming.

-- Georg
For large jobs, ed(1) is the most efficient editor

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Mon, 2007-03-05 at 14:20 +0100, Markus E Leypold wrote:
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>> > On Mon, 2007-03-05 at 12:07 +1100, Brian May wrote:
>> >> >>>>> "Georg" == Georg Bauhaus <bauhaus@futureapps.de> writes:
>> >> 
>> >>     Georg> $ echo *.ads
>> >> 
>> >> Get a real shell !
>> >
>> > Sure. Point is, we had been talking about Unix design choices
>> > not about what I am seemingly doing (doing according to you
>> > and others, that is, which is not what I'm doing :).
>> 
>> 
>> Hi Georg, 
>> 
>> As long as your arguments are heavily based on your experience and
>> practice we have to talk about what you're doing or we can stop
>> discussing.
>
> Right, but my experience, while not based on thousand of observations
> of Unix users, includes some of this. Moreover, some arguments
> are purely technical, like the many "white space thingies" in
> shell programming. Or the drastic semantic consequences of minor
> changes in quoting-or-not-or-differently type-less text that have
> been mentioned a while ago.

Fine. Again let me differentiate that the syntax has nothing to do
with Unix design choices, that is "only" a shell thing and the shell
can be replaced (already has more than once).

The limitation of the length of the command line passed to a process
on the other side is a Unix thingy, though I think you're all
overrating the impact, following the red herring of wild cards. Unix
_also_ supports the VMS-like model of calling to a procedure which
delivers input items one by one: It's called pipe, and modern shells
support passing lists of files by pipe, using rather universal
criteria, with something called process substitution:

  tar -T <$(find . -mtime +3 -type f) -cf foo.tgz

should archive all files that are older than 3 days.

As far as the shell syntax is concerned:  

  - There are shells that are based on established programming
    languages (ipython, scheme shell)

  - I do think the VMS shell has the same problem with the difference between 

      foo yadda*.* 
   
    and
  
      foo yadda *.*


  - I do see user complaining about having to type quotes all the
    time.

  - Piping untyped text between processes and having untyped files is
    certainly to some extend one of the _features_ of Unix.

    It is thinkable to replace the Bourne shell by a modern byte code
    based shell and most of the tools by dynamically loaded
    libraries. In this case there would be a difference between piping
    between processes and command composition and typing can be
    introduced.

> This is very much unlike Ada :-)

>
>> Most (auto-) configuration concepts are really bad hacks. They are
>> hardly Unix design choices. The wrong place to fix that is to change
>> the shell or the prcess model.

> Right. But don't you think that this kind of use of Unix tools
> must be investigated such that the Unix design choices are taken
> into account while doing so? 

Yes, but the brokenness of the auto configuration philosophy has
nothing to do with Unix design choices. It is actually a problem VMS
wouldn't have, since it doesn't exist in different sizes on vastly
different platforms. 

> What is the reason that the Unix design choices do not help prevent
> complex, strongly coupled, highly dependent pieces of shell
> programming?

Neither does Ada: You can write strongly coupled amorphous code in any
langauge. And the shell is, I repeat, no programming language, but a
command language. 

> Will REXX programs
> look the same?

The same as what?

> Unlike Ada, Unix favors the *writer* over the reader. No surprise I
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I cannot follow your argument here. Ada is a programming language,
Unix is an operating system. Are you comparing apples with oranges?

And would I want to have a command prompt with the verbosity of Ada?

> think. But damn right?

Yes.


> When it comes to echo *.ads, a decision was necessary as to what
> should happen when there is no matching file name. 

> The choice was
> not: reflect this fact and produce the empty result. 

The choice was to make it user settable. I've already quoted the
relevant flag elsewhere.

> This might have had other consequences somewhere else. Instead, it
> was to produce the pattern itself--which is very different from a
> file name.

... but adds a bit of more convencience for interactive use. You shell
scripts should either quote or use the appropriate setting.

> echo(1) is a highly overloaded function, so to speak, very flexible.

? It only ever does echo its arguments to standard output. Only 'true'
and 'false' are simpler.

> So flexible indeed that it takes some time to learn how this one
> command interacts with all sort of things Unix.

I repeat: What you learn here is not about echo(1), but about the way
the shell handles the production of arguments before executing a
process. A short (or longer) look into shell manual will clarify all
these things once and for all, for all "shell commands".

> That's unlike what ls produces. 

I already explained all this. You're again attributing something to a
"difference" between 'ls' and 'echo' that simply doesn't exist, at
least regarding the handling of arguments.

> But it is consistent with ls and with the other uses of echo by 1..*
> mental indirections. Now, what might be an alternative design
> choice?

Not doing wildcard expansion at all. Certainly.


> I wouldn't mind programs that just read their arguments unexpanded

I would mind it, since I want syntax to refer to groups of files.

And BTW: Unix tools don't "read their arguments expanded". They often
don't expand arguments at all, instead it the shell, that provides
... and if you don't want ... just turn it off ... or ... quote. You
know the text already, I've written it for a number of time now.

> and call the OS expansion service, an iteration device for example.
> And if there is no matching thing, then *every* program consistently
> produces empty results! One difference, then, is that an ls will
> consistently produce nothing for no argument. This will require more
> typing when you want something, for example ls -d "*".

Please, Georg, read and try to understand what I'm writing. Most of
what you complain about are features that CAN be turned of by at most
4 lines in your login script. You can also just use another shell.

> I don't think any Unix programmer will see the benefits of more
> typing. But having gone some way through the Ada experience I think
> this the right thing.

For a shell? Better even: typed files? Push XML to the file system? No
-- that's not the way to go. 

I agree, a bit more of typing would be a nice thing: Extended
attributes that would deliver typing hints to processing programs and
a common system of shared libraries that somehow represent readers and
writers for certain types / representations. That would be really
useful.

>
> Or with this change, if calls to the expansion service should not
> be part of Unix programs, why not have
>
> $ ls $(expand "*.ads")

Process substitution would provide this, if 'ls' had a 'read from this
file parameter. You can achieve exactly this effect by writing (lf => list files):

  lf(){ F="$1"; shift; xargs <"$F" ls ; }

and then

  lf <(find /etc -type f -name 'fs*' )

As it is, until now it probably wasn't important enough to most people
who could well live with

  find /etc -type f -name 'fs*' | xargs ls

> It isn't more difficult to understand, and it doesn't work with
> large directories either. It requires that shell commanders
> say what they want, though. 

Process substitution, though, works with large directories. And the
suggested metgod of expansion is more flexible, since it can select
after modification date etc.


> (I'm not a fan of large directories
> when we do have a hierarchical filing system, but again, who
> am I to suggest that a program be redesigned to use a hierarchy
> of directories for file storage.)
>
>
>> > system settings. But these seem to be the new Unix hackers' favorites.
>> 
>> new Unix hacker?
>
> There was a time when you knew that logging into a Unix system (HP,
> BSD, etc.) would give you a very basic setup. But you could use the
> entire Unix Toolbox, without surprises. Reaping the benefits of some
> shell programming would give you a productive environment.


>   Today, the new Unix hackers try to give you a "productive" environment

Today? The last time I saw a basic, standardized Unix environment was
V7. You must have missed out on all that Apollo Domain stuff, the
Munix system (Cadmus) etc.

> by default. You may have to expect AI-driven completion, and lots
> of aliases, and not only will learning some Unix shell programming
> still be profitable, but in addition you have to learn how to bridle
> typical default shell setups. 

It is arguable bad pratice to have all that on by default, but on the
other side, this is hardly a "Unix design choice". The distributions I
use, don't have it on and as an admin I always let it stay an option
and tell my users just to source 'init.completion' or
'init.gnu-pack-2' something like that in their setup.

> Unix used to be configurable (after mastering the design
> choices). Now it is pre-configured...

Is it? My Debian system sets the path in /etc/profile and a default
umask. The rest is under my control.

> I guess the consequence is that many users think they won't need to
> learn shell programming.

Well -- hardly anyone nows shell programming any more, I've
notice. Even people who call themselves hackers and developers ...

> For large jobs, ed(1) is the most efficient editor

If used with the following compatibility command:

  $ ed
  ! emacs


Regards -- Markus

Re: Ada.Command_Line and wildcards

[Jacob Sparre Andersen]

Georg Bauhaus wrote:

> Unlike Ada, Unix favors the *writer* over the reader. No surprise I
> think. But damn right?

Considering that the Unix shell is created for _interactive_ use, this
is certainly not a surprise.

But with our new, fancy, interactive shells (like Zsh) it may be time
to paraphrase Preben Randhol's signature:

   Saving keystrokes is the job of the interactive shell, not the
   programming language.

With GNU tools I generally use the long version of the command line
arguments.  In interactive use it is not significantly (if at all)
slower than the short versions, since Zsh helps quite a lot.  And in
programs it improves readability.

> When it comes to echo *.ads, a decision was necessary as to what
> should happen when there is no matching file name. The choice was
> not: reflect this fact and produce the empty result.

Which might have been nice.

> I wouldn't mind programs that just read their arguments unexpanded
> and call the OS expansion service, an iteration device for example.

If that is _the_ way to scan a directory for files, it may be possible
to get (practically) all programmers to use it, and thus give a
uniform file name pattern expansion service.  But what rules should
this uniform service follow?  Just plain old fashioned globbing?  Or
the extended Zsh version?  Or something completely different?  Can we
make the pattern matcher user selectable?  (Programs would of course
have to select one, to work consistently with internal patterns.)

> And if there is no matching thing, then *every* program consistently
> produces empty results!

Yes. :-)

> One difference, then, is that an ls will consistently produce
> nothing for no argument. This will require more typing when you want
> something, for example ls -d "*".

Couldn't one just expand the rules for "ls", so calling it with the
name of a directory corresponds to "ls <dir>/*" (in globbing terms)?
Since no explicit directory means ".", then "ls" will correspond to
"ls ./*" and work like the more lazy of us would like it to.

This would be different from calling "echo" without any arguments.
But it would be so because of the _meaning_ of the arguments.

> I don't think any Unix programmer will see the benefits of more
> typing. But having gone some way through the Ada experience I think
> this the right thing.

With a sufficiently smart interactive shell, we can probably cut down
on the typing at the same time as we improve the handling of big
directories.

> Or with this change, if calls to the expansion service should not be
> part of Unix programs, why not have
>
> $ ls $(expand "*.ads")

Much too long to type.  And it wouldn't solve the "too many arguments"
problem.  If there should be configurable file name pattern matching,
I would rather do it using an environment variable:

   FILE_NAME_EXPANSION=globbing ls *.ads

> (I'm not a fan of large directories when we do have a hierarchical
> filing system, but again, who am I to suggest that a program be
> redesigned to use a hierarchy of directories for file storage.)

When I store more than 10_000 messages from comp.lang.ada; how should
I distribute them in a hierarchy of directories?  I might for example
need to grep them for Preben's signature.

> For large jobs, ed(1) is the most efficient editor

For some reason I just use vi(1) and sed(1).

Greetings,

Jacob
-- 
�When in Rome; burn it�                        -- Diziet Sma

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

On Mar 6, 7:56 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
> When it comes to echo *.ads, a decision was necessary as to what
> should happen when there is no matching file name. The choice was
> not: reflect this fact and produce the empty result. This might
> have had other consequences somewhere else. Instead, it
> was to produce the pattern itself--which is very different from
> a file name.

One of those other consequences is that many, if not most, UNIX
programs treat a no-argument command as meaning "do your default
action". So 'ls' with no directory arguments lists the current
directory and 'cat' with no file arguments reads standard input, and
so forth. If I wrote 'cat *.ads' and there were no such files and the
shell expanded that to nothing, 'cat' would sit endlessly awaiting
input from the terminal. As it stands, I get 'cat: cannot open *.ads'
and I see the problem. What we have is a design that works pretty well
interactively and pretty well in scripts, failing only on a few weird
cases. That's good enough, because it gets you to 90% of what you
need, and Worse is Better.

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

"Hyman Rosen" <hyman.rosen@gmail.com> writes:

> On Mar 6, 7:56 am, Georg Bauhaus <bauh...@futureapps.de> wrote:
>> When it comes to echo *.ads, a decision was necessary as to what
>> should happen when there is no matching file name. The choice was
>> not: reflect this fact and produce the empty result. This might
>> have had other consequences somewhere else. Instead, it
>> was to produce the pattern itself--which is very different from
>> a file name.
>
> One of those other consequences is that many, if not most, UNIX
> programs treat a no-argument command as meaning "do your default
> action". So 'ls' with no directory arguments lists the current
> directory and 'cat' with no file arguments reads standard input, and
> so forth. If I wrote 'cat *.ads' and there were no such files and the
> shell expanded that to nothing, 'cat' would sit endlessly awaiting
> input from the terminal. As it stands, I get 'cat: cannot open *.ads'
> and I see the problem. What we have is a design that works pretty well
> interactively and pretty well in scripts, failing only on a few weird
> cases. That's good enough, because it gets you to 90% of what you
> need, and Worse is Better.

No, worse is not better, but shell script is, strictly spoken, not a
programming language but a interactive command language.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Wed, 2007-03-07 at 11:21 -0800, Hyman Rosen wrote:

> One of those other consequences is that many, if not most, UNIX
> programs treat a no-argument command as meaning "do your default
> action".

Yes, it is this default meaning that I had thought about when
suggesting that a possible alternative in designing Unix command
line conventions would have been not to do implicit, default,
things. In this case, when I wanted to cat standard input into
a file, I just say what I want:

$ cat /dev/stdin > my.text   # or use - in place of /dev/stdin
It works!
^D
$

(Requesting the standard input as /dev/stdin, maybe -, but not '',
actually fits nicely with the way Unix uses the filing
system. And similarly for Plan 9. :)

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Tue, 2007-03-06 at 16:07 +0100, Markus E Leypold wrote:
>  Again let me differentiate that the syntax has nothing to do
> with Unix design choices, that is "only" a shell thing and the shell
> can be replaced (already has more than once).

Well, I find it difficult to imagine Unix without the
programmable shells, intended to be used as glue between the
tools. For me, this counts as part of the design of Unix.

>  modern shells
> support

Yes, it is a good thing that modern shells support... ,
and I find reading tar names from pipes a natural extension.
(Anyone using cpio, besides comeaucomputing.com? ;-)
Incidentally, in a more limited environment like DOS,
programs tended to have an @-parameter for reading things
from a file. Simple, but parameterizing a program then is more
like assignment to temporary variables instead of using 
elegant functional pipes. And there is no garbage collection,
the @-files are still there when the program has finished :-)


> > What is the reason that the Unix design choices do not help prevent
> > complex, strongly coupled, highly dependent pieces of shell
> > programming?
> 
> Neither does Ada: You can write strongly coupled amorphous code in any
> langauge. And the shell is, I repeat, no programming language, but a
> command language. 

I disagree. The Unix shells are programmable, this is one of
the things that made them different. So there is programming
going on. It's fun, I spent almost half the day preparing a
cron job, enjoying varname=${1:-$(date +%Y-%m-%d)} and such.
Sparingly though, as others in the shop might want to read
this shell script.


> > Will REXX programs
> > look the same?
> 
> The same as what?

The same as the expressions above.

> > Unlike Ada, Unix favors the *writer* over the reader. No surprise I
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> I cannot follow your argument here. Ada is a programming language,
> Unix is an operating system. Are you comparing apples with oranges?

No. When I mean Unix design choices, I mean Unix as it was planned,
granted, and sold (with troff, sh, etc.). Unix operators write.
Unix shell program authors write. Programmers can use (I hope) some
shell programming to create software configurations. But considering
names like "creat" (sic) and the like, traditional short option letters,
etc., I fail to see how typical Unix abbreviations aren't favoring the
writer? (Of course, if your audience consist of readers who read nothing
but "Unix stuff" they will be well served with just abbreviations.)



> > When it comes to echo *.ads, a decision was necessary as to what
> > should happen when there is no matching file name. 
> 
> > The choice was
> > not: reflect this fact and produce the empty result. 
> 
> The choice was to make it user settable. I've already quoted the
> relevant flag elsewhere.

No, I mean the use case perspective that Hyman has mentioned.
You can run the ls(1) program without argument, and it produces
results that make sense in most cases. Case distinctions come
into play later.


>  A short (or longer) look into shell manual will clarify all
> these things once and for all, for all "shell commands".

Every longer look into a Unix subject might clarify.
However, the question is whether there should be a need for that
much clarification in the first place. That's the point.


> You're again attributing something to a
> "difference" between 'ls' and 'echo' that simply doesn't exist, at
> least regarding the handling of arguments.

>From the use case perspective there is a difference between echo
and ls. Why is it better when a user has to learn one or two levels of
indirection only in order to understand how Unix programs interact with
Unix shell expansion rules? Sounds like: This car has four pedals.
You will drive better when you learn how to use them. Please note that
when this car was designed, most other cars needed two operators, and
they didn't have pedals at all! (Comparing JCL, say.)



> And BTW: Unix tools don't "read their arguments expanded".

I mean after expansion has taken place (or not),
$ strace ls *.pl 2>&1 |head -1

execve("/bin/ls", ["ls", "check.pl", "test_md.pl", "test.pl"], ...

After expansion has taken place, there is something in argv
that I'm calling expanded arguments. No?



> Please, Georg, read and try to understand what I'm writing. Most of
> what you complain about are features that CAN be turned of

The Unix design choices can't be turned off. ls(1) has a default
behaviour. That's Unix. (And DOS, too.) I'm a Unix user by choice.
But I can't modify every Unix system I have to use on a daily basis.

Re: Ada.Command_Line and wildcards

[Simon Wright]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> I find reading tar names from pipes a natural extension

What if the names have spaces in them?

For find/xargs you have -print0/-0 respectively (I say eew, but
quietly)

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Tue, 2007-03-06 at 16:07 +0100, Markus E Leypold wrote:
>>  Again let me differentiate that the syntax has nothing to do
>> with Unix design choices, that is "only" a shell thing and the shell
>> can be replaced (already has more than once).
>
> Well, I find it difficult to imagine Unix without the
> programmable shells, intended to be used as glue between the

Aaaargh!! Did I say that? No, no, no! I said "replaced", not
abandoned. And since I already recommended some other shells (that
have a more regular syntax) that should have been clear enough.

> tools. For me, this counts as part of the design of Unix.

But the <censored> syntax of the shell has nothing <censored> to do
with a design choice "of Unix". It is not fixed. (This argument tires
me -- have you even tried to understand what I wrote before?)

>>  modern shells
>> support
>
> Yes, it is a good thing that modern shells support... ,
> and I find reading tar names from pipes a natural extension.

So? That interesting does not count as a positive point with Unix for
you, whereas the syntax of a shell built for a 16-bit processor (the
pdp/11) and kept out of tradition counts against Unix, despite the
fact that it is not an immutable part of the design?

<...>


>> > What is the reason that the Unix design choices do not help prevent
>> > complex, strongly coupled, highly dependent pieces of shell
>> > programming?
>> 
>> Neither does Ada: You can write strongly coupled amorphous code in any
>> language. And the shell is, I repeat, no programming language, but a
>> command language. 
>
> I disagree. The Unix shells are programmable, this is one of
> the things that made them different. So there is programming
> going on. 

Your choice. Don't complain to me if you use the wrong tools. Other
people have switched to perl or python for things like this (cron
jobs). 

> It's fun, I spent almost half the day preparing a
> cron job, enjoying varname=${1:-$(date +%Y-%m-%d)} and such.
> Sparingly though, as others in the shop might want to read
> this shell script.

Thanks for sharing that story with us. The conclusion for a more
general view on Unix is ... -- Please complete the following sentence:

  Georg B spents almost half the day preparing a cron Job. From that
  we must conlude that Unix __________.

Thanks.

>> > Will REXX programs
>> > look the same?
>> 
>> The same as what?
>
> The same as the expressions above.

And? Will they? Probably not. REXX had another syntax AFAIR. BTW even
C programs, Python, FORTRAN and Plankalk�l will not look the
same. What does that tell us?

And yes I'm deliberately obtuse now, since you alway just hint on
something offering spurious anecdotal evidence but than fail to spell
out your complete reasoning (which usually cannot be completed due to
the spuriousness of the anecdote that is supposed to show something).


>> > Unlike Ada, Unix favors the *writer* over the reader. No surprise I
>>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> I cannot follow your argument here. Ada is a programming language,
>> Unix is an operating system. Are you comparing apples with oranges?
>
> No. When I mean Unix design choices, I mean Unix as it was planned,
> granted, and sold (with troff, sh, etc.). 

Fine. So you're still comparing apples with oranges.

> Unix operators write.
> Unix shell program authors write. 

Yes, *Unix shell* programmers write. You know, a drivers license is
somewhat different from a driver, etc. You're a German, but probably
not Germany (notwithstanding bad image campaigns).

"Unix shell" is something to be distinguished from Unix. Care to
rephrase your statement that I can see what you mean?

> Programmers can use (I hope) some
> shell programming to create software configurations. But considering
> names like "creat" (sic) and the like, traditional short option letters,
> etc., I fail to see how typical Unix abbreviations aren't favoring the

Hm. 'creat' is not in my shell manual.

> writer? (Of course, if your audience consist of readers who read nothing
> but "Unix stuff" they will be well served with just abbreviations.)

 - cacls folder  /e /r user

 - @DUA2:[...]

And don't force me to quote from the VMS source code.

Or perhaps all operating systems have bad design choices? Why then are
you specifically shooting against Unix? 


>> > When it comes to echo *.ads, a decision was necessary as to what
>> > should happen when there is no matching file name. 
>> 
>> > The choice was
>> > not: reflect this fact and produce the empty result. 
>> 
>> The choice was to make it user settable. I've already quoted the
>> relevant flag elsewhere.

> No, I mean the use case perspective that Hyman has mentioned.

Which was that? I don't think I want to read back through the thread
to interpret this reference.

> You can run the ls(1) program without argument, and it produces
> results that make sense in most cases. Case distinctions come
> into play later.

NO, bloody no. Just turn wildcard expansion off _completely_ AND/OR
turn of that the expansion of a non-matching pattern is the pattern
itself. IT IS USER SETTABLE. Just do it. Case distinctions? What? I
don't even know what you're talking about here.

But I'm certain, I'm missing some finely spun argument here which
would demonstrate that the fact that the users cannot be bothered to
understand their tools and cannot be bothered to change setting -- how
that suddenly becomes the general and deep fault of the Unix design
choices again.

Well -- as far as I'm concerned, you can look for hairs in your soup
as long and as hard as you want. I, simply, find it more productive to
understand stuff and see how I can work with it, instead of waisting
energy to should-have-beens and cant-have-it-like-that where I simply
have no way to force a change now. I've other and better wind mills to
fight.

I'm certainly not saying that Unix is perfect. There is quite a lot of
things I'd improve if I could.

But the things you complain about a certainly either not problems at
all and certainly not important.


>>  A short (or longer) look into shell manual will clarify all
>> these things once and for all, for all "shell commands".

> Every longer look into a Unix subject might clarify.  However, the
> question is whether there should be a need for that much
> clarification in the first place. That's the point.

"That much" is a rather vague criterion. Again we're back to wether a
user/programmer can be bother to learn his tools.

BTW: "Concerning Ada: (Almost) every issue with Ada the ARM might
clarified by a look into the ARM or into Barnes excellent book.
However, the question is whether there should be a need for that much
clarification in the first place. That's the point". 

Do you see NOW how utterly empty such statement are?


>> You're again attributing something to a
>> "difference" between 'ls' and 'echo' that simply doesn't exist, at
>> least regarding the handling of arguments.


>>From the use case perspective there is a difference between echo
> and ls. Why is it better when a user has to learn one or two levels of

He has not. Just turn wildcard expansion off. The feature there for exactly
that purpose.

> indirection only in order to understand how Unix programs interact with
> Unix shell expansion rules? 

> Sounds like: This car has four pedals.
> You will drive better when you learn how to use them. Please note that
> when this car was designed, most other cars needed two operators, and
> they didn't have pedals at all! (Comparing JCL, say.)

More bad mataphors. Always a good way to drag out a discussion until
kingdom come.

What you require, is, that the car doesn't have any pedals and
that the user does not have to understand that a non-running car is
sometimes to be fixed by filling in gasoline, but sometimes by turning
on ignition.

>> And BTW: Unix tools don't "read their arguments expanded".
>
> I mean after expansion has taken place (or not),
> $ strace ls *.pl 2>&1 |head -1
>
> execve("/bin/ls", ["ls", "check.pl", "test_md.pl", "test.pl"], ...
>
> After expansion has taken place, there is something in argv
> that I'm calling expanded arguments. No?

No. _Unix tools_ still don't "read arguments epxanded". The _shell_
provides an optional language to _generate_ arguments. The _Unix tools_
have nothing to do with it.

>> Please, Georg, read and try to understand what I'm writing. Most of
>> what you complain about are features that CAN be turned of
>
> The Unix design choices can't be turned off. ls(1) has a default
> behaviour. That's Unix. 

But you DIDN'T complain about the ls behaviour. You DID complain about
the shell expansion, that CAN be turned off.

You're completely mixing things up. Does it even make sense to
continue this "discussion"?

>(And DOS, too.) I'm a Unix user by choice.

Who has such friends doesn't need enemies.

> But I can't modify every Unix system I have to use on a daily basis.

.profile, .bash_profile. cvs.

Yes, you can. And if you don't have a single system image or a
deployment mechanism for configurations on disjoint systems that again
is not a Unix design choice, but perhaps a choice of your system
administration / administrators.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Simon Wright <simon.j.wright@mac.com> writes:

> Georg Bauhaus <bauhaus@futureapps.de> writes:
>
>> I find reading tar names from pipes a natural extension
>
> What if the names have spaces in them?
>
> For find/xargs you have -print0/-0 respectively (I say eew, but
> quietly)

Space are probably not a problem (when reading from a pipe). New lines
in filenames are, though, but those also mess up the output of ls and
any other tool.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Thu, 2007-03-08 at 05:07 +0000, Simon Wright wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > I find reading tar names from pipes a natural extension
> 
> What if the names have spaces in them?

1/ I tell users that Unix file names shouldn't have spaces in them
2/ I deny that Unix shell design is based on not so recent choices.
3a/ I use --null and -T with tar
3b/ I use cpio

Does this sound like an Ada advocate insisting that Ada 83 was
damn right but if anyone wanted, they could even use inward
closures with Ada 2005?

> For find/xargs you have -print0/-0 respectively (I say eew, but
> quietly)

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

On Thu, 2007-03-08 at 10:16 +0100, Markus E Leypold wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:
> 
> > On Tue, 2007-03-06 at 16:07 +0100, Markus E Leypold wrote:
> >>  Again let me differentiate that the syntax has nothing to do
> >> with Unix design choices, that is "only" a shell thing and the shell
> >> can be replaced (already has more than once).
> >
> > Well, I find it difficult to imagine Unix without the
> > programmable shells, intended to be used as glue between the
> 
> Aaaargh!! Did I say that? No, no, no! I said "replaced", not
> abandoned.

I don't argue against using Unix, and not against configuring
Unix work environments either. The whole thread is about the 
consequences of some longstanding Unix design choices which
then established what can know be termed the Unix design.
Text substitution is still part of every successor design.

I really do know how to melt and loosen Unix design choices
and replace these choices with things I need today, on my machine.
  *BUT*:
(1) Textual substitution as in the original Unix design keeps
having consequences today, with or without new shells, with or
without pattern expansion. This is just a fact of life with Unix,
by design.
(2) Omissible text has consequences today, by design.

These are the design choices in question, see the prior postings
to this thread.

Suggesting replacement parts for pieces of Unix really means
suggesting to change its design. It isn't turned into Windows NT
by these changes, but someone coming from Unix will have to
learn how to use the new parts.

You keep listing perfect examples of how to improve on the Unix design,
by replacing parts of the design (e.g. different shells, hence
differently designed shells), new features, or by suggesting
to configure environments should it be necessary to overcome
default settings as per design. Fine. So the original design
has its flaws. (BTW, it is part of the design of
Unix that I *can* do these things. There is very little one
can comfortably do in this regard using cmd.exe without
extensions.)

By analogy, if we were talking about why they chose to make "tagged"
a keyword during the Ada 9X process and not make every type implicitly
tagged, we are talking about the Ada design (choices). For the notion
of Ada design, it doesn't matter that there can be Ada-like languages
that have implicit tags for every type. And it doesn't matter that I
can use Ada without Ada.Text_IO, or without tagged types; both are part
of the Ada design, no matter what. And this has consequences and
I have to know them, for good or bad.

Both Unix and Ada are entire things. (See e.g. Kernighan/Pike 1984).
You don't have to use either Unix or Ada in their entirety; you can
replace some parts, which is good.
If you used an encoding aware string type in place of Standard.STRING
etc, your program might be better, but you don't change the Ada
design choice for String types. You only avoid the consequences of the
original design. So the original design has consequences. Some
parts of the original design are just irreplaceable.

By turning off shell expansion, no one can change the Unix design
which offers shell expansion. (I doubt it is really used as just an
option in typical Unix use, but rather taken for granted.)
In particular, some parts of Unix design are just hard wired, as
you have demonstrated a number of times by informing us about your
knowledge of the many wires (mechanisms).



> Thanks for sharing that story with us. The conclusion for a more
> general view on Unix is ... -- Please complete the following sentence:
> 
>   Georg B spents almost half the day preparing a cron Job. From that
>   we must conlude that Unix __________.

I'll appreciate your view, although I trust no one will hurry to infer
Unix design properties from my having fun when working with Unix.

> Thanks.



>  What does that tell us?

[REXX, scsh, etc.] It tells about alternative designs. About a way
to compare design choices by their consequences. About what can be
done when it comes to successor designs.


> But I'm certain, I'm missing some finely spun argument here

Yes. I think you are missing the argument of this thread. That the
parts that make up Unix, with Bourne shell and C shell and expansions,
could have been designed differently in the past WRT how to
use textual substitution and WRT the amount of omissible text.
Much like "creat" (without the final letter 'e') could have been
named differently, as told by its creator.

Or should I accept that the Unix design was flawless in the
first place, and that programmers should just have learned
to omit the final letter from the word "create"? I think this
example is representative of some Unixisms. They are fun, but not
to be repeated as designed.


>  Again we're back to wether a
> user/programmer can be bother to learn his tools.

We are back to whether a design choice makes using a system
more or less work. Whether it has more pitfalls, requires more or
less configuration, more or less training to achieve the same
level of productivity, etc..


(BTW, are you saying that the expression argv[1] is not used when
reading arguments from the command line?)

Re: Ada.Command_Line and wildcards

[Robert Deininger]

In article <11wk29zr0.fsf@hod.lan.m-e-leypold.de>, Markus E Leypold
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote:

...

>As far as the shell syntax is concerned:  
>
...
>
>  - I do think the VMS shell has the same problem with the difference between 
>
>      foo yadda*.* 
>   
>    and
>  
>      foo yadda *.*

Out of curiosity, what is the problem here in VMS?

The first example passes 1 parameter (yadda*.*) to the command foo.  If
the number of required parameters for foo is <= 1, it will run. 
Otherwise, the shell will prompt for more parameters.

The second example passes 2 parameters (yadda and *.*) to command foo.  If
foo is defined with only 1 parameter, the shell will report a "too many
parameters" error instead of invoking foo.

If this behavior isn't reasonable, what behavior would be? 
Auto-correcting of typos, with a mind-reading option?

$ SET PROCESS/PARSE_STYLE=READ_MIND

Of course, the default would have to be /PARSE_STYLE=NOREAD_MIND to
maintain upward compatibility.  :-)

...

>>> Most (auto-) configuration concepts are really bad hacks. They are
>>> hardly Unix design choices. The wrong place to fix that is to change
>>> the shell or the prcess model.
>
>> Right. But don't you think that this kind of use of Unix tools
>> must be investigated such that the Unix design choices are taken
>> into account while doing so? 
>
>Yes, but the brokenness of the auto configuration philosophy has
>nothing to do with Unix design choices. It is actually a problem VMS
>wouldn't have, since it doesn't exist in different sizes on vastly
>different platforms. 

VMS certainly does exist in different sizes on different platforms.  But
the OS does a good job of hiding most of the underlying platform from
applications, so they don't need to care.

Auto-configuration style hacks are rarely used in native VMS
applications.  Usually, the information the hack is trying to figure out
can be obtained more directly.

Importing autoconfiguration hacks to VMS can be a nightmare.

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Thu, 2007-03-08 at 10:16 +0100, Markus E Leypold wrote:
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>> > On Tue, 2007-03-06 at 16:07 +0100, Markus E Leypold wrote:
>> >>  Again let me differentiate that the syntax has nothing to do
>> >> with Unix design choices, that is "only" a shell thing and the shell
>> >> can be replaced (already has more than once).
>> >
>> > Well, I find it difficult to imagine Unix without the
>> > programmable shells, intended to be used as glue between the
>> 
>> Aaaargh!! Did I say that? No, no, no! I said "replaced", not
>> abandoned.
>
> I don't argue against using Unix, and not against configuring
> Unix work environments either. The whole thread is about the 
> consequences of some longstanding Unix design choices which
> then established what can know be termed the Unix design.
> Text substitution is still part of every successor design.

If you mean by "text substitution" evaluating arguments and passing
them to procedures / tools, then you're right: THis is something I
don't want to miss. If you really mean text substitution, neither the
scheme shell nor i.e. iphyton are based on text substitution. They are
based on proper programming languages with properly delimited strings
and functions.

>
> I really do know how to melt and loosen Unix design choices
> and replace these choices with things I need today, on my machine.

Good ...

>   *BUT*:


> (1) Textual substitution as in the original Unix design keeps
> having consequences today, with or without new shells, with or
> without pattern expansion. This is just a fact of life with Unix,
> by design.

I admit that, but I find your use of "Unix" still problematic
here. First, the kernel itself doesn't know ynthiong about text
substitution. Second, text substitution is something implemented in a
lot of Unix tools (cpp, m4, sed, awk) and it is often exactly what one
needs to process text.

The feature has ben misused in the past, but that is not restricted to
Unix: We find wild pattern matching on input (insterad of proper
parsing) and "template expansion" (an euphemism for text substitution
:-)) all over the place. XML is also based on text -- with all the
consequences this has.

> (2) Omissible text has consequences today, by design.

I don't quite grok what you mean by "ommissible" here. If you mean
that quoting is not obligatory -- yes, that is the hallmark of many
interactive command languages, a number of them not grown on Unix at
all. It's the spirit of the 70s ... ;-).

And BTW: I'm not sure they were wrong.

I wouldn't want to use Ada as an interactive command language. There
are, I think, ways to get (1) type safety, (2) proper quoting without
too much overhead. I, personally, would built a new generation shell
system on, ahem, OCaml, because of the type interference and because
functional composition might take the part pipes have played in the
past. Something like

  dir "/etc/fstab" | dir_purge (fun f -> newer_than (2006,08,11) f.date ) | flatten | print dir_entry_long

should be possible.

> These are the design choices in question, see the prior postings
> to this thread.

> Suggesting replacement parts for pieces of Unix really means
> suggesting to change its design. 

No. I do think you use the word design in rather too broad a
sense. Else we could never change ynthing without "changing the
design".

One must perhaps live with the notion that no OS is just amonolithic
complex of design choices. It is not simply a "design change" if I
(user) change to another shell (that is designed to be user
replacable, BTW). The syscall API doesn't change. The compilers don't
change. The configuration system doesn't change. The libraries don't
change.

Of course you can lump all in one and ignore that a system like Unix
is built up of layers. But then I think you're missing something. At
least the chance to understand Unix better and learn to live with it.

The decision to have text substitution in the default shell, doesn't
permeate Unix. Most of the parts of Unix a blissfully ignorant of that
and that is good as it is, since that means we can have an embedded
Unix with e.g. busybox as shell, which does not do all the fancy stuff
bash does -- and we can still install/use/integrate basically the saem
tool set.

So no -- e.g. text subtitution is no "Unix design choice".


> It isn't turned into Windows NT
> by these changes, but someone coming from Unix will have to
> learn how to use the new parts.

Well, that is the nice thing with Unix: Many of those "you have to
learn to use a new thingy" are quite optional. Shells are per user
configurable. The use of specific programming languages can be decided
per project and so on. You never need. You can.


> You keep listing perfect examples of how to improve on the Unix design,
> by replacing parts of the design (e.g. different shells, hence
> differently designed shells), new features, or by suggesting
> to configure environments should it be necessary to overcome
> default settings as per design. Fine. So the original design
> has its flaws. 

Of course if I didn't want to use Bliss at VMS, I always had the
choice to use Pascal. Does that indicate a "design flaw" in VMS (they
never should have had Bliss at all)?

Hardly.

> (BTW, it is part of the design of
> Unix that I *can* do these things. There is very little one
> can comfortably do in this regard using cmd.exe without
> extensions.)

Exactly. So you continue to brand chances as proofs of flaws. Bad, in
my opinion. If you don't like the shell, use another. If you don't
like a programming language (shell, C), use another (Python, Ada,
...). Thousands of programmers never had problems with old shell or
the existing languages. That you have a problem with them doesn't make
them (a) design choices or (b) bad design choices. They weren't wrong
to be there in the beginning (in the 70s there WAS no alterntive
design nor a resonably priced machine that could carry it), that they
are still here today is also no design flaw (but compatibility, pure
and simple). BTW, I not, we're back to one of the old C vs. Ada
themes: Why don't people _change_ to other languages etc. -- Well, as
I have already alborated often enough, there are reasons.

That bourne shell (and C) are still there doesn't make them bad design
choices for the very reason that _you_ as user and developer have the
choice not to use them, but still use Unix.


> By analogy, if we were talking about why they chose to make "tagged"

No analogies please. They are like a green potato thrown after a
running dog and don't scratch the mustard. "Hngh?" you say? You see,
exactly that: Analogies are pretty bad to discuss somethingm because
they are often difficult to understand, their validity is limited and
needs to be subject of another discussion (as if we hadn't enough of
that already).

> a keyword during the Ada 9X process and not make every type implicitly
> tagged, we are talking about the Ada design (choices). For the notion
> of Ada design, it doesn't matter that there can be Ada-like languages
> that have implicit tags for every type. And it doesn't matter that I
> can use Ada without Ada.Text_IO, or without tagged types; both are part
> of the Ada design, no matter what. And this has consequences and
> I have to know them, for good or bad.

Well, see. Again you're using a programming language as an analogy for
an operating system. Instead of talking about first principles to
built OSses and how to best structure user interaction with the OS. 

That does bring us nowhere. 

> Both Unix and Ada are entire things. (See e.g. Kernighan/Pike 1984).

?? entire things ??

> You don't have to use either Unix or Ada in their entirety; you can
> replace some parts, which is good.


> If you used an encoding aware string type in place of Standard.STRING
> etc, your program might be better, but you don't change the Ada
> design choice for String types. You only avoid the consequences of the
> original design. So the original design has consequences. Some
> parts of the original design are just irreplaceable.

More (bad) analogies ... :-(

> By turning off shell expansion, no one can change the Unix design
> which offers shell expansion. 

Aaah, I understand: Its bad to offer functionality, even to those
users that want it?

> (I doubt it is really used as just an
> option in typical Unix use, but rather taken for granted.)

> In particular, some parts of Unix design are just hard wired, as
> you have demonstrated a number of times by informing us about your
> knowledge of the many wires (mechanisms).

My bad. I shouldn't have given the impression to know anything about
Unix (soft wired knowledge).

So if I know about something well enough it must be _hard_ wired? Get
real, Georg.

If you want to know how much functionality in Unix is really hard
wired, I suggest you study some of the development and porting history
of Bell Unix. There hardly seems anything that was no expendable at
one time or other (from users to full fork/exec).

>> Thanks for sharing that story with us. The conclusion for a more
>> general view on Unix is ... -- Please complete the following sentence:
>> 
>>   Georg B spents almost half the day preparing a cron Job. From that
>>   we must conlude that Unix __________.

> I'll appreciate your view, although I trust no one will hurry to infer
> Unix design properties from my having fun when working with Unix.

It is good that you see that. So we're actually back to square 1: (a)
A number of anectodes "things I found surprising when working with
Unix" (or should that be "thing I pretend to have found surprising",
since you always insist that you know very well how all that works,
only you think that other <whatever>) and (b) a number of assertions
that Unix is badly designed in some (IMHO minor) points that are not
connected to (a).

The problem as I see it, is basically, that we're discussing straw
man: Since you insist you can work with it and it is not really your
problem, we can only talk about problems of others. Or about problems
of the industry in general. That would require either something more
than narratives about your experiences (you don't have a problem,
rembember) or trying to establish sonme first principles on operating
system design and then relate the Unix design to that (I don't think
we'll be able to lead that discussion).

>> Thanks.
>
>
>
>>  What does that tell us?
>
> [REXX, scsh, etc.] It tells about alternative designs. About a way

REXX ahs never talked to me. As far as "seeing" things goes, I can
agree that REXX, C, Python, Ocaml, Bourne shell and Perl programs are
all different. Their beauty or ugliness and their relative merits
though all lie in the eye of the beholder. Since the programs don't
talk to me, a bit more reasoning would be required to establish some
conclusions here.

> to compare design choices by their consequences. About what can be
> done when it comes to successor designs.

Since I'm not able to deduce the existence of chocolade pudding and
income tax from "cogito ergo sum", abit help would be required to
point all those conclusion out to me. But before you do that, perhaps
it would be useful to formulate a hypothesis / lemme that relates to
out Unix discussion and woul actually change the course of our
argument and only after we have indeed established that, try to
somehow corroborate that hypothesis / argument with conlusion drawn
from the evolution of REXX. I doubt that is possible, except in very
general and useless sense, since REXX is a language, Unix an OS and
you'd probably also say something about the validity of transfering
conlusion from one domain to the other.

>
>> But I'm certain, I'm missing some finely spun argument here
>
> Yes. I think you are missing the argument of this thread. That the
> parts that make up Unix, with Bourne shell and C shell and expansions,
> could have been designed differently in the past WRT how to
> use textual substitution and WRT the amount of omissible text.

Good. Should haves are indeed not my bailiwick. How to change things
to the better are more in my direction.

Rant on against the shell, if you like. The shell (I say it again) is
not Unix, a formulation youd use again and again.

> Much like "creat" (without the final letter 'e') could have been
> named differently, as told by its creator.

Still, creat is not in my shell manual. The topic is still shell
related isn't it?

> Or should I accept that the Unix design was flawless in the
> first place, 

Admitting that Unix certainly has flaws is quite different from
admitting to your specific points. Probably "X has some flaws" is true
fro any man made X.

> and that programmers should just have learned
> to omit the final letter from the word "create"? I think this
> example is representative of some Unixisms. They are fun, but not
> to be repeated as designed.


What nonsense. You undertand the words "history artefacts". Is DUA0
named DUA0 because it is perfectly understandable or for some deep
design choice or because of historic development?

>>  Again we're back to wether a
>> user/programmer can be bother to learn his tools.
>
> We are back to whether a design choice makes using a system
> more or less work. Whether it has more pitfalls, requires more or

Aaah! So the VMS shell is just so much less work than the Bourne
shell? I had the impression that most of the additions to the shell in
V7 had the purpose to save work (also to the tool writers).

> less configuration, more or less training to achieve the same
> level of productivity, etc..

I'm sure you can prove that Unix fails miserably in all that? Esp. if
compared to better or newer operating systems? But let's not start
that discussion again.

If you just want to _state_ how much more complicated _you_ find the
Unix shell and working with Unix (than ...?), we can just leave it at
that. It's hard to contradict testimonies of personal experiences that
properly start with "I". It's only conclusions we can dispute.

> (BTW, are you saying that the expression argv[1] is not used when
> reading arguments from the command line?)

Yes it is used. But I do not understand the drift of your
argument. Using argv[1] does not expand the argument, does not relate
to quoting or the shell. It's outside of the scope of the world view
tools have: They get arguments and they process them. Some of them
even expand them (mcopy, e.g. or find) others use them as they find
them. That is, indeed, exactly as it is in VMS (we've been refereing
to VMS a number of times as a counter example). But in the sentence
"the tool reads the expanded arguments and they do it wrong" there is
either a hidden actor somewhere inplied (the shell) and that means
"they do it wrong" can't mean the tools, but should refer to the shell
OR the expanded is somwhat out of place: "the tools read the
arguments. Fullstop".

But you snipped that part of my last post, so maybe I'm relating you
question to the wrong subtopic.

Summary: Yes, argv[n] (0<=n<=argc) is used to retrieve the command line
words. But how is that related to the discussion on the Unix shell?

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

rdeininger@mindspringdot.com (Robert Deininger) writes:

> In article <11wk29zr0.fsf@hod.lan.m-e-leypold.de>, Markus E Leypold
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote:
>
> ...
>
>>As far as the shell syntax is concerned:  
>>
> ...
>>
>>  - I do think the VMS shell has the same problem with the difference between 
>>
>>      foo yadda*.* 
>>   
>>    and
>>  
>>      foo yadda *.*
>
> Out of curiosity, what is the problem here in VMS?
>
> The first example passes 1 parameter (yadda*.*) to the command foo.  If

> The second example passes 2 parameters (yadda and *.*) to command foo.  If

To me, none. It was the role of space as argument separator some
people have been complaining about, see the post before my reply.

> If this behavior isn't reasonable, what behavior would be? 

Ask me. I should have set "problem" in quotes.

> Auto-correcting of typos, with a mind-reading option?

Hey, wasn't me who styled that as a problem ...

>>Yes, but the brokenness of the auto configuration philosophy has
>>nothing to do with Unix design choices. It is actually a problem VMS
>>wouldn't have, since it doesn't exist in different sizes on vastly
>>different platforms. 
>
> VMS certainly does exist in different sizes on different platforms.  But
> the OS does a good job of hiding most of the underlying platform from
> applications, so they don't need to care.

There is only so much you can hide if the underlying platform is
really different. Emulating a 32bit enviroment on a 16bit plattform
would be tedious, restricting a 32bit platform to a 16bit "portable"
API dito.

> Auto-configuration style hacks are rarely used in native VMS
> applications.  Usually, the information the hack is trying to figure out
> can be obtained more directly.
>
> Importing autoconfiguration hacks to VMS can be a nightmare.

:-)

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On Fri, 09 Mar 2007 18:11:59 +0100, Markus E Leypold wrote:

> I wouldn't want to use Ada as an interactive command language.

Why not? I never could understand why anybody would need phyton to
configure Ada projects...

But "interactive command language" is nonsense in these days. There exist
far better ways of interaction with human beings than command languages.
They are a legacy of teleprinters.

> There
> are, I think, ways to get (1) type safety, (2) proper quoting without
> too much overhead. I, personally, would built a new generation shell
> system on, ahem, OCaml, because of the type interference and because
> functional composition might take the part pipes have played in the
> past. Something like
> 
>   dir "/etc/fstab" | dir_purge (fun f -> newer_than (2006,08,11) f.date ) | flatten | print dir_entry_long

Huh, but the above looks quite untyped. A properly typed object named
"fstab" would not need special "dir" to enumerate its members. Even less it
would need pipes to communicate its members to procedures. It already has
these members in it. And why do you construct a new set before printing, if
you have closures? The same old flawed UNIX ideology? (:-))

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

Re: Ada.Command_Line and wildcards

[Larry Kilgallen]

In article <jz1wjypcck.fsf@hod.lan.m-e-leypold.de>, Markus E Leypold writes:
> 
> rdeininger@mindspringdot.com (Robert Deininger) writes:
> 
>> In article <11wk29zr0.fsf@hod.lan.m-e-leypold.de>, Markus E Leypold
>> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote:

>>>  - I do think the VMS shell has the same problem with the difference between 
>>>
>>>      foo yadda*.* 
>>>   
>>>    and
>>>  
>>>      foo yadda *.*
>>
>> Out of curiosity, what is the problem here in VMS?
>>
>> The first example passes 1 parameter (yadda*.*) to the command foo.  If
> 
>> The second example passes 2 parameters (yadda and *.*) to command foo.  If
> 
> To me, none. It was the role of space as argument separator some
> people have been complaining about, see the post before my reply.

What constitutes an argument separator depends on the definition of the
command language being used.  VMS defines unquoted spaces in DCL commands
as separating arguments.

If one is bound and determined to create a program that flies in the
face of what users are expecting on VMS, the Foreign Command mechanism
can be used.

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

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

> On Fri, 09 Mar 2007 18:11:59 +0100, Markus E Leypold wrote:
>
>> I wouldn't want to use Ada as an interactive command language.
>
> Why not? I never could understand why anybody would need phyton to
> configure Ada projects...
>
> But "interactive command language" is nonsense in these days. There exist
> far better ways of interaction with human beings than command languages.
> They are a legacy of teleprinters.

<beeep>

Sorry, you just lost most of you points. What was the last time one of
those "better methods" enabled me to 

>
>> There
>> are, I think, ways to get (1) type safety, (2) proper quoting without
>> too much overhead. I, personally, would built a new generation shell
>> system on, ahem, OCaml, because of the type interference and because
>> functional composition might take the part pipes have played in the
>> past. Something like
>> 
>>   dir "/etc/fstab" | dir_purge (fun f -> newer_than (2006,08,11) f.date ) | flatten | print dir_entry_long
>
> Huh, but the above looks quite untyped. 


> A properly typed object named
> "fstab" would not need special "dir" to enumerate its members. 

I wanted to write "/etc", but you know, the difference is between a
_name_ and the object bound under that name. I somehow abhor the idea
of filesystems which are completely statically bound.


> Even less it would need pipes to communicate its members to
> procedures.

Tcha. You missed the definition of (|) in this case. It's basically
the function composition operator, not a pipe.

>>   dir "/etc/fstab" | dir_purge (fun f -> newer_than (2006,08,11) f.date ) 

is 

>>   dir_purge (fun f -> newer_than (2006,08,11) f.date ) (dir "/etc/fstab" )

but easier to read for people thinking in sequences of transformations.

> It already has
> these members in it. And why do you construct a new set before printing, if
> you have closures? 

What have closure to do with printing?

And BTW, that was a mockup. There are perhaps even ways to eliminate
"print" in the toplevel, not only flatten. Flatten, BTW is sometimes
needed (because of the type system) to convert trees onto
lists. Wether I really need it in this case I haven't completely
figured out yet.

> The same old flawed UNIX ideology? (:-))

Oh, forgive me. Next time I ask you. Not.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On Fri, 09 Mar 2007 20:02:21 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> A properly typed object named
>> "fstab" would not need special "dir" to enumerate its members. 
> 
> I wanted to write "/etc", but you know, the difference is between a
> _name_ and the object bound under that name. I somehow abhor the idea
> of filesystems which are completely statically bound.

?

The object root contains object "etc" which contains "fstab". It is not
statically bound. You index a collection with a string.

But wait,  of course you would not need "filesystems" in a typed system of
persistent objects...

 >>>   dir "/etc/fstab" | dir_purge (fun f -> newer_than (2006,08,11) f.date ) 
> 
> is 
> 
>>>   dir_purge (fun f -> newer_than (2006,08,11) f.date ) (dir "/etc/fstab" )
> 
> but easier to read for people thinking in sequences of transformations.

I doubt it, especially because in most cases it is not a sequence but a
DAG. In others it is a general case directed graph. I could also imagine
purely relational interfaces to collections of persistent objects. And,
there is something cranky in transformations of collections of persistent
[=having identity] things.

>> It already has
>> these members in it. And why do you construct a new set before printing, if
>> you have closures? 
> 
> What have closure to do with printing?

You could do: if f.date >  2006.08.11 then f.print; end if;

> And BTW, that was a mockup. There are perhaps even ways to eliminate
> "print" in the toplevel, not only flatten. Flatten, BTW is sometimes
> needed (because of the type system) to convert trees onto
> lists. Wether I really need it in this case I haven't completely
> figured out yet.

You don't need to convert anything. Provide "ordered set" interface along
with "DAG" interface. Or equivalently use path iterators instead of
strings. Because it is supposed to be typed, the compiler will figure out
what view is relevant in which case, or else complain about overloading
ambiguity.

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

Re: Ada.Command_Line and wildcards

[Randy Brukardt]

"Markus E Leypold"
<development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in
message news:8g649apcio.fsf@hod.lan.m-e-leypold.de...
...
> I wouldn't want to use Ada as an interactive command language.

Well, I would. Down with all non-Ada syntaxes!! ;-)

Seriously, we did in fact design an Ada command language for our debugger.
It works quite well. (I think others have done similar things.) Of course,
it's neither full Ada and it allows leaving out "noise" characters. And I
believe we required one statement per line (that allows a lot more
abbreviations). You can type:

   Step_Line (Count => 20);

or

   sl 20
(abbreviated command name; unneeded parens and semicolon omitted)
Of course, if something is ambiguous, you have to use a longer form.

We originally did this because we wanted the macro language for the debugger
to be as close to Ada as possible - that makes the macros readable and
maintanable. Usually, you use shorter forms from the command line (typing
too much is awful).

                            Randy.

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> What constitutes an argument separator depends on the definition of the
> command language being used.  

Surprise! Well - actually that has been my stance all the time. Don't
lead THAT discussion with me.

> VMS defines unquoted spaces in DCL commands
> as separating arguments.

That definition has been pointed out as a severe "design flaw of
Unix". Since in the same discussion/thread the VMS shell system has
been put forward as an example how command line arguments are handled
"right", I thought I'd point out that space argument seperator is also
common in VMS (and a number of other operating systems I know of). 

Calling that a design flaw might be justified (but I wouldn't support
it), calling it a design flaw of Unix, not.

But as I said: It wasn't me who said space as argument seperator were
a problem. I, certainly, am not of this opinion.

> If one is bound and determined to create a program that flies in the
> face of what users are expecting on VMS, the Foreign Command mechanism
> can be used.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

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

> On Fri, 09 Mar 2007 20:02:21 +0100, Markus E Leypold wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> A properly typed object named
>>> "fstab" would not need special "dir" to enumerate its members. 
>> 
>> I wanted to write "/etc", but you know, the difference is between a
>> _name_ and the object bound under that name. I somehow abhor the idea
>> of filesystems which are completely statically bound.
>
> ?
>
> The object root contains object "etc" which contains "fstab". It is not
> statically bound. You index a collection with a string.

"/etc" is a string, not an object. 

And I personally wouldn't want to write 

 (fs_root.get_member "etc").get_member "fstab"

> But wait,  of course you would not need "filesystems" in a typed system of
> persistent objects...

It's my design and I'd like to keep the FS. Actually I'd want a shell
not a completely different computing paradigm.


>  >>>   dir "/etc/fstab" | dir_purge (fun f -> newer_than (2006,08,11) f.date ) 
>> 
>> is 
>> 
>>>>   dir_purge (fun f -> newer_than (2006,08,11) f.date ) (dir "/etc/fstab" )
>> 
>> but easier to read for people thinking in sequences of transformations.
>
> I doubt it, especially because in most cases it is not a sequence but a
> DAG. 

You know, one of the points in designing an interactive command
language is, to provide syntactic sugar for the most common cases. The
DAG isn't forbidden by providing alternate syntax.


> In others it is a general case directed graph. I could also imagine
> purely relational interfaces to collections of persistent objects. And,
> there is something cranky in transformations of collections of persistent
> [=having identity] things.

I didn't talk about objects. I talked about a basically functional
shell. A list (e.g.) is not an object, it's just data to me. Since
you're on a war footing with anything functional anyway, you might not
like that approach.

>
>>> It already has
>>> these members in it. And why do you construct a new set before printing, if
>>> you have closures? 
>> 
>> What have closure to do with printing?
>
> You could do: if f.date >  2006.08.11 then f.print; end if;

And that is supposed to be a closure? Or is that example incomplete?


>> And BTW, that was a mockup. There are perhaps even ways to eliminate
>> "print" in the toplevel, not only flatten. Flatten, BTW is sometimes
>> needed (because of the type system) to convert trees onto
>> lists. Wether I really need it in this case I haven't completely
>> figured out yet.


> You don't need to convert anything. 

Well, I should know better.

> Provide "ordered set" interface along
> with "DAG" interface. 

Thanks for teaching me how to program. But we're talking about
_functional programming_ here, not OO.

> Or equivalently use path iterators instead of
> strings. 

There are no iterators in functional data. We have folds and maps and
I hide them in the pipe-syntax because the idea was exactly to write
down transformation steps.

> Because it is supposed to be typed, the compiler will figure out
> what view is relevant in which case, or else complain about overloading
> ambiguity.

Overloading? There is no overloading, both with type inference (and
types we want, don't we?).

You completely missed most of central points of the whole idea (and
you didn't even ask), but since you're not interested in it except to
find you own concept in it, we can just stop discussing it.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

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

> "Markus E Leypold"
> <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> wrote in
> message news:8g649apcio.fsf@hod.lan.m-e-leypold.de...
> ...
>> I wouldn't want to use Ada as an interactive command language.
>
> Well, I would. Down with all non-Ada syntaxes!! ;-)

I admit I was rather interested in Tash also, for some time, but
actually more as a scripting tool.

>
> Seriously, we did in fact design an Ada command language for our debugger.
> It works quite well. (I think others have done similar things.) Of course,
> it's neither full Ada and it allows leaving out "noise" characters. And I
> believe we required one statement per line (that allows a lot more
> abbreviations). You can type:
>
>    Step_Line (Count => 20);
>
> or
>
>    sl 20
> (abbreviated command name; unneeded parens and semicolon omitted)
> Of course, if something is ambiguous, you have to use a longer form.

I think that might work with a debugger. For a shell I'd like to have
a "powerful" mechanism to combine / chain / compose operations and I
think that will become a nuisance with Ada syntax, especially when one
tries to build the shell expression incrementally.

> We originally did this because we wanted the macro language for the debugger
> to be as close to Ada as possible - that makes the macros readable and
> maintanable. Usually, you use shorter forms from the command line (typing
> too much is awful).

I think your design makes a lot of sense. But I'm certain you don't
require the user to declare all variables at the interactive prompt or
want them to open a new declare/begin block when introducing a new
variable. I often use

 > T="$( some_command ... )"

 > echo $T # convince myself that I have all data I want

 > for i in $T; do ... done  # do something

 > SUF=".txt"

 > for i in $T; do ... done  # do something else with $SUF


With strict Ada this style would becomes (IMHO) quickly tedious.

A certain amount of sloppiness in the interactive shell, that is my
point, of furthers usability.

A just "pascalish/adaish" syntax of course is not a problem and indeed
I'm preaching exactly that when I suggest to use a only slightly
modified OCaml toplevel as a shell: Strings are properly quotes, one
has functions and nesting parenthesis etc. It is well typed. And the
major feature in my eyes is would be type inference (as with the
"normal" shells one wouldn't have to provide type information). 

This is still mostly SF though.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Georg Bauhaus]

Markus E Leypold wrote:
>
 I find your use of "Unix" still problematic
> here.

I thought it is quite common to think of Unix as kernel,
hierarchical filing system, pipes, utilities, shell glue,
compilers, job control, text processing, ... and then
speak of the whole collection as Unix.


>> (2) Omissible text has consequences today, by design.
> 
> I don't quite grok what you mean by "ommissible" here. 

Arguments may be omitted, quotes may be omitted, basically
anything can be omitted whose description includes a phrase
that starts, "if there is no x, then y will ...". See below.


>> In particular, some parts of Unix design are just hard wired, as
>> you have demonstrated a number of times by informing us about your
>> knowledge of the many wires (mechanisms).

This was written in a mood. Read, "when explaining the many
wires (mechanisms)."

> 
> My bad. I shouldn't have given the impression to know anything about
> Unix (soft wired knowledge).
> 
> So if I know about something well enough it must be _hard_ wired? Get
> real, Georg.

Let me concentrate on a few things hard wired into Unix(TM).
Let me exclude descriptions of operating environments that
are based on parts of Unix and on other things, because
these operating environments cannot illustrate Unix
design decisions where Unix, as above, refers to what
you would have got buying Unix. (I think that few have
a problem with the inclusive notion of Unix when speaking
about the design of the OS made then?)

So, leaving out options handling for the moment, in Unix I
expect the system programs, most relevant to any shell work,
to have certain behavior, by design.

- echo prints its arguments.
- ls stats its arguments.
- Default shells may expand file name patterns.
  When they do, and there is no match, the pattern expansion
  (re-)produces the pattern.
- echo without arguments will likely print an empty line
- ls without arguments will list the files in the current directory.
- When pattern expansion (re-)produces a pattern,
  echo will print the pattern and succeed,
  ls will stat the pattern and fail.

That is, with the above choices, you can run programs, omit
arguments, and get implicit default behavior. This is by design.
Learning the defaults, settings, and implications will be the
protective measure against some surprises.

Here is another set of choices. They stubbornly disallow
no-argument calls, doing exactly what Unix rm(1) does,
in this regard.

- echo prints arguments
- ls stats arguments
- Default shells have no notion of file name pattern expansion.
- fnexpand(1) expands file name patterns. When there is no
  match, it produces nothing. Otherwise it prints all matching
  filenames, properly quoted.
- echo without arguments will fail
- ls without arguments will fail

So we might have:

$ echo $(fnexpand "*.ads")
echo: no arguments
$ ls $(fnexpand "*.ads")
ls: no filenames
$


Either set of choices has consequences. One consequence is that
one source of surprises is excluded by the second set, by design:

 If there is no argument, a program will fail.

This is opposed to what we now have in Unix as designed:

 If there is no argument, whether or not the program
 will fail depends on the program

Therefore, the second set of choices suggest that there might have
been a different Unix design, one that permits writing shell programs
and commands that would have offered simpler, more regular, easy to
predict behavior at the cost of slightly more typing.

(I know it is certainly possible to construct functions and
programs to work like that using Unix as is. But the result
will differ from Unix design.)


[creat]

> What nonsense. You undertand the words "history artefacts".

Yes. Unix artefacts is what we are talking about. Their cons and
their pros. (I must once again stress that of course there are pros,
not because I think there are pros, but because e.g. Unix shells can
be compared to the OS-control solutions that are/were offered by
the competition. The solutions can be compared by considering
use cases, and by considering technical properties.)

Re: Ada.Command_Line and wildcards

[Jacob Sparre Andersen]

Markus E Leypold wrote:

> I admit that, but I find your use of "Unix" still problematic
> here. First, the kernel itself doesn't know ynthiong about text
> substitution. Second, text substitution is something implemented in
> a lot of Unix tools (cpp, m4, sed, awk) and it is often exactly what
> one needs to process text.

But C, the system call interface and sh(1) are all a part of the Unix
design and system. - Even if a part of the design is that some parts
of it can be changed.

We shouldn't ignore this.  And in a historical context, this design is
probably rather good.  We should rather look at how we can use our
experience with the system (and what we've built on top of it) to
create an even better one.

> I wouldn't want to use Ada as an interactive command language. There
> are, I think, ways to get (1) type safety, (2) proper quoting
> without too much overhead. I, personally, would built a new
> generation shell system on, ahem, OCaml, because of the type
> interference and because functional composition might take the part
> pipes have played in the past.

I'm not sure I would use OCaml as the basis.  To me it seems too big
and complicated for the purpose.  But the shell (interactive command
language) should support all the different kinds of interprocess
communication that the underlying kernel supports.  That doesn't quite
seem to be the case with sh(1).

>> Suggesting replacement parts for pieces of Unix really means
>> suggesting to change its design.
>
> No. I do think you use the word design in rather too broad a
> sense. Else we could never change ynthing without "changing the
> design".
>
> One must perhaps live with the notion that no OS is just amonolithic
> complex of design choices. It is not simply a "design change" if I
> (user) change to another shell (that is designed to be user
> replacable, BTW).

Since sh(1) is a requirement in the POSIX standard, it is a change in
the design to substitute sh(1) with something else (although it is a
change the remaining system is designed to allow).  Adding yet another
user selectable shell to the system is on the other hand not something
I consider a change in the design.

Greetings,

Jacob
-- 
"The universe isn't for the likes of me to understand. I only work here."

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

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

> Markus E Leypold wrote:

>> I wouldn't want to use Ada as an interactive command language. There
>> are, I think, ways to get (1) type safety, (2) proper quoting
>> without too much overhead. I, personally, would built a new
>> generation shell system on, ahem, OCaml, because of the type
>> interference and because functional composition might take the part
>> pipes have played in the past.
>
> I'm not sure I would use OCaml as the basis.  

Well, I think I will. For me it's more a hacking project (that is, get
something better / different for as cheap as possible: After all I
don't want to spent years with that), so I'll have to built on an
existing language. Some other constraints which are not derived from
"cogito ergo sum" but just express my desires are:

 - functional
 - strong static type system
 - possible to create C bindings
 - dynamic loading of byte code should be possible.
  
> To me it seems too big and complicated for the purpose.

A running Ocaml toplevel requires only slightly more meory than bash
and it is faster and needs to fork less external tools.

> But the shell (interactive command language) should support all the
> different kinds of interprocess communication that the underlying
> kernel supports.

But?

> That doesn't quite seem to be the case with sh(1).

Yes, it isn't. That is the reason ksh was invented and came too late
to become standard shell on all Unices.


>>> Suggesting replacement parts for pieces of Unix really means
>>> suggesting to change its design.
>>
>> No. I do think you use the word design in rather too broad a
>> sense. Else we could never change ynthing without "changing the
>> design".
>>
>> One must perhaps live with the notion that no OS is just amonolithic
>> complex of design choices. It is not simply a "design change" if I
>> (user) change to another shell (that is designed to be user
>> replacable, BTW).


> Since sh(1) is a requirement in the POSIX standard, it is a change in
> the design to substitute sh(1) with something else (although it is a
> change the remaining system is designed to allow).  

You and George are using the word "design" rather to gratiously. More
about that another time.

> Adding yet another user selectable shell to the system is on the
> other hand not something I consider a change in the design.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> But "interactive command language" is nonsense in these days. There exist
> far better ways of interaction with human beings than command languages.
> They are a legacy of teleprinters.

Really? Name one.

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On Sun, 11 Mar 2007 00:15:06 GMT, Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
>> But "interactive command language" is nonsense in these days. There exist
>> far better ways of interaction with human beings than command languages.
>> They are a legacy of teleprinters.
> 
> Really? Name one.

GUI

(what about driving cars using an interactive command language? Interaction
assumes duplex communication, notion of time and state. People are not so
good in simultaneous typing, reading, understanding, predicting.)

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

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

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

> On Sun, 11 Mar 2007 00:15:06 GMT, Hyman Rosen wrote:
>
>> Dmitry A. Kazakov wrote:
>>> But "interactive command language" is nonsense in these days. There exist
>>> far better ways of interaction with human beings than command languages.
>>> They are a legacy of teleprinters.
>> 
>> Really? Name one.
>
> GUI

Muhahahaha. No problem: How to I specify complex collective renaming
operations in a GUI?

> (what about driving cars using an interactive command language? 

Well -- perhaps, that might be new to you, cars are less complex
(read: less powerful) than computers.

> Interaction assumes duplex communication, notion of time and
> state. People are not so good in simultaneous typing, reading,
> understanding, predicting.)

And GUI is monoplex or what? Doesn't overtax the user because it
doesn't output while he is inputting? Waits for user input and only
then talks back? (Or was that the ill reputed command line, whereas
the famous GUI is popping up out-of-context windows all the time in
the users face, trying to catch his attention focused on one task by
blinking twirling its windows and icons - I don't quite remember).

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Hyman Rosen]

On Mar 11, 3:59 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> GUI

Really? But one of the difficult situations people are describing here
occurs when a file pattern expands into too many files to fit within
the limits of the command line. Can you reasonably expect that the
typical GUI environment will be able to comfortably handle such a
situation? My experience is that it would bog down into incredibly
slow performance if given a directory with thousands of files in it.

> (what about driving cars using an interactive command language?

Driving involves continuous operation with extensive feedback, which
is quite different from a shell language, designed to perform one
operation at a time. But even when it comes to driving, consider what
an ordinary driver does when faced with parking a car in the tight
confines of a parking garage. Using the normal mechanisms, it's quite
easy to misalign the car, hit other cars, bash your mirrors, and so
forth. Using a command language to precisely guide the car might be
just the ticket!

Re: Ada.Command_Line and wildcards

[Dmitry A. Kazakov]

On 12 Mar 2007 06:32:00 -0700, Hyman Rosen wrote:

> On Mar 11, 3:59 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> GUI
> 
> Really? But one of the difficult situations people are describing here
> occurs when a file pattern expands into too many files to fit within
> the limits of the command line. Can you reasonably expect that the
> typical GUI environment will be able to comfortably handle such a
> situation?

Sure, because they were designed to prevent such situations to happen.

The very need in patterns indicates the low level of the interface. If an
action involves a massive number of files, then that does not imply that
all these files (or better to say bits) need to be specified explicitly. If
they need, then the interface is *bad*. To book a ticket you press the
button "submit order." Surely you don't specify the names of the
corresponding files... 

The true catastrophe happens when something unexpected occurs. But at this
level of complexity there is nothing you could do anyway: Denver airport,
or a file system chewed by the virus...

> My experience is that it would bog down into incredibly
> slow performance if given a directory with thousands of files in it.

That is not really my argument against command languages. It is rather
about the abstraction level of. The real arguments are IMO:

1. Half-duplex nature of communication
2. Very limited communication speed (reading and typing)
3. Inefficient use of human senses
4. The system state is invisible
5. Language training is required
6. Error prone
7. Integration and extensibility is a problem

>> (what about driving cars using an interactive command language?
> 
> Driving involves continuous operation with extensive feedback, which
> is quite different from a shell language, designed to perform one
> operation at a time. But even when it comes to driving, consider what
> an ordinary driver does when faced with parking a car in the tight
> confines of a parking garage. Using the normal mechanisms, it's quite
> easy to misalign the car, hit other cars, bash your mirrors, and so
> forth. Using a command language to precisely guide the car might be
> just the ticket!

Yes, at some level there always exists the perfect command language, with
the only command "do that damned thing!" Unfortunately, it is too ambiguous
for either people or computers to become a reality.

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

Re: Ada.Command_Line and wildcards

[Jacob Sparre Andersen]

Markus E Leypold wrote:

> A running Ocaml toplevel requires only slightly more meory than bash
> and it is faster and needs to fork less external tools.

In my view, the whole idea with a shell is that it is used to launch
(fork) external tools, so I am not convinced that it is a real
benefit.

Greetings,

Jacob
-- 
�What fun is it being "cool" if you can't wear a sombrero?�

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

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

> On 12 Mar 2007 06:32:00 -0700, Hyman Rosen wrote:
>
>> On Mar 11, 3:59 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>>> GUI
>> 
>> Really? But one of the difficult situations people are describing here
>> occurs when a file pattern expands into too many files to fit within
>> the limits of the command line. Can you reasonably expect that the
>> typical GUI environment will be able to comfortably handle such a
>> situation?
>
> Sure, because they were designed to prevent such situations to happen.

How does a GUI prevent the user to have 100000 files in a directory
("folder")? And what happens if the user opens such a directory?

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

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

> Markus E Leypold wrote:
>
>> A running Ocaml toplevel requires only slightly more meory than bash
>> and it is faster and needs to fork less external tools.
>
> In my view, the whole idea with a shell is that it is used to launch
> (fork) external tools, so I am not convinced that it is a real
> benefit.

Yes + no. The shell is an environment where "procedures" are
implemented by providing external tools / binaries and composing them
via pipe. This was the best way to handle things on s PDP/11 with
really tight memory constraints. These days it's perhaps better to
"internalize" many of the standard functions. My suggestion is, that a
"tool" actually corresponds to a function (stdin -> stdout :-) and
piping is actually function composition. Of course external tools are
a separate case now, but that can be handled by introducing a wrapper:

  do-something | run "foo" ["arg1";"arg2"] | do-something-with-output 

Running multiple external process connected by pipelines becomes less
important now and will be a seperate case.

Regards -- Markus

Re: Ada.Command_Line and wildcards

[Brian May]

>>>>> "Markus" == Markus E Leypold <Markus> writes:

    Markus> How does a GUI prevent the user to have 100000 files in a
    Markus> directory ("folder")? And what happens if the user opens
    Markus> such a directory?

If I go to the computer of a typical GUI user, I find that their
desktop is full of files. Usually this will be a mix of downloads
(recent and old), applications (depending on OS), data files (some
important, some out-of-date, and some rubbish).

GUIs do nothing to ensure users use good organisational techniques for
filing important data.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Ada.Command_Line and wildcards

[Markus E Leypold]

Brian May <bam@snoopy.apana.org.au> writes:

>>>>>> "Markus" == Markus E Leypold <Markus> writes:
>
>     Markus> How does a GUI prevent the user to have 100000 files in a
>     Markus> directory ("folder")? And what happens if the user opens
>     Markus> such a directory?
>
> If I go to the computer of a typical GUI user, I find that their
> desktop is full of files. Usually this will be a mix of downloads
> (recent and old), applications (depending on OS), data files (some
> important, some out-of-date, and some rubbish).
>
> GUIs do nothing to ensure users use good organisational techniques for
> filing important data.

Well, I really meant 100000 files. One of the standard complaints in
this thread was, how, due to the restricted length of the unix command
line (more precisely: The maximum length of argv[] passed to a process
by the operating system kernel), ls *.adb fails sometimes and how bad
that is (and how it shows that wild card expansion in a shell is a bad
idea).

Well, my question was to Dmitry, who has been suggesting a GUI as a
better, more efficient way to interact with a computer (and than has
fallen conspiciously silent).

I'm not talking about garbage files lying around. I'm talking about
the following:

If we have many files in a GUI folder, the scroll bars become unusable
for scrolling and I wonder how long I'll take to mark all files in the
folder which are of pattern *~ to clean away garbage (in example). Is
this the better way to interact? Hardly. It's easier in the beginning,
yes, but much worse in the long run. Interestingly, the point "easier
to use in the beginning" or in interactive usage was, what the enemies
of the Unix command line here didn't want to concede back than. 

But I'm perhaps wrong to identify Georg's point of view with Dmitry's
and I'm not sure I really want to know more about Dmitry's very
own. I've been failing to grasp his avantgarde perspective on
everything to do with computing before. (I really respect his work,
i.e. contributions to GtkAda, but when the discussion shifts to theory
I realize that we come from different universes, probably even with
vastly different physical laws, <note:joke> and only meet here).

Nonetheless: A short answer, wether he thinks the Windows or Mac GUI
provide a solution to manage many files in one folder or to manipulate
all backup files beneath a certain folder, would be appreciated. If
not (if they don't provide) about which GUI has he been thinking (I
don't pretend Windows' and Mac's are the only two GUIs in the world).

Regards -- Markus