AmigaOS 3.1.4! [beta]

[daxb]

I don't know but KingCON can do requester or cycle through objects. It is configurable.

[gulliver]

Originally Posted by Romanujan

Going back to feature/technical discussion:

- does 3.1.4 contain a 'cardreset' fix for A1200 Gayle/PCMCIA?
- there are gossips that Shell-Seg from 3.1.4 got tab autocompletion - is it true? does it work BASH-like way (cycling by available objects), or KingCON-like way (requester)?

There was never a a shell with tab autocompletion during development and that is between many other things, a feature shelved for a future OS release if there is one.

Seems someone is definately spreading false rumours.

BTW, the PCMCIA did receive some love and care.

[Romanujan]

Understood, NDA

Originally Posted by gulliver

Seems someone is definately spreading false rumours

This rumor comes from the Vampire team: http://apollo-core.com/knowledge.php...17194&z=hkWedc

2) Shell-Seg updated and provides tab auto-completion feature even when booting without Startup-Sequence

[gulliver]

I will certainly not waste my time fighting guys spreading FUD.

It is up to them to grow up.

[modrobert]

Originally Posted by DamienD

@kolla; your above post has been reported by numerous people...

Who reported it?

Would be more honest and upfront to reply in this thread instead of reporting it to a moderator.

The question seems relevant and "on topic", to ask who is actually involved in testing and developing this, since it isn't apparent.

[ptyerman]

Think you missed the why he was chastised. Hint: Piracy of it.

[patrik]

Originally Posted by Romanujan

Going back to feature/technical discussion:

- does 3.1.4 contain a 'cardreset' fix for A1200 Gayle/PCMCIA?
- there are gossips that Shell-Seg from 3.1.4 got tab autocompletion - is it true? does it work BASH-like way (cycling by available objects), or KingCON-like way (requester)?

Bash does no cycling. If there are multiple matches so completion needs more input, pressing tab twice shows you all matches.

Windows cmd does cycling. I do not understand this scheme, terrible inefficient and awkward to cycle through all matches with an effective window size of 1.

[modrobert]

Originally Posted by ptyerman

Think you missed the why he was chastised. Hint: Piracy of it.

Yes, my mistake, missed that one. It felt so natural that the Amiga community efforts would be shared between active projects that I completely forgot it's a commercial update.

[Gorf]

Originally Posted by modrobert

It felt so natural that the Amiga community efforts would be shared between active projects...

that would be a huge revolution ....

[modrobert]

Originally Posted by Gorf

that would be a huge revolution ....

Welcome to EAB, that's how we roll, humble and sharing (with a few exceptions).

[Gorf]

Originally Posted by modrobert

Welcome to EAB, that's how we roll, humble and sharing (with a few exceptions).

thats why I love this forum.
But sadly the opposite is true for the rest of the Amiga community (except AROS) and it has been this why for a very long time leading to the known fragmentation and disadvantages for the users and the platform in general.

The situation is much better on C64, Atari or even RiscOS

[Olaf Barthel]

Originally Posted by Romanujan

- there are gossips that Shell-Seg from 3.1.4 got tab autocompletion - is it true? does it work BASH-like way (cycling by available objects), or KingCON-like way (requester)?

Not this time.

We discussed reusing the con-handler/shell code I created for OS4 but it turned out that the design needs a lot more work. So, stay tuned

[Olaf Barthel]

Originally Posted by Romanujan

Understood, NDA



This rumor comes from the Vampire team: http://apollo-core.com/knowledge.php...17194&z=hkWedc

Hm... the content is technically not exactly spot-on. The shell is (of course) a separate kickstart module and a pointer to it winds up in the dos.library base where is referred to as the "shell segment". The "user interface" of the shell is the "con-handler" kickstart module, and this is where the tab completion would have to happen. Except that it doesn't in the AmigaOS 3.1.4 update

[shaf]

this might be a silly question but those of us who have multiple Amiga models, can we buy just the KS ROMs after initially getting the Update Kits? I would need 2 A4000 KS and an A500 KS Chip.

[kolla]

Originally Posted by Olaf Barthel

(con...) this is where the tab completion would have to happen. Except that it doesn't in the AmigaOS 3.1.4 update

Not really, it should be in shell, that was also the last ThoR wrote to me not so long ago. To put it in console handler has always been a (to various degrees "dirty") work-around. Most alternative shells already support various completion methods. Just another part of AmigaOS that is a mess, remember the days when using csh on Amiga was practically the norm

[Gorf]

Originally Posted by kolla

Not really, it should be in shell, that was also the last ThoR wrote to me not so long ago. To put it in console handler has always been a (to various degrees "dirty") work-around.

True
That way the console.handler could support different shells with that feature without having to know any details.

[gregthecanuck]

Well I definitely plan to support 3.1.4 and hopefully many future updates. Whatever doesn't make the 3.1.4 cut can always wait for future releases when it makes sense.

Let's keep the party going!! Nice work Olaf and all other developers and testers.

[Olaf Barthel]

Originally Posted by kolla

Not really, it should be in shell, that was also the last ThoR wrote to me not so long ago. To put it in console handler has always been a (to various degrees "dirty") work-around. Most alternative shells already support various completion methods. Just another part of AmigaOS that is a mess, remember the days when using csh on Amiga was practically the norm

True, it's a mess. The underpinnings of AmigaDOS are vaguely related to design concepts we are today most familiar with in the context of Unix.

This extends to the shell and its commands, which differ from the arguably more robust Unix design in many important points. For example, there is no well-defined shell language, the commands perform the wildcard expansion, and there is no single shell entity but the pair of the command execution engine and the user interface.

In the Unix design the command execution is part of the kernel, and the shell "merely" processes the script or user input before eventually the kernel gets to execute the program code of the command. In AmigaDOS the operating system functions for executing shell commands invoke the shell module (and the shell in turn calls a different set of dos.library functions to execute the program code of a command; these functions didn't even exist in this form until Kickstart 2.0 came around). There is no sound separation of responsibilities. Complex, check!, twisted, check!, error prone, check!

What we got here in AmigaDOS is architecturally so different from what happens in the Unix kernel and the various shells that improvements in how the AmigaDOS shell/console combo works are in order.

I'm very wary of changing what we got because invariably each and every aspect of this AmigaDOS design has side-effects and hidden dependencies which take a while to even document and acknowledge. Some are very, very subtle and require a considerable amount of time to investigate (the Amiga "rigid disk block" partitioning scheme comes to mind, for example).

For example, when the mechanism was discovered which allowed CLI commands to disconnect from the shell environment (disconnecting the input/output streams, too) it only worked well enough with the default ROM shell (which in those days, 1987, was actually part of the lump of code which made up dos.library). Custom shells crashed instead, and, if I remember correctly, the Aztec 'C' runtime library function intended to launch CLI programs crashed, too.

Our current AmigaDOS shell is still just the command execution engine, which has no concept of processing interactive user input. This is what the con-handler does for it. If you add command completion to con-handler you have to make assumptions about the state of the process which it is attached to (could be an interactive shell, could be program which just needs the console window to show its output, the list goes on). This is the big issue here because there's currently no clean way to make this happen.

This is where work is needed. Given how complex and less than pretty the shell code looks like, my guess is that the shell will have to be reworked further quite a bit first since the issues to be solved here are of a bigger scale than for the con-handler and the command completion.

Incidentally, the command completion in the con-handler for OS4 was modeled on the WShell completion code, which offers suffix, prefix and combined prefix+suffix completion. I would be loath to lose this functionality and replace it with what shells today (bash comes to mind) are restricted to (suffix completion only).

[hexaae]

KingCON forever here… would be nice something equal directly in the std CON

[MrDBUG]

Would it be possible to simply make a "new" shell and leave the old for compatibility ?
:-D