Re: [COFF] Other OSes?

On Thu, Jul 05, 2018 at 01:49:58PM -0700, Steve Johnson wrote: 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. 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 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… 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