Re: Properties

[Shark8 <onewingedshark@gmail.com>]

On Dec 3, 1:16 am, Thomas Løcke <t...@ada-dk.org> 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 =>
> > File_Extention, Element =>  Application_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=pages, 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:=
         Get_Standard_Input;  -- Initializes to standard in.
 Output : Access Ada.Streams.Root_Stream_Type'Class:=
         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 =>
   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?