From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,36a29c2860aff686 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!21g2000prv.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Properties Date: Sat, 4 Dec 2010 11:53:28 -0800 (PST) Organization: http://groups.google.com Message-ID: <88c3cb91-132b-4f24-bf0f-92ec7fd934b5@21g2000prv.googlegroups.com> References: 4cf8a744$0$23761$14726298@news.sunsite.dk NNTP-Posting-Host: 174.28.198.93 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1291492408 27163 127.0.0.1 (4 Dec 2010 19:53:28 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 4 Dec 2010 19:53:28 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 21g2000prv.googlegroups.com; posting-host=174.28.198.93; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:16775 Date: 2010-12-04T11:53:28-08:00 List-Id: On Dec 3, 1:16=A0am, Thomas L=F8cke wrote: > It's of course less portable if you try to use it with the C shell. C-shell -> irksome. Having to migrate between C- and BASH-shells -> more irksome. Sometimes using a different shell is not an option, as policy may forbid such 'foreign'/non-approved software. All shells must implement *-expansion, which means that it is close-to- if-not-impossible to consistently/portability get the user's as-typed command; granted that some shell or system may allow access to the as- typed command but that would be making use of a feature not-portable to other systems. > If you don't like BASH, csh, zsh or Korn, then why not try > something like BUSH: > > http://www.pegasoft.ca/bush.html > > It has a very Ada-like approach to shell scripting. I'll have to give it a look. > > > The lack of types on files is another; old Macs had file-types down, > > but *nix has nothing like that (nor does it have even the capability > > for it, kernel-wise). {Windows has a [barely] workable file-extension/ > > association scheme -- analogous to an Ada map of (Key =3D> > > File_Extention, Element =3D> =A0Application_Info).} > > The "file" command is your friend. > > It just works, and it doesn't depend on some shaky dot extension scheme. Er, you missed my point that the "shaky dot extension scheme" is barely workable. Using a facility like the file command means that any file-type cannot be determined w/o some sort of processing on the file itself [the results may be saved/indexed for future use/performance]; the dot- extension alleviates the need for this processing at the expense of the unreliable extension (rather like a typecast in C); an actual typed-file file-system has neither of these problems. Period. > > Simple file->program association is handled well in both KDE and Gnome. > I suspect other desktop environments have similar systems in place. I > don't think this is a job for the kernel. Why not? Isn't the job of the kernel to facilitate the use of the computer's resources? If files are considered resources* then checking that they are used properly cannot but be a part of the kernel's job. *The *nix philosophy of "everything is a file" mandates that resources (as a part of *everything*) are files. > > One single hyphenated-word: man-pages. > > The old DOS hypertext help was superior to man=3Dpages, windows .HLP > > file help was/is superior to man-pages, the OpenVMS help-system is > > FAR, FAR more usable than man-pages. > > man rename > man file > > What's wrong with that? It could not be any easier. > It's easy, flexible and it works. And here I thought the goal of the os was to make the machine usable to human-users, not force them to act like machines. The navigation system for man pages is, far far far subpar to any of the help-systems I mentioned. In particular the DOS and VMS help systems are both-text based and both can be easily navigated via keyboard. > > > Error codes? In *nix programs may or may not use them... (some > > programs return 0/success when errors were encountered) which makes > > them less than useless. > > Hardly the fault of *nix, just as the abundance of horrible software > for Windows cannot be blamed on Windows itself. Actually it is the fault of unix, via C, which mandates that the main subprogram return an error-code. A better system would be one where programs are run and exceptions are thrown on errors (the exception could be handled in-program or propagated out). Something, conceptually similar to this: -- In this system all program-entries have input and -- output streams as parameters and a parameter which -- contains the command as typed. Type Program_Procedure is Access All Procedure( Input, Output : In Ada.Streams.Root_Stream_Type'Class; Command : String ); Procedure Run_Program( Program : in Program_Procedure; Command : String ) is Input : Access Ada.Streams.Root_Stream_Type'Class:=3D Get_Standard_Input; -- Initializes to standard in. Output : Access Ada.Streams.Root_Stream_Type'Class:=3D Get_Standard_Output; -- Initializes to standard out. -- Command is passed in from the command-interpreter. begin Program.All( Input, Output, Command ); exception -- handle 'normal' [predefined] exceptions... When Event: Others =3D> Ada.Text_IO.Put_line( '[' & Exception_Name(Event) & ']' & ':' & Character'Pos(9) & -- padding for the message Exception_Message(Event) ); end Run_Program; Since something in the vein of the above does not use error-codes programmers cannot do something like: int main() { get_list(); operate_list(); // some error occurs here return SUCCESS; } The above undermines/invalidates the entire reasoning for requiring main() to return an error-code, no?