Anyone interested in Antiquities?

Software
1

For the last few days I’ve been exploring a couple of programs with a rather ancient history. (Well, thirty years is an aeon in computers…) They are both still in use today, so I guess they must be of some use. The following is likely a product of my oddball interests, so if you don’t share them neither of us should be bothered.

First (though actually the second that I encountered), has anyone played with the Extensible Shell (“es”)? @Donn, I see your name prominently in its mailing list early days. Are you still interested?

For a couple of days, I thought this was the shell I’ve been looking for all my computer life. I soon discovered some drawbacks, too, but it’s definitely something I’ll keep around – especially for scripts. Its syntax is a delight compared to bash.

One neat feature is that all variables are lists, not just strings. This turns out to be rather convenient for managing arguments and things. And structuring is done with braces, nested if needed, so it’s all nice and clean. I’ve been writing a few scripts in it, and it flows well.

The two most serious lacks are no job control, and a complete absence of arithmetic. Apparently the designers (according to the mailing list archive) thought the first was “unnecessary”. With a new terminal being easily popped up, OK, it is, but when I’m remotely logged in somewhere I tend to use ctrl-Z a lot. (I see on its GitHub site that someone wrote a job control patch, but I haven’t looked at it.) Being unable to compute indices into lists is a severe limitation. I hacked up a ‘calc’ command using ‘bc’, but I don’t know how well it will work.

I see that the es shell has a package on HaikuDepot, so it’s easy to check out. I came to it by a back road, so I built a slightly earlier version, but the differences are trivial – except that I tweaked my copy a bit, to initialize non-login as well as login shells. (I want some custom functions in scripts started from an icon, for one thing.)

This odyssey began when I started thinking again about Rob Pike’s Sam text editor – which is getting on for forty years old! I’ve been using its “Structural Regular Expressions” pretty well daily for over twenty years in my own app. (Which I’ve given up trying to persuade anyone else to use, but I can’t live without it…) Sam led to Plan9, which uses a shell ‘rc’, which became ‘es’, so that’s how my journey went.

I found a Linux Sam on GitHub, so I thought it worth playing with. Whether it could ever be brought to Haiku is another question. One unusual thing about the editor is that it’s in two parts: the sam engine and a GUI ‘samterm’. The GUI is X11-based, so a Haiku equivalent would be a complete rewrite, but ‘sam’ itself can be run from the command line and does in fact work in Haiku.

The power of sam lies in those structural regular expressions, which are not bound by lines like other RE tools. Makes it easy to select arbitrary desired segments of text to work on. Without a GUI, though, you really have no feedback, and it doesn’t even incorporate readline. With everything in one window it’s pretty hopeless. I made it a bit more usable by wrapping it in a Weaver configuration, with separate input and display TextViews, but it’s still far from ideal. I have used it a couple of times to do repetitive edits, but it’s not going to replace Koder or Pe!

I must say I’d love a visual editor that also had good RE selection. for the times when simple Search-and-Replace don’t suffice, but I have a feeling that creating a GUI for sam would be a major job.

Well, that was a long essay, probably of little interest to anyone else, but I had fun exploring those bits of history, and ES at least is a keeper.

1 Like
2

In fact not long ago I installed es, just for old times’ sake. Delightful programming shell. For me, not an interactive environment I’d care to use, so the lack of job control is not a worry. I did for some reason use “rc” for an interactive shell in one situation for a while, but I don’t think it lasted very long. Unfortunately I remember next to nothing from those days back in the '90s, so I can’t say if I had any serious issues with es.

For me, that problem space as it were, is pretty thin. The UNIX shell is far inferior as a programming environment, but it’s arguably good enough anyway. There have been shell scripts that turned into big unmanageable problems, for sure, but I think more because of the development process than because of the language.

3

Care to say why, in particular? I have hit a few inconveniences, like not being friendly to long-options (you have to quote an equals) but I’ve found it kind of cool sometimes when I want a bit more than a plain command line. How about, for instance:

diff <{ls workdir} <{ls backupdir)

to check the differences between two directories?

“Good enough” is the important thing, I guess. I’m trying to remember where I saw a quote to the effect that “good enough” is the enemy of adopting better solutions. Once you’re used to something, it takes a lot to overcome inertia to switch to a better idea.

But now having played with es long enough to understand it (mostly!) I’m going to try to use it for scripting at least. I have a lot of – mostly xicon – scripts I use day-to-day and I think es will work well for that.

4

For sure, it’s great to be able to work with something like that when you have an application that takes a heavy amount of script programming.

This is a totally off the top of my head with no real basis thought - BeOS/Haiku application scripting? (As opposed to UNIX/Haiku scripting, what shells do.) Applications these days aren’t really built for it, like they were on the Amiga, but maybe with a more potent script language than sh+hey there’d be a demand for that.

As for interactive use … 98% of what I need is command line editing and simple redirection. Es redirection is fine, of course, and it seems to have command line editing here. That’s one thing I’m a little picky over … don’t see how to set command line editing to vi mode, but it’s probably in there somewhere. Reviewing the man page, I’m reminded that I used to like how you could easily apply an operation to a list variable -

; x = a b c
; echo $a ^ .html
a.html b.html c.html

I’m also vaguely reminded that I didn’t like how they used the UNIX environment, as I recall they stuffed function definitions and so forth in there.

But mainly it’s just that I don’t care that much about the programming features unless there’s at least somewhat challenging programming involved, and if I don’t care, I’m more than happy with the UNIX shell that comes in the box. It isn’t like the old Berkeley days when they’d give you csh.

5

Yeah, once upon a time I dreamed of programs talking to each other to do great things. (I wrote an improved IPC scheme for the Amiga to do just that.) Never worked out that way. A lot of hulking monoliths around.

Most of my scripts are Xicon. They sit on the desktop waiting to be clicked on or to have a file dropped on them to do some quick job. If things get complex I’ll probably use ruby rather than bash, but in most cases they’re too simple to need that.

Regarding command line editing, es uses readline and .inputrc, so for me it’s exactly the same as bash. Apparently I’ve been using emacs mode all these years and never knew it(!). I set vi mode in .inputrc and the differences were minor – took me a while to find them. I have the special keys I use set explicitly anyway. But you sent me on a reading spree! Actually read the bash manual command line editing section plus some web stuff, and found a bunch of useful keys I never knew about!

I think I like the way functions get exported, though it does clutter up printenv a bit! That was one reason I added a .es_init file for non-login shells, though, so I can cancel functions that are not appropriate there.

But yeah, bash is adequate – and familiar…

6

See, in my opinion, you should be able to count on a script file executing the same way, regardless of user ID, regardless of caller. There are some obvious major holes in that - PATH, at least - but the fewer the better. I don’t want my scripts inheriting a bunch of junk from the environment, running initialization files or any such folderol. But even if the principle were sound, it just looks like a hack. Did anyone check to see how big those environment variables can be before it starts to cause trouble, and on a variety of operating systems?

My dream (I usually don’t remember my dreams, and guess it’s just as well) for application scripting, is that you could automate an online operation of moderate complexity through WebPositive. That’s the “killer app” that would get the ball rolling. WebPositive would have to expose the various controls in a useful way, and unless that happens I guess it hardly matters what tools we have to take advantage of it.

7

Huh. I don’t see that as a problem in my use. I either want utiity functions that I can rely on being available everywhere (which go in the init file), or they’re intended for interactive use, in which case they’ll be in .esrc and will usually have unique names that won’t appear in scripts. The only breaker is ‘cd’, which I’ve overloaded to both put the folder in the tab and act like pushd. Don’t want either in stand-alone scripts, so the init file restores the default.

Unlike attributes, I wouldn’t think there are any limits on environment storage. Just clutter.

I guess scripting is never going to happen now. I never had much use for BeOS scripting. I’ve used it exactly once I think (to minimize the window of a program launched at boot). I like Willy Langeveld’s scheme better – closer to my Amiga idea – but it also needs apps to be written for it and nobody’s going to do that.

8

Well it’s definitely somewhere in my roadmap. What’s the point of making a new OS like Haiku if we can’t achieve such things? But it’s not the top priority. At the moment I’d be happy with using my large VGA display instead of the 12" one in my laptop, and a more functional web browser. I’m at a point where I end up running another OS on another machine on that large VGA display and moving too much of my computer activity there, which is not nice.

1 Like
9

That’s good to hear! :slightly_smiling_face: Do you have any particular applications/areas in mind?

Come to think of it, I suppose my ‘Weaver’ is an example of that way of working, if in a somewhat specialized environment. Modules are connected in a dataflow diagram to perform enhanced functions. It’s mainly to do things with MIDI, but the ‘StreamWeaver’ modules handle generic byte-streams, and you can plug in almost any command line that uses stdin and stdout. As I mentioned earlier in the thread, I plugged in sam to improve its usability.

Maybe I should start promoting it again! :grinning:

10

I was saying this more from the OS development side.

For the apps I work on, the one where I did most work on that side is ACE, which is ported from MorphOS so it of curse uses AREXX. But I have not decided that this is the way to go, it just was convenient in that particular case (I have enough problems rewriting the whole GUI already, let’s not add the scripting to that).

I’m aware of the existence of MusicWeaver and StreamWeaver although I never took the time to really dig into that. I’ll certainly do when I get to work on the topic.

On a more general view, here’s what I think would make a good scripting system (but, it’s only my current opinion and it may change):

  • Use of a nice scripting language, and maybe even allow multiple ones (Lua, Python, …)
  • Discoverability of scripting endpoints in applications (a bit like the “getsuites” in hey), and to discover apps which expose endpoints even if they are not running (BeBREXX has a PortManager server for that, but BRoster would probably do the job just as well)
  • Apps bundled with Haiku used as an example/reference implementation by allowing access to all their functions through scripting
  • An API that doesn’t feel like an aftertought (that means, use BMessages, and in general work with the existing way apps are written)

Not having done a complete survey of the existing tools both inside and outside Haiku, I need to do some research first.

11

Ahh… I like… A nice set of objectives.

Script language agnosticism is important, I think. Even bash if that feels appropriate. A clean API that’s easy to wrap with any interpreter.

How would you find the endpoints of non-running apps — new mime-db attributes?

Would be nice…

Of course! (I actually think Willy’s is pretty good. Straightforward and understandable.) I’m thinking an extension to an interface for MUSCLE messages would be cool. Control apps on other machines…!