[TUHS] A few comments on porting the Bourne shell

segaloco via TUHS tuhs at tuhs.org
Tue Jan 3 08:54:22 AEST 2023


A shell is only as powerful as the constructs it can interact with.  One can do logic all day and night but if that logic isn't being put to work, it's just an exercise in vanity.  I think that's a good point that scripting problems may be a symptom of the nature of the tools being used in them.

So the day job is pretty much an all Microsoft shop, from .NET code to IIS servers, not a '$' prompt in sight usually.  However, being a scientific operation, we have quite a diverse crew of UNIX machines floating around out there resigned to their fates sitting in the corner running the oldest equipment at their respective labs.  Any time I've had to interact with any of these I've been grateful for not taking various post-Bourne shell quirks for granted.  Not that these interactions are frequent, but I find myself tapped often being "that UNIX guy" on the team.  A couple examples come to mind.

One facility is running two pieces of equipment the software for which runs on Digital UNIX circa mid 90s.  The data transfer mechanism was some FTP thing their previous technical director had cooked up and one morning we had found it went down.  The resident IT guy there knew the basics of how to get in there, but hadn't really put the process down anywhere.  Luckily (security may think otherwise...) I was able to connect over rsh with the password he provided and was able to modify the script for that exporter to self-heal.  I don't know what shell it was running beyond it spitting a '$' out at me, but luckily didn't have to know.

The other is a lab using a data analysis system for, among others, HP-UX.  I don't recall the age of the version they were running on, but the system is called Target and was eventually forked in a few directions when the original company closed up shop, our group inheriting one of the forks.  It's one of those things I hope I can archive publicly someday, but not there yet.  In any case, the technicians all had Windows PCs with an X11 server setup for accessing the HP-UX machine, and it was running CDE if that helps date it (unless that's still default).  That system is in archive now as we've replaced it with the current version of our fork which is now .NET.  I was surprised they didn't have more UNIX going on, but they had managed to get a lot of their older equipment to work with some sort of Windows based solution one way or another.  Life finds a way...

I'm not sure where it stands as far as the sea of shells these days, but one I've opted towards in system builds the past few years is dash.  It's pretty small and seems to hit all the marks as far as basic Bourne-ish behavior and POSIX stuff.  When I'm tinkering on a board and just need to toss a shell on top of a kernel, I go for dash.

- Matt G.

------- Original Message -------
On Monday, January 2nd, 2023 at 1:19 PM, Dan Cross <crossd at gmail.com> wrote:


> On Mon, Jan 2, 2023 at 4:07 PM Clem Cole clemc at ccc.com wrote:
> 
> > On Mon, Jan 2, 2023 at 4:03 PM Dan Cross crossd at gmail.com wrote:
> > 
> > > Couldn't you also ship a shell? That kinda seems like the simplest solution.
> > 
> > Sure the problem is -- where do you stop?
> 
> 
> Good question. But this sort of suggests that maybe it's not the shell
> that's really the problem, but the entire milieu of all the tools that
> we use when we write "shell scripts."
> 
> > The result is the fork/mess called Gnu.
> 
> 
> BUGS: Yes.
> 
> - Dan C.


More information about the TUHS mailing list