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(a)gmail.com> wrote:
On Mon, Jan 2, 2023 at 4:07 PM Clem Cole clemc(a)ccc.com
wrote:
On Mon, Jan 2, 2023 at 4:03 PM Dan Cross
crossd(a)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.