ptorric wrote:
(sorry for my pour english)
Unfortunately, the quality of the English will make understanding somewhat difficult. Please bear with us if we don't seem to understand.
Quote:
in our days, the role of a cli is secondary (but powershell...brrrr!) because we use a gui (also in linux bash is loosing positions)
I encourage you to reconsider this position. The GUI has not dominated the CLI for even moderately advanced users. This includes on MacOS X installations. A cursory search of MacOS X tips shows a plethora of blog articles detailing the usage of the CLI.
Also, remember too that not all CLIs are the same. Much of the CLI syntax used in Windows and Unix systems are arcane, optimized for rapid writing of one-off scripts by system administrators under heavy pressure from technical support and senior management, but
not for user comprehension at all.
Contrast this with Tripos (and, by extension, AmigaDOS), where command names use real, honest-to-goodness words, and have real, honest-to-goodness parsers to interpret command-line options.
Quote:
what i'm asking to myself, and maybe someone is interested, if in our days is it possible to project a good environment for to drive a 6502 o.s. without reinventing the wheel or copying a pre-existent solution.
Here is where my understanding breaks down. I really don't know what you're asking here.
Here's my attempt to guess based on context: as far as I can tell, you are asking if it's possible to evolve from a CLI-based environment to a GUI-based environment without discarding old software?
The answer is yes -- there are three ways to accomplish this that I know of:
* Rewrite the CLI so that it, itself, is a GUI application. This is the approach that AmigaOS took, and with stellar results (refer to the Amiga ROM Kernel manual, Libraries and Devices, and read up on the "console.device" component).
* Write your CLI commands so that their business logic sits in a shared library. That way, the CLI 'command' is just a program that links against the library, parses CLI options, and then passes all the dirty work off to the library. Then, the GUI version of the same program does the same thing -- presenting a window or dialog box with the relevant options, then passing everything off to the library to do the dirty work.
* Write your CLI commands so that its input and output are concurrently machine- and human-readable. Many Linux tools are written this way. Numerous CD-burners, for example, don't actually touch the SCSI interface at all -- they launch a program called "cdrecord", which is a command-line tool whose output is (more-or-less) easily intercepted by another program and translated into a GUI display in real-time.
Indeed, the jump from CLI to GUI is actually somewhat small as long as good user interface guidelines are supported for both the GUI and the CLI application environments. Jumping from a single-tasking to a multi-tasking operating system, however, is a
substantially more disruptive change.
With all this being said, however, be aware that you're making a change for a reason: it's foolish not to write software which exploits the new features you've worked so hard to make possible.
Quote:
rexx, like in amiga, or bash as in linux are complex languages, maybe too complex for a 6502 project, where the use of memory must be conservative.
Not necessarily,
IF you're willing to precompile your scripts first. This is the approach that Python takes:
Step 1. When launching your script's interpreter, check to see if it needs to be recompiled into bytecode first. If so, perform the compilation.
Step 2. Then, just interpret the bytecode.
The pre-compilation step is totally transparent to the user, except for the length of time it might take (particularly on slower CPUs or I/O subsystems).