[COFF] Other OSes?

[Theodore Y. Ts'o]

On Thu, Jul 05, 2018 at 01:49:58PM -0700, Steve Johnson wrote:
> My two examples of this are editor scripts and shell scripts.   In
> the day, I would write at least one shell script and several editor
> scripts a day.  Most of them were 2-4 lines long and used once.  But
> they allowed operations to be done on multiple files quite quickly and
> safely.

Before making such generalizations, I think it's wise to state more
clearly what you have in mind when you say "shell script".  I use
shell scripts all the time, but they tend to be for simple things that
have control statements, and thus are not 2-4 lines long, and they
aren't use-just once sort of things.

For example, my "do-suspend script":

#!/bin/bash

if [[ $EUID -ne 0 ]]; then
   exec sudo /usr/local/bin/do-suspend
fi

/usr/bin/xflock4
sleep 0.5
echo deep > /sys/power/mem_sleep 
exec systemctl suspend

I use this many times a day, and shell script was the right choice, as
it was simple to write, simple to debug, and it would have been more
effort to implement it in almost any other language.  (Note that I
needed to use /bin/bash instead of a PODIX /bin/sh because I needed
access to the effective uid via $EUID.)

Your definition of "shell scripts" and "editor scripts" that have
disappear seem to be one-off things.  For me, those have been replaced
by command-line history and command-line editing in the shell, and as
far as one-off editor scripts, I use emacs's keyboard macro facility,
which is faster (for me) to set up than editor scripts.

> With the advent of glass teletypes, shell scripts simply evaporated --
> there was no equivalent.  (yes, there were programs like sed, but it
> wasn't the same...).  Changing, e.g., a function name in 10 files
> got a lot more tedious.

So here's the thing, with emacs's keyboard macros, it's actually not
tedious at all.  That's why I use them instead of editor scripts!

Granted, somewhere starting around 10 files I'll probably end up
breaking out some emacs-lisp for forther automation, but for a small
number of files, using file-name completionm and then using a handful
of control characters per file to kick off the keyboard macros a few
hundred times (C-u C-u C-u C-u C-u C-x C-e) ends up being faster to
type than consing up a one-off shell or editor script.  (Because,
basically, an emacs keyboard macro really *is* an editor script!)

> What abstraction mechanisms might we add back to Unix to fill these
> gaps?

What do you mean by "Unix"?  Does using /bin/bash for my shell scripts
count as Unix?  Or only if I strict myself to a strict Unix V9 or
POSIX subset?  Does using emacs count as "Unix"?  What about perl?  Or
Python?

Personally I all consider this "Unix", or at least "Linux", and they
are are additoinal tools which, if learned well, are far more powerful
than the traditional Unix tools.  And the nice thing about Linux
largely dominating the "Unix-like" world is for the most part, I don't
have to worry about backwards compatibility issues, at leasts for my
personal usage.

For scripts that I expect other people to use, I still have the reflex
of doing things as portability as possible.  So for example, consider
if you will, mk_cmds and its helper scripts, which is part of a port
of Multics's SubSystem facility originated with Kerberos V5, and is
now also part of ext2/3/4 userspace utilities:

https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ss/mk_cmds.sh.in
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ss/ct_c.sed
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ss/ct_c.awk

My implementation of mk_cmds was designed for ultra-portability (as
in, it would behave identically on Mac's AUX, IBM's AIX, Solaris (with
either a SunSoft or GNU toolchain), OSF/1, Linux, etc.).  To do this,
the above scripts use a strict subset of POSIX defined syntax and
behaviours.  And it's a great use of shell, sed, and awk scripts,
precisely because they were available everywhere.

The original version of mk_cmds was implemented in C, Yacc, and Lex,
and the problem was that (a) this got complicated when cross
compiling, where the Host != Target architecture, and (b) believe it
or not, Yacc and Lex are not all that standardized across different
Unix/Linux systems.  (Between AT&T's Yacc, Berkeley Yacc, and GNU
Bison, portability was a massive and painful headache.)

So I solved both problems by taking what previously had been done in
C, Yacc, and Lex, and using shell, sed, and awk isntead.  :-)

   	     	      	    	   	    - Ted