6 Jul
2018
6 Jul
'18
9:38 p.m.
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