* Ada.Command_Line and wildcards @ 2007-02-21 20:43 Gautier 2007-02-21 20:59 ` (see below) 2007-02-21 21:43 ` Dr. Adrian Wrigley 0 siblings, 2 replies; 158+ messages in thread From: Gautier @ 2007-02-21 20:43 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-21 20:43 Ada.Command_Line and wildcards Gautier @ 2007-02-21 20:59 ` (see below) 2007-02-22 1:13 ` Marc A. Criley ` (2 more replies) 2007-02-21 21:43 ` Dr. Adrian Wrigley 1 sibling, 3 replies; 158+ messages in thread From: (see below) @ 2007-02-21 20:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-21 20:59 ` (see below) @ 2007-02-22 1:13 ` Marc A. Criley 2007-02-22 2:08 ` Adam Beneschan 2007-02-22 8:16 ` gautier_niouzes 2 siblings, 0 replies; 158+ messages in thread From: Marc A. Criley @ 2007-02-22 1:13 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-21 20:59 ` (see below) 2007-02-22 1:13 ` Marc A. Criley @ 2007-02-22 2:08 ` Adam Beneschan 2007-02-22 5:59 ` (see below) 2007-02-22 8:16 ` gautier_niouzes 2 siblings, 1 reply; 158+ messages in thread From: Adam Beneschan @ 2007-02-22 2:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 2:08 ` Adam Beneschan @ 2007-02-22 5:59 ` (see below) 0 siblings, 0 replies; 158+ messages in thread From: (see below) @ 2007-02-22 5:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-21 20:59 ` (see below) 2007-02-22 1:13 ` Marc A. Criley 2007-02-22 2:08 ` Adam Beneschan @ 2007-02-22 8:16 ` gautier_niouzes 2007-02-22 10:25 ` Simon Wright ` (2 more replies) 2 siblings, 3 replies; 158+ messages in thread From: gautier_niouzes @ 2007-02-22 8:16 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 8:16 ` gautier_niouzes @ 2007-02-22 10:25 ` Simon Wright 2007-02-22 11:02 ` Alex R. Mosteo 2007-02-22 11:19 ` Jean-Pierre Rosen 2 siblings, 0 replies; 158+ messages in thread From: Simon Wright @ 2007-02-22 10:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 8:16 ` gautier_niouzes 2007-02-22 10:25 ` Simon Wright @ 2007-02-22 11:02 ` Alex R. Mosteo 2007-02-24 6:34 ` Martin Krischik 2007-02-22 11:19 ` Jean-Pierre Rosen 2 siblings, 1 reply; 158+ messages in thread From: Alex R. Mosteo @ 2007-02-22 11:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 11:02 ` Alex R. Mosteo @ 2007-02-24 6:34 ` Martin Krischik 2007-02-24 11:46 ` Markus E Leypold ` (2 more replies) 0 siblings, 3 replies; 158+ messages in thread From: Martin Krischik @ 2007-02-24 6:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 6:34 ` Martin Krischik @ 2007-02-24 11:46 ` Markus E Leypold 2007-02-24 14:54 ` Georg Bauhaus 2007-02-24 18:28 ` Martin Krischik 2007-02-24 13:04 ` Larry Kilgallen 2007-03-05 1:03 ` Brian May 2 siblings, 2 replies; 158+ messages in thread From: Markus E Leypold @ 2007-02-24 11:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 11:46 ` Markus E Leypold @ 2007-02-24 14:54 ` Georg Bauhaus 2007-02-24 16:45 ` Markus E Leypold 2007-03-05 1:07 ` Brian May 2007-02-24 18:28 ` Martin Krischik 1 sibling, 2 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-02-24 14:54 UTC (permalink / raw) 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 :) ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 14:54 ` Georg Bauhaus @ 2007-02-24 16:45 ` Markus E Leypold 2007-02-24 20:08 ` Jacob Sparre Andersen ` (2 more replies) 2007-03-05 1:07 ` Brian May 1 sibling, 3 replies; 158+ messages in thread From: Markus E Leypold @ 2007-02-24 16:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 16:45 ` Markus E Leypold @ 2007-02-24 20:08 ` Jacob Sparre Andersen 2007-02-24 20:45 ` Georg Bauhaus 2007-02-24 20:26 ` Georg Bauhaus 2007-02-25 7:46 ` Hyman Rosen 2 siblings, 1 reply; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-02-24 20:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 20:08 ` Jacob Sparre Andersen @ 2007-02-24 20:45 ` Georg Bauhaus 2007-02-25 0:39 ` Björn Persson 2007-02-25 16:29 ` Martin Krischik 0 siblings, 2 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-02-24 20:45 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 20:45 ` Georg Bauhaus @ 2007-02-25 0:39 ` Björn Persson 2007-02-25 16:29 ` Martin Krischik 1 sibling, 0 replies; 158+ messages in thread From: Björn Persson @ 2007-02-25 0:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 20:45 ` Georg Bauhaus 2007-02-25 0:39 ` Björn Persson @ 2007-02-25 16:29 ` Martin Krischik 1 sibling, 0 replies; 158+ messages in thread From: Martin Krischik @ 2007-02-25 16:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 16:45 ` Markus E Leypold 2007-02-24 20:08 ` Jacob Sparre Andersen @ 2007-02-24 20:26 ` Georg Bauhaus 2007-02-25 7:46 ` Hyman Rosen 2 siblings, 0 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-02-24 20:26 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 16:45 ` Markus E Leypold 2007-02-24 20:08 ` Jacob Sparre Andersen 2007-02-24 20:26 ` Georg Bauhaus @ 2007-02-25 7:46 ` Hyman Rosen 2007-02-25 13:19 ` Georg Bauhaus 2 siblings, 1 reply; 158+ messages in thread From: Hyman Rosen @ 2007-02-25 7:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-25 7:46 ` Hyman Rosen @ 2007-02-25 13:19 ` Georg Bauhaus 0 siblings, 0 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-02-25 13:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 14:54 ` Georg Bauhaus 2007-02-24 16:45 ` Markus E Leypold @ 2007-03-05 1:07 ` Brian May 2007-03-05 1:39 ` Markus E Leypold 2007-03-05 12:16 ` Georg Bauhaus 1 sibling, 2 replies; 158+ messages in thread From: Brian May @ 2007-03-05 1:07 UTC (permalink / raw) >>>>> "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> ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-05 1:07 ` Brian May @ 2007-03-05 1:39 ` Markus E Leypold 2007-03-06 3:48 ` Brian May 2007-03-05 12:16 ` Georg Bauhaus 1 sibling, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-03-05 1:39 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-05 1:39 ` Markus E Leypold @ 2007-03-06 3:48 ` Brian May 0 siblings, 0 replies; 158+ messages in thread From: Brian May @ 2007-03-06 3:48 UTC (permalink / raw) >>>>> "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> ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-05 1:07 ` Brian May 2007-03-05 1:39 ` Markus E Leypold @ 2007-03-05 12:16 ` Georg Bauhaus 2007-03-05 13:20 ` Markus E Leypold 2007-03-06 3:07 ` Brian May 1 sibling, 2 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-03-05 12:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-05 12:16 ` Georg Bauhaus @ 2007-03-05 13:20 ` Markus E Leypold 2007-03-06 12:56 ` Georg Bauhaus 2007-03-06 3:07 ` Brian May 1 sibling, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-03-05 13:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-05 13:20 ` Markus E Leypold @ 2007-03-06 12:56 ` Georg Bauhaus 2007-03-06 15:07 ` Markus E Leypold ` (2 more replies) 0 siblings, 3 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-03-06 12:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-06 12:56 ` Georg Bauhaus @ 2007-03-06 15:07 ` Markus E Leypold 2007-03-07 22:06 ` Georg Bauhaus 2007-03-09 13:41 ` Robert Deininger 2007-03-06 15:08 ` Jacob Sparre Andersen 2007-03-07 19:21 ` Hyman Rosen 2 siblings, 2 replies; 158+ messages in thread From: Markus E Leypold @ 2007-03-06 15:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-06 15:07 ` Markus E Leypold @ 2007-03-07 22:06 ` Georg Bauhaus 2007-03-08 5:07 ` Simon Wright 2007-03-08 9:16 ` Markus E Leypold 2007-03-09 13:41 ` Robert Deininger 1 sibling, 2 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-03-07 22:06 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-07 22:06 ` Georg Bauhaus @ 2007-03-08 5:07 ` Simon Wright 2007-03-08 9:19 ` Markus E Leypold 2007-03-08 9:28 ` Georg Bauhaus 2007-03-08 9:16 ` Markus E Leypold 1 sibling, 2 replies; 158+ messages in thread From: Simon Wright @ 2007-03-08 5:07 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-08 5:07 ` Simon Wright @ 2007-03-08 9:19 ` Markus E Leypold 2007-03-08 9:28 ` Georg Bauhaus 1 sibling, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-03-08 9:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-08 5:07 ` Simon Wright 2007-03-08 9:19 ` Markus E Leypold @ 2007-03-08 9:28 ` Georg Bauhaus 1 sibling, 0 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-03-08 9:28 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-07 22:06 ` Georg Bauhaus 2007-03-08 5:07 ` Simon Wright @ 2007-03-08 9:16 ` Markus E Leypold 2007-03-09 13:33 ` Georg Bauhaus 1 sibling, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-03-08 9:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-08 9:16 ` Markus E Leypold @ 2007-03-09 13:33 ` Georg Bauhaus 2007-03-09 17:11 ` Markus E Leypold 0 siblings, 1 reply; 158+ messages in thread From: Georg Bauhaus @ 2007-03-09 13:33 UTC (permalink / raw) 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?) ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 13:33 ` Georg Bauhaus @ 2007-03-09 17:11 ` Markus E Leypold 2007-03-09 18:22 ` Dmitry A. Kazakov ` (3 more replies) 0 siblings, 4 replies; 158+ messages in thread From: Markus E Leypold @ 2007-03-09 17:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 17:11 ` Markus E Leypold @ 2007-03-09 18:22 ` Dmitry A. Kazakov 2007-03-09 19:02 ` Markus E Leypold 2007-03-11 0:15 ` Hyman Rosen 2007-03-10 2:12 ` Randy Brukardt ` (2 subsequent siblings) 3 siblings, 2 replies; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-03-09 18:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 18:22 ` Dmitry A. Kazakov @ 2007-03-09 19:02 ` Markus E Leypold 2007-03-09 20:04 ` Dmitry A. Kazakov 2007-03-11 0:15 ` Hyman Rosen 1 sibling, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-03-09 19:02 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 19:02 ` Markus E Leypold @ 2007-03-09 20:04 ` Dmitry A. Kazakov 2007-03-10 10:40 ` Markus E Leypold 0 siblings, 1 reply; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-03-09 20:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 20:04 ` Dmitry A. Kazakov @ 2007-03-10 10:40 ` Markus E Leypold 0 siblings, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-03-10 10:40 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 18:22 ` Dmitry A. Kazakov 2007-03-09 19:02 ` Markus E Leypold @ 2007-03-11 0:15 ` Hyman Rosen 2007-03-11 7:59 ` Dmitry A. Kazakov 1 sibling, 1 reply; 158+ messages in thread From: Hyman Rosen @ 2007-03-11 0:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-11 0:15 ` Hyman Rosen @ 2007-03-11 7:59 ` Dmitry A. Kazakov 2007-03-11 14:55 ` Markus E Leypold 2007-03-12 13:32 ` Hyman Rosen 0 siblings, 2 replies; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-03-11 7:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-11 7:59 ` Dmitry A. Kazakov @ 2007-03-11 14:55 ` Markus E Leypold 2007-03-12 13:32 ` Hyman Rosen 1 sibling, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-03-11 14:55 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-11 7:59 ` Dmitry A. Kazakov 2007-03-11 14:55 ` Markus E Leypold @ 2007-03-12 13:32 ` Hyman Rosen 2007-03-12 14:14 ` Dmitry A. Kazakov 1 sibling, 1 reply; 158+ messages in thread From: Hyman Rosen @ 2007-03-12 13:32 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-12 13:32 ` Hyman Rosen @ 2007-03-12 14:14 ` Dmitry A. Kazakov 2007-03-12 15:08 ` Markus E Leypold 0 siblings, 1 reply; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-03-12 14:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-12 14:14 ` Dmitry A. Kazakov @ 2007-03-12 15:08 ` Markus E Leypold 2007-03-16 8:06 ` Brian May 0 siblings, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-03-12 15:08 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-12 15:08 ` Markus E Leypold @ 2007-03-16 8:06 ` Brian May 2007-03-16 12:53 ` Markus E Leypold 0 siblings, 1 reply; 158+ messages in thread From: Brian May @ 2007-03-16 8:06 UTC (permalink / raw) >>>>> "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> ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-16 8:06 ` Brian May @ 2007-03-16 12:53 ` Markus E Leypold 0 siblings, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-03-16 12:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 17:11 ` Markus E Leypold 2007-03-09 18:22 ` Dmitry A. Kazakov @ 2007-03-10 2:12 ` Randy Brukardt 2007-03-10 10:52 ` Markus E Leypold 2007-03-10 15:48 ` Georg Bauhaus 2007-03-10 18:11 ` Jacob Sparre Andersen 3 siblings, 1 reply; 158+ messages in thread From: Randy Brukardt @ 2007-03-10 2:12 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-10 2:12 ` Randy Brukardt @ 2007-03-10 10:52 ` Markus E Leypold 0 siblings, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-03-10 10:52 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 17:11 ` Markus E Leypold 2007-03-09 18:22 ` Dmitry A. Kazakov 2007-03-10 2:12 ` Randy Brukardt @ 2007-03-10 15:48 ` Georg Bauhaus 2007-03-10 18:11 ` Jacob Sparre Andersen 3 siblings, 0 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-03-10 15:48 UTC (permalink / raw) 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.) ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 17:11 ` Markus E Leypold ` (2 preceding siblings ...) 2007-03-10 15:48 ` Georg Bauhaus @ 2007-03-10 18:11 ` Jacob Sparre Andersen 2007-03-10 18:42 ` Markus E Leypold 3 siblings, 1 reply; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-03-10 18:11 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-10 18:11 ` Jacob Sparre Andersen @ 2007-03-10 18:42 ` Markus E Leypold 2007-03-12 14:25 ` Jacob Sparre Andersen 0 siblings, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-03-10 18:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-10 18:42 ` Markus E Leypold @ 2007-03-12 14:25 ` Jacob Sparre Andersen 2007-03-12 15:17 ` Markus E Leypold 0 siblings, 1 reply; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-03-12 14:25 UTC (permalink / raw) 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?� ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-12 14:25 ` Jacob Sparre Andersen @ 2007-03-12 15:17 ` Markus E Leypold 0 siblings, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-03-12 15:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-06 15:07 ` Markus E Leypold 2007-03-07 22:06 ` Georg Bauhaus @ 2007-03-09 13:41 ` Robert Deininger 2007-03-09 17:15 ` Markus E Leypold 1 sibling, 1 reply; 158+ messages in thread From: Robert Deininger @ 2007-03-09 13:41 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 13:41 ` Robert Deininger @ 2007-03-09 17:15 ` Markus E Leypold 2007-03-09 18:58 ` Larry Kilgallen 0 siblings, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-03-09 17:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 17:15 ` Markus E Leypold @ 2007-03-09 18:58 ` Larry Kilgallen 2007-03-10 10:27 ` Markus E Leypold 0 siblings, 1 reply; 158+ messages in thread From: Larry Kilgallen @ 2007-03-09 18:58 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-09 18:58 ` Larry Kilgallen @ 2007-03-10 10:27 ` Markus E Leypold 0 siblings, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-03-10 10:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-06 12:56 ` Georg Bauhaus 2007-03-06 15:07 ` Markus E Leypold @ 2007-03-06 15:08 ` Jacob Sparre Andersen 2007-03-07 19:21 ` Hyman Rosen 2 siblings, 0 replies; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-03-06 15:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-06 12:56 ` Georg Bauhaus 2007-03-06 15:07 ` Markus E Leypold 2007-03-06 15:08 ` Jacob Sparre Andersen @ 2007-03-07 19:21 ` Hyman Rosen 2007-03-07 20:27 ` Markus E Leypold 2007-03-07 21:12 ` Georg Bauhaus 2 siblings, 2 replies; 158+ messages in thread From: Hyman Rosen @ 2007-03-07 19:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-07 19:21 ` Hyman Rosen @ 2007-03-07 20:27 ` Markus E Leypold 2007-03-07 21:12 ` Georg Bauhaus 1 sibling, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-03-07 20:27 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-07 19:21 ` Hyman Rosen 2007-03-07 20:27 ` Markus E Leypold @ 2007-03-07 21:12 ` Georg Bauhaus 1 sibling, 0 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-03-07 21:12 UTC (permalink / raw) 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. :) ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-05 12:16 ` Georg Bauhaus 2007-03-05 13:20 ` Markus E Leypold @ 2007-03-06 3:07 ` Brian May 1 sibling, 0 replies; 158+ messages in thread From: Brian May @ 2007-03-06 3:07 UTC (permalink / raw) >>>>> "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> ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 11:46 ` Markus E Leypold 2007-02-24 14:54 ` Georg Bauhaus @ 2007-02-24 18:28 ` Martin Krischik 1 sibling, 0 replies; 158+ messages in thread From: Martin Krischik @ 2007-02-24 18:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 6:34 ` Martin Krischik 2007-02-24 11:46 ` Markus E Leypold @ 2007-02-24 13:04 ` Larry Kilgallen 2007-02-24 16:16 ` Markus E Leypold 2007-03-05 1:03 ` Brian May 2 siblings, 1 reply; 158+ messages in thread From: Larry Kilgallen @ 2007-02-24 13:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 13:04 ` Larry Kilgallen @ 2007-02-24 16:16 ` Markus E Leypold 2007-02-25 14:18 ` Larry Kilgallen 0 siblings, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-02-24 16:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 16:16 ` Markus E Leypold @ 2007-02-25 14:18 ` Larry Kilgallen 0 siblings, 0 replies; 158+ messages in thread From: Larry Kilgallen @ 2007-02-25 14:18 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 6:34 ` Martin Krischik 2007-02-24 11:46 ` Markus E Leypold 2007-02-24 13:04 ` Larry Kilgallen @ 2007-03-05 1:03 ` Brian May 2007-03-05 10:34 ` Martin Krischik 2 siblings, 1 reply; 158+ messages in thread From: Brian May @ 2007-03-05 1:03 UTC (permalink / raw) >>>>> "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> ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-05 1:03 ` Brian May @ 2007-03-05 10:34 ` Martin Krischik 2007-03-05 20:46 ` Simon Wright 0 siblings, 1 reply; 158+ messages in thread From: Martin Krischik @ 2007-03-05 10:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-03-05 10:34 ` Martin Krischik @ 2007-03-05 20:46 ` Simon Wright 0 siblings, 0 replies; 158+ messages in thread From: Simon Wright @ 2007-03-05 20:46 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 8:16 ` gautier_niouzes 2007-02-22 10:25 ` Simon Wright 2007-02-22 11:02 ` Alex R. Mosteo @ 2007-02-22 11:19 ` Jean-Pierre Rosen 2007-02-22 13:49 ` Maciej Sobczak ` (3 more replies) 2 siblings, 4 replies; 158+ messages in thread From: Jean-Pierre Rosen @ 2007-02-22 11:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 11:19 ` Jean-Pierre Rosen @ 2007-02-22 13:49 ` Maciej Sobczak 2007-02-22 14:25 ` Jean-Pierre Rosen 2007-02-22 17:07 ` Adam Beneschan ` (2 subsequent siblings) 3 siblings, 1 reply; 158+ messages in thread From: Maciej Sobczak @ 2007-02-22 13:49 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 13:49 ` Maciej Sobczak @ 2007-02-22 14:25 ` Jean-Pierre Rosen 2007-02-22 15:12 ` Larry Kilgallen 2007-02-22 15:15 ` Ludovic Brenta 0 siblings, 2 replies; 158+ messages in thread From: Jean-Pierre Rosen @ 2007-02-22 14:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 14:25 ` Jean-Pierre Rosen @ 2007-02-22 15:12 ` Larry Kilgallen 2007-02-22 15:15 ` Ludovic Brenta 1 sibling, 0 replies; 158+ messages in thread From: Larry Kilgallen @ 2007-02-22 15:12 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 14:25 ` Jean-Pierre Rosen 2007-02-22 15:12 ` Larry Kilgallen @ 2007-02-22 15:15 ` Ludovic Brenta 2007-02-22 15:54 ` Dmitry A. Kazakov 2007-02-22 16:20 ` Ada.Command_Line and wildcards Jean-Pierre Rosen 1 sibling, 2 replies; 158+ messages in thread From: Ludovic Brenta @ 2007-02-22 15:15 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 15:15 ` Ludovic Brenta @ 2007-02-22 15:54 ` Dmitry A. Kazakov 2007-02-22 18:26 ` Markus E Leypold 2007-02-22 16:20 ` Ada.Command_Line and wildcards Jean-Pierre Rosen 1 sibling, 1 reply; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-02-22 15:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 15:54 ` Dmitry A. Kazakov @ 2007-02-22 18:26 ` Markus E Leypold 2007-02-22 19:34 ` Dmitry A. Kazakov 2007-02-25 16:35 ` wildcards with unix shells Martin Krischik 0 siblings, 2 replies; 158+ messages in thread From: Markus E Leypold @ 2007-02-22 18:26 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 18:26 ` Markus E Leypold @ 2007-02-22 19:34 ` Dmitry A. Kazakov 2007-02-22 20:38 ` Simon Wright 2007-02-25 16:35 ` wildcards with unix shells Martin Krischik 1 sibling, 1 reply; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-02-22 19:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 19:34 ` Dmitry A. Kazakov @ 2007-02-22 20:38 ` Simon Wright 2007-02-23 8:43 ` Dmitry A. Kazakov 0 siblings, 1 reply; 158+ messages in thread From: Simon Wright @ 2007-02-22 20:38 UTC (permalink / raw) "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? ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 20:38 ` Simon Wright @ 2007-02-23 8:43 ` Dmitry A. Kazakov 0 siblings, 0 replies; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-02-23 8:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* wildcards with unix shells 2007-02-22 18:26 ` Markus E Leypold 2007-02-22 19:34 ` Dmitry A. Kazakov @ 2007-02-25 16:35 ` Martin Krischik 1 sibling, 0 replies; 158+ messages in thread From: Martin Krischik @ 2007-02-25 16:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 15:15 ` Ludovic Brenta 2007-02-22 15:54 ` Dmitry A. Kazakov @ 2007-02-22 16:20 ` Jean-Pierre Rosen 2007-02-22 18:34 ` Markus E Leypold 1 sibling, 1 reply; 158+ messages in thread From: Jean-Pierre Rosen @ 2007-02-22 16:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 16:20 ` Ada.Command_Line and wildcards Jean-Pierre Rosen @ 2007-02-22 18:34 ` Markus E Leypold 2007-02-22 19:30 ` Niklas Holsti ` (2 more replies) 0 siblings, 3 replies; 158+ messages in thread From: Markus E Leypold @ 2007-02-22 18:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 18:34 ` Markus E Leypold @ 2007-02-22 19:30 ` Niklas Holsti 2007-02-23 1:01 ` Randy Brukardt 2007-02-23 8:49 ` Jean-Pierre Rosen 2 siblings, 0 replies; 158+ messages in thread From: Niklas Holsti @ 2007-02-22 19:30 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 18:34 ` Markus E Leypold 2007-02-22 19:30 ` Niklas Holsti @ 2007-02-23 1:01 ` Randy Brukardt 2007-02-23 4:44 ` Jeffrey R. Carter ` (2 more replies) 2007-02-23 8:49 ` Jean-Pierre Rosen 2 siblings, 3 replies; 158+ messages in thread From: Randy Brukardt @ 2007-02-23 1:01 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 1:01 ` Randy Brukardt @ 2007-02-23 4:44 ` Jeffrey R. Carter 2007-02-23 5:06 ` Anders Wirzenius 2007-02-23 8:43 ` Jacob Sparre Andersen 2 siblings, 0 replies; 158+ messages in thread From: Jeffrey R. Carter @ 2007-02-23 4:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 1:01 ` Randy Brukardt 2007-02-23 4:44 ` Jeffrey R. Carter @ 2007-02-23 5:06 ` Anders Wirzenius 2007-02-24 16:37 ` Simon Wright 2007-02-23 8:43 ` Jacob Sparre Andersen 2 siblings, 1 reply; 158+ messages in thread From: Anders Wirzenius @ 2007-02-23 5:06 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 5:06 ` Anders Wirzenius @ 2007-02-24 16:37 ` Simon Wright 2007-02-25 16:42 ` Martin Krischik 2007-02-26 11:59 ` Anders Wirzenius 0 siblings, 2 replies; 158+ messages in thread From: Simon Wright @ 2007-02-24 16:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 16:37 ` Simon Wright @ 2007-02-25 16:42 ` Martin Krischik 2007-02-26 20:51 ` Simon Wright 2007-02-26 11:59 ` Anders Wirzenius 1 sibling, 1 reply; 158+ messages in thread From: Martin Krischik @ 2007-02-25 16:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-25 16:42 ` Martin Krischik @ 2007-02-26 20:51 ` Simon Wright 2007-02-27 7:11 ` Martin Krischik 0 siblings, 1 reply; 158+ messages in thread From: Simon Wright @ 2007-02-26 20:51 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-26 20:51 ` Simon Wright @ 2007-02-27 7:11 ` Martin Krischik 2007-02-27 21:32 ` Björn Persson 0 siblings, 1 reply; 158+ messages in thread From: Martin Krischik @ 2007-02-27 7:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 7:11 ` Martin Krischik @ 2007-02-27 21:32 ` Björn Persson 2007-02-27 21:56 ` Georg Bauhaus 0 siblings, 1 reply; 158+ messages in thread From: Björn Persson @ 2007-02-27 21:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 21:32 ` Björn Persson @ 2007-02-27 21:56 ` Georg Bauhaus 2007-02-27 22:53 ` Markus E Leypold 0 siblings, 1 reply; 158+ messages in thread From: Georg Bauhaus @ 2007-02-27 21:56 UTC (permalink / raw) 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! :-) :-) ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 21:56 ` Georg Bauhaus @ 2007-02-27 22:53 ` Markus E Leypold 2007-02-28 13:55 ` Georg Bauhaus 0 siblings, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-02-27 22:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 22:53 ` Markus E Leypold @ 2007-02-28 13:55 ` Georg Bauhaus 2007-02-28 14:25 ` Markus E Leypold 0 siblings, 1 reply; 158+ messages in thread From: Georg Bauhaus @ 2007-02-28 13:55 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-28 13:55 ` Georg Bauhaus @ 2007-02-28 14:25 ` Markus E Leypold 0 siblings, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-02-28 14:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 16:37 ` Simon Wright 2007-02-25 16:42 ` Martin Krischik @ 2007-02-26 11:59 ` Anders Wirzenius 2007-02-26 14:46 ` Larry Kilgallen 1 sibling, 1 reply; 158+ messages in thread From: Anders Wirzenius @ 2007-02-26 11:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-26 11:59 ` Anders Wirzenius @ 2007-02-26 14:46 ` Larry Kilgallen 0 siblings, 0 replies; 158+ messages in thread From: Larry Kilgallen @ 2007-02-26 14:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 1:01 ` Randy Brukardt 2007-02-23 4:44 ` Jeffrey R. Carter 2007-02-23 5:06 ` Anders Wirzenius @ 2007-02-23 8:43 ` Jacob Sparre Andersen 2007-02-23 11:34 ` Jean-Pierre Rosen 2007-02-25 16:57 ` Martin Krischik 2 siblings, 2 replies; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-02-23 8:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 8:43 ` Jacob Sparre Andersen @ 2007-02-23 11:34 ` Jean-Pierre Rosen 2007-02-24 13:40 ` Jacob Sparre Andersen 2007-02-25 16:57 ` Martin Krischik 1 sibling, 1 reply; 158+ messages in thread From: Jean-Pierre Rosen @ 2007-02-23 11:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 11:34 ` Jean-Pierre Rosen @ 2007-02-24 13:40 ` Jacob Sparre Andersen 0 siblings, 0 replies; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-02-24 13:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 8:43 ` Jacob Sparre Andersen 2007-02-23 11:34 ` Jean-Pierre Rosen @ 2007-02-25 16:57 ` Martin Krischik 2007-02-26 21:27 ` Björn Persson 1 sibling, 1 reply; 158+ messages in thread From: Martin Krischik @ 2007-02-25 16:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-25 16:57 ` Martin Krischik @ 2007-02-26 21:27 ` Björn Persson 2007-02-27 7:18 ` Martin Krischik 0 siblings, 1 reply; 158+ messages in thread From: Björn Persson @ 2007-02-26 21:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-26 21:27 ` Björn Persson @ 2007-02-27 7:18 ` Martin Krischik 0 siblings, 0 replies; 158+ messages in thread From: Martin Krischik @ 2007-02-27 7:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 18:34 ` Markus E Leypold 2007-02-22 19:30 ` Niklas Holsti 2007-02-23 1:01 ` Randy Brukardt @ 2007-02-23 8:49 ` Jean-Pierre Rosen 2007-02-23 9:29 ` Jacob Sparre Andersen 2 siblings, 1 reply; 158+ messages in thread From: Jean-Pierre Rosen @ 2007-02-23 8:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 8:49 ` Jean-Pierre Rosen @ 2007-02-23 9:29 ` Jacob Sparre Andersen 0 siblings, 0 replies; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-02-23 9:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 11:19 ` Jean-Pierre Rosen 2007-02-22 13:49 ` Maciej Sobczak @ 2007-02-22 17:07 ` Adam Beneschan 2007-02-22 18:40 ` Markus E Leypold ` (2 more replies) 2007-02-22 20:12 ` Gautier 2007-02-23 1:15 ` Robert A Duff 3 siblings, 3 replies; 158+ messages in thread From: Adam Beneschan @ 2007-02-22 17:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 17:07 ` Adam Beneschan @ 2007-02-22 18:40 ` Markus E Leypold 2007-02-23 10:47 ` Rob Norris 2007-02-23 13:28 ` brian.b.mcguinness 2 siblings, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-02-22 18:40 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 17:07 ` Adam Beneschan 2007-02-22 18:40 ` Markus E Leypold @ 2007-02-23 10:47 ` Rob Norris 2007-02-23 13:28 ` brian.b.mcguinness 2 siblings, 0 replies; 158+ messages in thread From: Rob Norris @ 2007-02-23 10:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 17:07 ` Adam Beneschan 2007-02-22 18:40 ` Markus E Leypold 2007-02-23 10:47 ` Rob Norris @ 2007-02-23 13:28 ` brian.b.mcguinness 2007-02-23 13:56 ` Georg Bauhaus 2007-02-23 17:10 ` Adam Beneschan 2 siblings, 2 replies; 158+ messages in thread From: brian.b.mcguinness @ 2007-02-23 13:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 13:28 ` brian.b.mcguinness @ 2007-02-23 13:56 ` Georg Bauhaus 2007-02-23 17:10 ` Adam Beneschan 1 sibling, 0 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-02-23 13:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 13:28 ` brian.b.mcguinness 2007-02-23 13:56 ` Georg Bauhaus @ 2007-02-23 17:10 ` Adam Beneschan 1 sibling, 0 replies; 158+ messages in thread From: Adam Beneschan @ 2007-02-23 17:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 11:19 ` Jean-Pierre Rosen 2007-02-22 13:49 ` Maciej Sobczak 2007-02-22 17:07 ` Adam Beneschan @ 2007-02-22 20:12 ` Gautier 2007-02-23 1:15 ` Robert A Duff 3 siblings, 0 replies; 158+ messages in thread From: Gautier @ 2007-02-22 20:12 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-22 11:19 ` Jean-Pierre Rosen ` (2 preceding siblings ...) 2007-02-22 20:12 ` Gautier @ 2007-02-23 1:15 ` Robert A Duff 2007-02-23 9:25 ` Jacob Sparre Andersen ` (3 more replies) 3 siblings, 4 replies; 158+ messages in thread From: Robert A Duff @ 2007-02-23 1:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 1:15 ` Robert A Duff @ 2007-02-23 9:25 ` Jacob Sparre Andersen 2007-02-24 1:18 ` typed pipes (was: Ada.Command_Line and wildcards) Björn Persson 2007-02-23 14:45 ` Ada.Command_Line and wildcards Larry Kilgallen ` (2 subsequent siblings) 3 siblings, 1 reply; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-02-23 9:25 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 158+ messages in thread
* typed pipes (was: Ada.Command_Line and wildcards) 2007-02-23 9:25 ` Jacob Sparre Andersen @ 2007-02-24 1:18 ` Björn Persson 2007-02-24 8:16 ` typed pipes Dmitry A. Kazakov 2007-02-24 13:37 ` Jacob Sparre Andersen 0 siblings, 2 replies; 158+ messages in thread From: Björn Persson @ 2007-02-24 1:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: typed pipes 2007-02-24 1:18 ` typed pipes (was: Ada.Command_Line and wildcards) Björn Persson @ 2007-02-24 8:16 ` Dmitry A. Kazakov 2007-02-24 13:37 ` Jacob Sparre Andersen 1 sibling, 0 replies; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-02-24 8:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: typed pipes 2007-02-24 1:18 ` typed pipes (was: Ada.Command_Line and wildcards) Björn Persson 2007-02-24 8:16 ` typed pipes Dmitry A. Kazakov @ 2007-02-24 13:37 ` Jacob Sparre Andersen 2007-02-24 16:33 ` Björn Persson 1 sibling, 1 reply; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-02-24 13:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: typed pipes 2007-02-24 13:37 ` Jacob Sparre Andersen @ 2007-02-24 16:33 ` Björn Persson 2007-02-24 20:17 ` Jacob Sparre Andersen 0 siblings, 1 reply; 158+ messages in thread From: Björn Persson @ 2007-02-24 16:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: typed pipes 2007-02-24 16:33 ` Björn Persson @ 2007-02-24 20:17 ` Jacob Sparre Andersen 2007-02-25 1:11 ` Björn Persson 0 siblings, 1 reply; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-02-24 20:17 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: typed pipes 2007-02-24 20:17 ` Jacob Sparre Andersen @ 2007-02-25 1:11 ` Björn Persson 2007-02-25 7:03 ` Jacob Sparre Andersen 0 siblings, 1 reply; 158+ messages in thread From: Björn Persson @ 2007-02-25 1:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: typed pipes 2007-02-25 1:11 ` Björn Persson @ 2007-02-25 7:03 ` Jacob Sparre Andersen 0 siblings, 0 replies; 158+ messages in thread From: Jacob Sparre Andersen @ 2007-02-25 7:03 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 1:15 ` Robert A Duff 2007-02-23 9:25 ` Jacob Sparre Andersen @ 2007-02-23 14:45 ` Larry Kilgallen 2007-02-24 19:24 ` Robert A Duff 2007-02-23 16:58 ` Adam Beneschan 2007-02-23 19:04 ` Hyman Rosen 3 siblings, 1 reply; 158+ messages in thread From: Larry Kilgallen @ 2007-02-23 14:45 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 14:45 ` Ada.Command_Line and wildcards Larry Kilgallen @ 2007-02-24 19:24 ` Robert A Duff 2007-02-25 6:29 ` Hyman Rosen 0 siblings, 1 reply; 158+ messages in thread From: Robert A Duff @ 2007-02-24 19:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 19:24 ` Robert A Duff @ 2007-02-25 6:29 ` Hyman Rosen 2007-02-25 12:21 ` Robert A Duff 0 siblings, 1 reply; 158+ messages in thread From: Hyman Rosen @ 2007-02-25 6:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-25 6:29 ` Hyman Rosen @ 2007-02-25 12:21 ` Robert A Duff 2007-02-25 16:22 ` Pascal Obry 2007-02-25 17:50 ` Jeffrey R. Carter 0 siblings, 2 replies; 158+ messages in thread From: Robert A Duff @ 2007-02-25 12:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-25 12:21 ` Robert A Duff @ 2007-02-25 16:22 ` Pascal Obry 2007-02-25 16:44 ` Dmitry A. Kazakov 2007-02-25 17:50 ` Jeffrey R. Carter 1 sibling, 1 reply; 158+ messages in thread From: Pascal Obry @ 2007-02-25 16:22 UTC (permalink / raw) To: Robert A Duff 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-25 16:22 ` Pascal Obry @ 2007-02-25 16:44 ` Dmitry A. Kazakov 2007-02-26 5:03 ` Hyman Rosen 0 siblings, 1 reply; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-02-25 16:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-25 16:44 ` Dmitry A. Kazakov @ 2007-02-26 5:03 ` Hyman Rosen 2007-02-26 8:44 ` Dmitry A. Kazakov 2007-02-27 0:34 ` Randy Brukardt 0 siblings, 2 replies; 158+ messages in thread From: Hyman Rosen @ 2007-02-26 5:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-26 5:03 ` Hyman Rosen @ 2007-02-26 8:44 ` Dmitry A. Kazakov 2007-02-26 17:11 ` Hyman Rosen 2007-02-27 0:34 ` Randy Brukardt 1 sibling, 1 reply; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-02-26 8:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-26 8:44 ` Dmitry A. Kazakov @ 2007-02-26 17:11 ` Hyman Rosen 2007-02-26 17:34 ` Markus E Leypold 2007-02-26 20:30 ` Dmitry A. Kazakov 0 siblings, 2 replies; 158+ messages in thread From: Hyman Rosen @ 2007-02-26 17:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-26 17:11 ` Hyman Rosen @ 2007-02-26 17:34 ` Markus E Leypold 2007-02-27 16:13 ` Georg Bauhaus 2007-02-26 20:30 ` Dmitry A. Kazakov 1 sibling, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-02-26 17:34 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-26 17:34 ` Markus E Leypold @ 2007-02-27 16:13 ` Georg Bauhaus 2007-02-27 16:19 ` Markus E Leypold 2007-02-27 20:29 ` Randy Brukardt 0 siblings, 2 replies; 158+ messages in thread From: Georg Bauhaus @ 2007-02-27 16:13 UTC (permalink / raw) 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 > > > ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 16:13 ` Georg Bauhaus @ 2007-02-27 16:19 ` Markus E Leypold 2007-02-27 16:39 ` Georg Bauhaus 2007-02-27 20:29 ` Randy Brukardt 1 sibling, 1 reply; 158+ messages in thread From: Markus E Leypold @ 2007-02-27 16:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 16:19 ` Markus E Leypold @ 2007-02-27 16:39 ` Georg Bauhaus 2007-02-27 17:56 ` Markus E Leypold 0 siblings, 1 reply; 158+ messages in thread From: Georg Bauhaus @ 2007-02-27 16:39 UTC (permalink / raw) 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 > ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 16:39 ` Georg Bauhaus @ 2007-02-27 17:56 ` Markus E Leypold 0 siblings, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-02-27 17:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 16:13 ` Georg Bauhaus 2007-02-27 16:19 ` Markus E Leypold @ 2007-02-27 20:29 ` Randy Brukardt 1 sibling, 0 replies; 158+ messages in thread From: Randy Brukardt @ 2007-02-27 20:29 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-26 17:11 ` Hyman Rosen 2007-02-26 17:34 ` Markus E Leypold @ 2007-02-26 20:30 ` Dmitry A. Kazakov 1 sibling, 0 replies; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-02-26 20:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-26 5:03 ` Hyman Rosen 2007-02-26 8:44 ` Dmitry A. Kazakov @ 2007-02-27 0:34 ` Randy Brukardt 2007-02-27 14:52 ` Hyman Rosen 1 sibling, 1 reply; 158+ messages in thread From: Randy Brukardt @ 2007-02-27 0:34 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 0:34 ` Randy Brukardt @ 2007-02-27 14:52 ` Hyman Rosen 2007-02-27 20:43 ` Randy Brukardt 2007-02-27 20:56 ` Dmitry A. Kazakov 0 siblings, 2 replies; 158+ messages in thread From: Hyman Rosen @ 2007-02-27 14:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 14:52 ` Hyman Rosen @ 2007-02-27 20:43 ` Randy Brukardt 2007-02-27 20:56 ` Dmitry A. Kazakov 1 sibling, 0 replies; 158+ messages in thread From: Randy Brukardt @ 2007-02-27 20:43 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-27 14:52 ` Hyman Rosen 2007-02-27 20:43 ` Randy Brukardt @ 2007-02-27 20:56 ` Dmitry A. Kazakov 1 sibling, 0 replies; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-02-27 20:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-25 12:21 ` Robert A Duff 2007-02-25 16:22 ` Pascal Obry @ 2007-02-25 17:50 ` Jeffrey R. Carter 1 sibling, 0 replies; 158+ messages in thread From: Jeffrey R. Carter @ 2007-02-25 17:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 1:15 ` Robert A Duff 2007-02-23 9:25 ` Jacob Sparre Andersen 2007-02-23 14:45 ` Ada.Command_Line and wildcards Larry Kilgallen @ 2007-02-23 16:58 ` Adam Beneschan 2007-02-23 19:12 ` Hyman Rosen 2007-02-24 1:19 ` Björn Persson 2007-02-23 19:04 ` Hyman Rosen 3 siblings, 2 replies; 158+ messages in thread From: Adam Beneschan @ 2007-02-23 16:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 16:58 ` Adam Beneschan @ 2007-02-23 19:12 ` Hyman Rosen 2007-02-23 19:26 ` Adam Beneschan 2007-02-24 1:19 ` Björn Persson 1 sibling, 1 reply; 158+ messages in thread From: Hyman Rosen @ 2007-02-23 19:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 19:12 ` Hyman Rosen @ 2007-02-23 19:26 ` Adam Beneschan 2007-02-25 17:05 ` Martin Krischik 0 siblings, 1 reply; 158+ messages in thread From: Adam Beneschan @ 2007-02-23 19:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 19:26 ` Adam Beneschan @ 2007-02-25 17:05 ` Martin Krischik 0 siblings, 0 replies; 158+ messages in thread From: Martin Krischik @ 2007-02-25 17:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 16:58 ` Adam Beneschan 2007-02-23 19:12 ` Hyman Rosen @ 2007-02-24 1:19 ` Björn Persson 2007-02-24 3:46 ` Adam Beneschan 2007-02-25 17:02 ` Martin Krischik 1 sibling, 2 replies; 158+ messages in thread From: Björn Persson @ 2007-02-24 1:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 1:19 ` Björn Persson @ 2007-02-24 3:46 ` Adam Beneschan 2007-02-24 11:42 ` Markus E Leypold 2007-02-25 17:02 ` Martin Krischik 1 sibling, 1 reply; 158+ messages in thread From: Adam Beneschan @ 2007-02-24 3:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 3:46 ` Adam Beneschan @ 2007-02-24 11:42 ` Markus E Leypold 0 siblings, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-02-24 11:42 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 1:19 ` Björn Persson 2007-02-24 3:46 ` Adam Beneschan @ 2007-02-25 17:02 ` Martin Krischik 1 sibling, 0 replies; 158+ messages in thread From: Martin Krischik @ 2007-02-25 17:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 1:15 ` Robert A Duff ` (2 preceding siblings ...) 2007-02-23 16:58 ` Adam Beneschan @ 2007-02-23 19:04 ` Hyman Rosen 2007-02-23 19:30 ` Adam Beneschan 2007-02-24 19:22 ` Robert A Duff 3 siblings, 2 replies; 158+ messages in thread From: Hyman Rosen @ 2007-02-23 19:04 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 19:04 ` Hyman Rosen @ 2007-02-23 19:30 ` Adam Beneschan 2007-02-23 19:46 ` Dmitry A. Kazakov ` (2 more replies) 2007-02-24 19:22 ` Robert A Duff 1 sibling, 3 replies; 158+ messages in thread From: Adam Beneschan @ 2007-02-23 19:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 19:30 ` Adam Beneschan @ 2007-02-23 19:46 ` Dmitry A. Kazakov 2007-02-23 20:07 ` Markus E Leypold 2007-02-24 1:18 ` Björn Persson 2 siblings, 0 replies; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-02-23 19:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 19:30 ` Adam Beneschan 2007-02-23 19:46 ` Dmitry A. Kazakov @ 2007-02-23 20:07 ` Markus E Leypold 2007-02-24 1:18 ` Björn Persson 2 siblings, 0 replies; 158+ messages in thread From: Markus E Leypold @ 2007-02-23 20:07 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 19:30 ` Adam Beneschan 2007-02-23 19:46 ` Dmitry A. Kazakov 2007-02-23 20:07 ` Markus E Leypold @ 2007-02-24 1:18 ` Björn Persson 2 siblings, 0 replies; 158+ messages in thread From: Björn Persson @ 2007-02-24 1:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-23 19:04 ` Hyman Rosen 2007-02-23 19:30 ` Adam Beneschan @ 2007-02-24 19:22 ` Robert A Duff 2007-02-24 20:26 ` Dmitry A. Kazakov 2007-02-25 7:32 ` Hyman Rosen 1 sibling, 2 replies; 158+ messages in thread From: Robert A Duff @ 2007-02-24 19:22 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 19:22 ` Robert A Duff @ 2007-02-24 20:26 ` Dmitry A. Kazakov 2007-02-25 7:32 ` Hyman Rosen 1 sibling, 0 replies; 158+ messages in thread From: Dmitry A. Kazakov @ 2007-02-24 20:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-24 19:22 ` Robert A Duff 2007-02-24 20:26 ` Dmitry A. Kazakov @ 2007-02-25 7:32 ` Hyman Rosen 1 sibling, 0 replies; 158+ messages in thread From: Hyman Rosen @ 2007-02-25 7:32 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 158+ messages in thread
* Re: Ada.Command_Line and wildcards 2007-02-21 20:43 Ada.Command_Line and wildcards Gautier 2007-02-21 20:59 ` (see below) @ 2007-02-21 21:43 ` Dr. Adrian Wrigley 1 sibling, 0 replies; 158+ messages in thread From: Dr. Adrian Wrigley @ 2007-02-21 21:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 158+ messages in thread
end of thread, other threads:[~2007-03-16 12:53 UTC | newest] Thread overview: 158+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-21 20:43 Ada.Command_Line and wildcards Gautier 2007-02-21 20:59 ` (see below) 2007-02-22 1:13 ` Marc A. Criley 2007-02-22 2:08 ` Adam Beneschan 2007-02-22 5:59 ` (see below) 2007-02-22 8:16 ` gautier_niouzes 2007-02-22 10:25 ` Simon Wright 2007-02-22 11:02 ` Alex R. Mosteo 2007-02-24 6:34 ` Martin Krischik 2007-02-24 11:46 ` Markus E Leypold 2007-02-24 14:54 ` Georg Bauhaus 2007-02-24 16:45 ` Markus E Leypold 2007-02-24 20:08 ` Jacob Sparre Andersen 2007-02-24 20:45 ` Georg Bauhaus 2007-02-25 0:39 ` Björn Persson 2007-02-25 16:29 ` Martin Krischik 2007-02-24 20:26 ` Georg Bauhaus 2007-02-25 7:46 ` Hyman Rosen 2007-02-25 13:19 ` Georg Bauhaus 2007-03-05 1:07 ` Brian May 2007-03-05 1:39 ` Markus E Leypold 2007-03-06 3:48 ` Brian May 2007-03-05 12:16 ` Georg Bauhaus 2007-03-05 13:20 ` Markus E Leypold 2007-03-06 12:56 ` Georg Bauhaus 2007-03-06 15:07 ` Markus E Leypold 2007-03-07 22:06 ` Georg Bauhaus 2007-03-08 5:07 ` Simon Wright 2007-03-08 9:19 ` Markus E Leypold 2007-03-08 9:28 ` Georg Bauhaus 2007-03-08 9:16 ` Markus E Leypold 2007-03-09 13:33 ` Georg Bauhaus 2007-03-09 17:11 ` Markus E Leypold 2007-03-09 18:22 ` Dmitry A. Kazakov 2007-03-09 19:02 ` Markus E Leypold 2007-03-09 20:04 ` Dmitry A. Kazakov 2007-03-10 10:40 ` Markus E Leypold 2007-03-11 0:15 ` Hyman Rosen 2007-03-11 7:59 ` Dmitry A. Kazakov 2007-03-11 14:55 ` Markus E Leypold 2007-03-12 13:32 ` Hyman Rosen 2007-03-12 14:14 ` Dmitry A. Kazakov 2007-03-12 15:08 ` Markus E Leypold 2007-03-16 8:06 ` Brian May 2007-03-16 12:53 ` Markus E Leypold 2007-03-10 2:12 ` Randy Brukardt 2007-03-10 10:52 ` Markus E Leypold 2007-03-10 15:48 ` Georg Bauhaus 2007-03-10 18:11 ` Jacob Sparre Andersen 2007-03-10 18:42 ` Markus E Leypold 2007-03-12 14:25 ` Jacob Sparre Andersen 2007-03-12 15:17 ` Markus E Leypold 2007-03-09 13:41 ` Robert Deininger 2007-03-09 17:15 ` Markus E Leypold 2007-03-09 18:58 ` Larry Kilgallen 2007-03-10 10:27 ` Markus E Leypold 2007-03-06 15:08 ` Jacob Sparre Andersen 2007-03-07 19:21 ` Hyman Rosen 2007-03-07 20:27 ` Markus E Leypold 2007-03-07 21:12 ` Georg Bauhaus 2007-03-06 3:07 ` Brian May 2007-02-24 18:28 ` Martin Krischik 2007-02-24 13:04 ` Larry Kilgallen 2007-02-24 16:16 ` Markus E Leypold 2007-02-25 14:18 ` Larry Kilgallen 2007-03-05 1:03 ` Brian May 2007-03-05 10:34 ` Martin Krischik 2007-03-05 20:46 ` Simon Wright 2007-02-22 11:19 ` Jean-Pierre Rosen 2007-02-22 13:49 ` Maciej Sobczak 2007-02-22 14:25 ` Jean-Pierre Rosen 2007-02-22 15:12 ` Larry Kilgallen 2007-02-22 15:15 ` Ludovic Brenta 2007-02-22 15:54 ` Dmitry A. Kazakov 2007-02-22 18:26 ` Markus E Leypold 2007-02-22 19:34 ` Dmitry A. Kazakov 2007-02-22 20:38 ` Simon Wright 2007-02-23 8:43 ` Dmitry A. Kazakov 2007-02-25 16:35 ` wildcards with unix shells Martin Krischik 2007-02-22 16:20 ` Ada.Command_Line and wildcards Jean-Pierre Rosen 2007-02-22 18:34 ` Markus E Leypold 2007-02-22 19:30 ` Niklas Holsti 2007-02-23 1:01 ` Randy Brukardt 2007-02-23 4:44 ` Jeffrey R. Carter 2007-02-23 5:06 ` Anders Wirzenius 2007-02-24 16:37 ` Simon Wright 2007-02-25 16:42 ` Martin Krischik 2007-02-26 20:51 ` Simon Wright 2007-02-27 7:11 ` Martin Krischik 2007-02-27 21:32 ` Björn Persson 2007-02-27 21:56 ` Georg Bauhaus 2007-02-27 22:53 ` Markus E Leypold 2007-02-28 13:55 ` Georg Bauhaus 2007-02-28 14:25 ` Markus E Leypold 2007-02-26 11:59 ` Anders Wirzenius 2007-02-26 14:46 ` Larry Kilgallen 2007-02-23 8:43 ` Jacob Sparre Andersen 2007-02-23 11:34 ` Jean-Pierre Rosen 2007-02-24 13:40 ` Jacob Sparre Andersen 2007-02-25 16:57 ` Martin Krischik 2007-02-26 21:27 ` Björn Persson 2007-02-27 7:18 ` Martin Krischik 2007-02-23 8:49 ` Jean-Pierre Rosen 2007-02-23 9:29 ` Jacob Sparre Andersen 2007-02-22 17:07 ` Adam Beneschan 2007-02-22 18:40 ` Markus E Leypold 2007-02-23 10:47 ` Rob Norris 2007-02-23 13:28 ` brian.b.mcguinness 2007-02-23 13:56 ` Georg Bauhaus 2007-02-23 17:10 ` Adam Beneschan 2007-02-22 20:12 ` Gautier 2007-02-23 1:15 ` Robert A Duff 2007-02-23 9:25 ` Jacob Sparre Andersen 2007-02-24 1:18 ` typed pipes (was: Ada.Command_Line and wildcards) Björn Persson 2007-02-24 8:16 ` typed pipes Dmitry A. Kazakov 2007-02-24 13:37 ` Jacob Sparre Andersen 2007-02-24 16:33 ` Björn Persson 2007-02-24 20:17 ` Jacob Sparre Andersen 2007-02-25 1:11 ` Björn Persson 2007-02-25 7:03 ` Jacob Sparre Andersen 2007-02-23 14:45 ` Ada.Command_Line and wildcards Larry Kilgallen 2007-02-24 19:24 ` Robert A Duff 2007-02-25 6:29 ` Hyman Rosen 2007-02-25 12:21 ` Robert A Duff 2007-02-25 16:22 ` Pascal Obry 2007-02-25 16:44 ` Dmitry A. Kazakov 2007-02-26 5:03 ` Hyman Rosen 2007-02-26 8:44 ` Dmitry A. Kazakov 2007-02-26 17:11 ` Hyman Rosen 2007-02-26 17:34 ` Markus E Leypold 2007-02-27 16:13 ` Georg Bauhaus 2007-02-27 16:19 ` Markus E Leypold 2007-02-27 16:39 ` Georg Bauhaus 2007-02-27 17:56 ` Markus E Leypold 2007-02-27 20:29 ` Randy Brukardt 2007-02-26 20:30 ` Dmitry A. Kazakov 2007-02-27 0:34 ` Randy Brukardt 2007-02-27 14:52 ` Hyman Rosen 2007-02-27 20:43 ` Randy Brukardt 2007-02-27 20:56 ` Dmitry A. Kazakov 2007-02-25 17:50 ` Jeffrey R. Carter 2007-02-23 16:58 ` Adam Beneschan 2007-02-23 19:12 ` Hyman Rosen 2007-02-23 19:26 ` Adam Beneschan 2007-02-25 17:05 ` Martin Krischik 2007-02-24 1:19 ` Björn Persson 2007-02-24 3:46 ` Adam Beneschan 2007-02-24 11:42 ` Markus E Leypold 2007-02-25 17:02 ` Martin Krischik 2007-02-23 19:04 ` Hyman Rosen 2007-02-23 19:30 ` Adam Beneschan 2007-02-23 19:46 ` Dmitry A. Kazakov 2007-02-23 20:07 ` Markus E Leypold 2007-02-24 1:18 ` Björn Persson 2007-02-24 19:22 ` Robert A Duff 2007-02-24 20:26 ` Dmitry A. Kazakov 2007-02-25 7:32 ` Hyman Rosen 2007-02-21 21:43 ` Dr. Adrian Wrigley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox