From: cross@spitfire.i.gajendra.net   
      
   In article <10hnpjg$2648n$1@paganini.bofh.team>,   
   Waldek Hebisch  wrote:   
   >Lawrence D’Oliveiro  wrote:   
   >> On Sat, 06 Dec 2025 11:42:47 +0100, Marc Van Dyck wrote:   
   >>   
   >>> User written lexical functions, on the other hand, would be a real   
   >>> bonus. There are, for one, still many parts of the operating system for   
   >>> which you need to get information, and the only possible way to do it is   
   >>> to parse some output (think of everything TCP/IP, for example), while   
   >>> there is a callable interface available to get the info properly.   
   >>   
   >> POSIXish shells seem to feel less need for such built-in extensions.   
   >>   
   >> Is this a reflection on the ease of doing command substitutions in them,   
   >> vis-à-vis DCL?   
   >>   
   >> Some newer commands in the Linux world have the option to produce output   
   >> in JSON format, which also helps.   
   >   
   >First, backwards compatibility is a powerful force blocking   
   >possible improvement.  I was using Sun OS and Solaris in   
   >nineties.  Later I looked at Solaris from 2007.  In 2007   
   >they shipped crappy '/bin/sh' which had exactly the same   
   >problems as I remembered from my earlier use.  I suspect   
   >that it was bug-for-bug compatible with '/bin/sh' which   
   >they shipped in 1984.  And I suspect that if you get   
   >current Solaris from Oracle, you will get the same crappy   
   >'/bin/sh'.   
      
   It is true that Solaris/illumos put large, perhaps almost   
   excessive, emphasis on stability and backwards compatibility.   
   However in this case, the criticism is a bit unfair.  As you   
   sort of alude below, on Unix systems, command interpreters are   
   interchangeable.  Both Solaris and illumos ship with multiple   
   shells, and the preference is to write scripts using ksh93, not   
   /bin/sh.  That said, I will grant you that it is annoying to   
   have to assume the subset of behavior defined by 7th Edition   
   research Unix for "portable" shell scripts, and increasingly   
   even that is tenuous on Linux systems.   
      
   >The same forces that prevent improvments to '/bin/sh' work   
   >for DCL, so chance of change here is very small.   
   >   
   >Second, early Unix had relatively cheap process creation,   
   >but some implementations (PDP-11 and 16-bit Xenix) had   
   >thight limit on process size.  So, there was preference   
   >to using external commands for extentions.  Unix provides   
   >commands (and /proc filesystem in Linux) so that information   
   >is available in textual form, meaning less need for   
   >libraray API.   
      
   Not only is there less need, it would have been rather difficult   
   in early Unix.  There was little sharing going on back then; I   
   think some of that was a reaction to the complexity of sharing   
   in Multics.  It took 20-ish years to get shared libraries, and   
   even then the model that won was based on TENEX and GENIE.   
      
   >Third, Unix shell does not play as distingished role as   
   >DCL in VMS, users can have different shells.  There are   
   >scripting languages and for programming shell is just   
   >one of available scripting languages.  Some scripting   
   >languages (like Perl) give access to system calls, most   
   >have FFI, so that one can call code in shared libraries.   
      
   Indeed.   
      
   However, I'll go out on a limb and say that, whatever the   
   limitations of DCL, Unix shells aren't particularly good   
   programming languages, and would be a bad model to emulate.   
   They spend too much effort trying to thread the needle between   
   being interactive command interpreters, with all of the rich UI   
   semantics that demands, _and_ being programming languages; in   
   areas where these conflict, the experience is usually mediocre   
   for both.   
      
   One feels that, in a sense, both Unix and VMS suffer from lack   
   of clear separation here, but on balance, VMS is probably better   
   suited to address that precisely because of the privileged   
   position of DCL in the overall system.  _If_ the user's state   
   were represented by well-defined objects with clear interfaces,   
   then one could imagine a programming language that would be   
   co-equal to a command interpreter, but that was _just_ a   
   language interpreter, and not a shell; the shell similarly would   
   be just a shell, and not a programming language interpreter.   
      
   By way of example, one might look to z/VM and CMS and the way   
   that REXX and XEDIT are integrated into the environment; REXX is   
   not a command interpreter, but one can easily write the   
   equivalent of shell scripts in it.  Similarly, XEDIT is a text   
   editor, but REXX scripts can "address", thus making it possible   
   to implement REXX programs with TUIs that leverage the   
   (considerable) power of the text editor.  The result is a   
   plethora of very rich, yet highly consistent, text-oriented   
   interfaces: the file and mail readers, the help system, etc.   
      
   Implementing this in a general way for a Unix-style system would   
   be, essentially, impossible.  And while it would be a heavy lift   
   for VMS, I imagine it would at least be possible.   
      
   Would it be worth it, though?  Particularly vis an incremental   
   improvement to the existing system?  I kind of doubt it.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)