[COFF] Other OSes?

[gtaylor at tnetconsulting.net (Grant Taylor)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3847 bytes --]

On 07/05/2018 02:49 PM, Steve Johnson wrote:
> My two examples of this are editor scripts and shell scripts.

Will you please elaborate on what you mean by "editor scripts"?  That's 
a term that I'm not familiar with.

I feel like you're talking about automating an editor in one way or 
another.  Redirecting standard input into ed (ex, etc) comes to mind.

As does vi(m)'s ex command mode.  Regular expressions, macros, and the 
likes start waiving their arms like an anxious student in the back of 
the class.

There's also Vim's vimscript language that is black magic to me.

> 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.

I too have always written lots of shell scripts.  Granted, most of the 
one off shell scripts are long / nested command lines and not actually 
script files.  At least not until I need to do something for the 2nd or 
3rd time.

I use the following single line script daily if not hourly.

/usr/bin/xsel -ob | /bin/sed 's/^\s*>\{1,\}\s\{1,\}//;s/^\s*//' | 
/usr/bin/fmt | /bin/sed ':a;N;$!ba;s/\n/ \n/g;s/ \n \n/\n\n/g;s/\n 
\n/\n\n/g;s/ $//' | /usr/bin/xsel -ib

It is derived from a very close variant that works without the leading 
/^>+\s/

> 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 oin 10 files got a 
> lot more tedious.

I don't understand that at all.  How did glass ttys (screens) change 
what people do / did on unix?

Granted, there is more output history with a print terminal.  There are 
times that I'd like more of that, particularly when my terminal's 
history buffer isn't deep enough for one reason or another.  (I really 
should raise that higher than 10k lines.)

What could / would you do at a shell prompt pre-glass-TTYs that you 
can't do the same now with glass-TTYs?

I must need more caffeine as I'm not understanding the difference.

> With the advent of drag and drop and visual interfaces, shell scripts 
> evaporated as well.

Why do you say that?  If anything, GUIs caused me to use more shell 
scripts.  Rather, things that I used to do as a quick one off are now 
saved in a shell script that I'll call with the path to the file(s) that 
I want to act on.

On Windows I'd write batch files that worked by accepting file(s) being 
drug and dropped onto them.  That way I could select files, drag them to 
a short cut and have the script run on the files that I had visually 
selected.  (I've not felt the need to do similar in unix.)

> Once again, doing something on 10 files got harder than before.

Why did it get harder?  Could you no longer still use the older shell 
based method?

Or are you saying that there was no good GUI counterpart for what you 
used to do in shell?

> I still use a lot of shell scripts, but mostly don't write them from 
> scratch any more.

I too use a lot of shell scripts.  Many of them evolve from ad-hock 
command lines that have grown more complex or has been needed for the 
3rd time.

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

I don't know what I'd add back as I feel like they are still there.

I also think that the CLI is EXTREMELY dynamic and EXTREMELY flexible. 
I have zero idea how to provide a point and click GUI interface that is 
as dynamic or flexible.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20180706/4508fa07/attachment.bin>