| >I didn't get your solution below because "local_variable" is actually a global. A global in a subshell, so the caller's globals aren't affected. >Also, someone once said "it's easier to port a shell than a shell script". Yeah, but it's pretty damn presumptuous to make someone install some random shell on my machine to build your code, imo. The same goes double for e.g. GNU coreutils extensions, since I have to set up some kind of separate root for you where true --version works (ditto for assuming /bin/sh is bash, or even dash so you can use 'local'). It's like encouraging people to use a fucked up version of libc where the args to strcat are reversed. Fuck that. The standard exists to define the environment. Sometimes it's within reason to have dependencies outside of that - but the shell is a good example of where the case for it is very weak. For the record, my motivations for working on Simon's mrsh project is basically 50:50 between "I want to support POSIX-compatible shell scripts" and "I want a POSIX shell whose interactive mode isn't dogshit". Both are equally important to me. >EDIT: Also I think there's no problem adding local variables to POSIX, since all shells implement the same way as far as I can tell. That would be the much better solution, rather than trying to convince people to use only globals. That's all well and good. The Austin Group has public meetings, a public bug tracker, and a public mailing list. Go there and make a case for it! But be prepared for "all shells" to include more than dash, bash, ksh, and zsh. >There are many useful / real shell scripts that are thousands of lines long, so you really need locals. Length of shell script is not directly correleated for need for locals. |
Is it more presumptuous to make people install a language you used than to make them install a library you used? Either way people need to get your dependencies if they want to run your code.
> The standard exists to define the environment.
Standards are great, but not all environments need to be standard. Most shell scripts don't need to be ported to dozens of different platforms, and most shell script authors would be much better served by a language with fewer weird gotchas, saner semantics, and the benefit of a lot of language research that's happened in the past few decades. For instance, as I've been porting my personal shell scripts to Rash (my shell in Racket), I've been able to use all the patterns I use in posix shells but with benefits of better readability, easier reasoning, better means of abstraction, etc. It's been a solid win that I would recommend to anybody. Sure, if someone else wants to run my scripts they need to install Rash. But few people (in practice: nobody) are really interested in running my personal shell scripts besides myself. If somebody does want to run them, installing the dependencies is not very hard.
There is a small set of scripts that needs to be portable and be written in a shell-like language. Until standards catch up, posix is perhaps the best thing we have. But most of the time when people write shell scripts they could be writing in any language but choose shell because they want to automate something they do manually or they really want a processes-and-files DSL. Choosing a better shell that fits the processes-and-files domain and allows easy interactive use with better features and less insanity in these situations is a slam dunk.