On Thu, 2020-03-26 at 19:05 +0200, Vaidas BoQsc wrote:
> I keep on wondering why these shells can't come up with something better
> than improving previous shell syntax by little by only providing poor
> better alternatives.
> I somehow think there is a need to rethink shells from scratch to make them
> less mentally demanding and readable in the command prompt and scripts
> themselves.
>
This is an interest of mine as well. Shells are an interactive programming
environment built on the idea of combining other programs to solve
problems. I feel they should not just suffice in those roles, but excel at
them. And to that end I think shells would really benefit from things like
more powerful data structures, better facilities for passing complex data to,
and parsing complex data from different programs, better scoping, better
file handling, and clean-up of various language and implementation details that
currently tend to trip people up. (subshell forking, the word
splitting and globbing rules that kick in when you don't quote absolutely
everything, etc.)
That said I'm not entirely sure there's room for a fresh take on the shell
(another one, I mean - Powershell exists) - I expect a lot of shell users
at this point are traditionalists who want the shell to be what it is. I think
that is basically why we don't see a lot of innovation in shells these
days, and I don't think we'll see much in Bash.
I think there is room for shell implementations to innovate even without
radically departing from tradition - for instance better support for NUL as a
delimiter in built-in tools (and allowing it to be stored in parameters as
well) can have a pretty big impact on how the shell can interact with other
tools. There's also frequently some flexibility in how certain established
features behave. For instance, I think it would be quite natural for a
pattern like this:
$ some_command -file1 $fd1 -file2 $fd2 {fd1}<./first_file {fd2}<./second_file
to work as a substitute for this:
$ exec {fd1}<./first_file {fd2}<./second_file # open files, store file
descriptor numbers in parameters
$ some_command -file1 $fd1 -file2 $fd2
$ exec {fd1}<&- {fd2}<&- # close files
That is, open the files just for the command being run (because that's how
redirections work) and make the parameters storing the file descriptor
numbers available before expanding parameters in the command, so you can pass
them to the command. This is not how Bash handles a command like this -
my point here is not to reopen that discussion, rather just to illustrate the
possibilities.
