MacRelix: Feature Request - auto-complete in sh

[yhaenggi]

Hi

It would be great to have auto-complete for files/directories in macrelix's sh.

[jjuran]

MacRelix's console view currently handles all editing on its own, and sh only sees the final product. Maybe I could implement filename-only completion in the console view, if it had some way of knowing the current directory.

The real solution is to implement cbreak mode in MacRelix and have sh enable it and handle editing itself.

[marciot]

MacRelix's console view currently handles all editing on its own, and sh only sees the final product. Maybe I could implement filename-only completion in the console view, if it had some way of knowing the current directory.

Dumb suggestion, add a prompt to the shell with the current directory and have the console look for that? BTW, how does communication take place between the shell and the console? Is it a device driver? (that is how Symantec C++ handles console output in their ANSI libraries). I am curious whether I could write Mac apps that could be used from within MacRelix. That would open up a lot of possibilities.

[jjuran]

add a prompt to the shell with the current directory and have the console look for that?

The console has no business trying to recognize what it or isn't a shell prompt, much less trying to scrape information out of one. In any case, there's no need — the console view knows its terminal, which knows its foreground process group, from which we can examine the process group leader's current directory.

I made a simple proof of concept that can complete an unambiguous, single-component pathname, proving that locating the current directory works. Extending this to be more generally useful is a straightforward (though not trivial) task.

[jjuran]

BTW, how does communication take place between the shell and the console?

Like any user-space process, the shell makes system calls. /dev/con/1 is both a tty and a terminal, which are distinct concepts in MacRelix but tied together on the same filehandle. The terminal is internally linked both to the window and to the console in its view hierarchy.

[jjuran]

the console? Is it a device driver? (that is how Symantec C++ handles console output in their ANSI libraries).

MacRelix provides its own vfs layer, which uses File Manager APIs to access Mac filesystems. It also uses the Device Manager to talk to serial ports, but it doesn't provide any device drivers.

All GUI elements in MacRelix except the About box are mapped into the virtual file system, so console output isn't really any different in principle than file output.

[jjuran]

I am curious whether I could write Mac apps that could be used from within MacRelix.

I've experimented with that. Try out about, mon, confirm, prompt, and asklogin. (The original front end for Advanced Mac Substitute was actually a MacRelix applet!)

I've since concluded that a file system interface is not suitable for all applications, and I've been replacing API-wrapping vfs modules with programs that call those APIs directly. (You can call any Mac OS API from a MacRelix tool, but using it correctly and cleaning up afterward is your responsibility, unlike with filehandles.)

I still really like the idea of making APIs available to the casual scripter — but lately I've been thinking direct support in the language is the way to go.

[jjuran]

I made a simple proof of concept that can complete an unambiguous, single-component pathname, proving that locating the current directory works. Extending this to be more generally useful is a straightforward (though not trivial) task.

I've done this.

One limitation is that it only completes shell-safe characters. Another is that it doesn't recognize non-path syntax (like leading ~ for home directories). Also, as console input behavior, it's on all the time, whether you're in the shell or not.

Those caveats aside, it works. Enjoy!