Re: Are there any plans for more readable, modern syntaxes for If statements?

[George]

On Sun, 2020-03-29 at 01:55 -0700, John W wrote:
> On 3/26/20, George <
> tetsujin@scope-eye.net
> > wrote:
> > On Thu, 2020-03-26 at 19:05 +0200, Vaidas BoQsc wrote:
> > 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.
> 
> I can almost hear the same thoughts going through Larry Wall's head 30+
> years ago (:

I think it's fair to say that when people have ideas to make things "better" 
it's not always so...  And that applies to me, too. Looking to Perl -
personally there's a lot I don't like about it, but it *is* a more capable 
language than Bash.

> > $ 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
> 
> Are you familiar with

Yes. :)

> ...Bash's <(...) syntax?
> Your example could be written (if I understand right):
> 
>   $ some_command -file1 <(cat ./first_file) -file2 <(cat ./second_file)

If you look at it that way one could as easily just say "-file1 ./first_file", 
etc. Also process substitution doesn't provide the command with file
handles to those files, it gets pipes carrying the data from those files. (So 
it's non-seekable, for instance, strictly sequential.)

The idea behind this pattern is that the shell, or some tool accessed from the 
shell, would do some nontrivial or specialized work associated with
opening that "file" (i.e. use some privileges or authentication to open the 
file, and pass it to a sandboxed process) - tasks that would be outside
the scope of the tool which is being handed that file. Though of course the 
simple file redirection example would be pretty limited for that - and in
terms of syntax it would be better to have something which, like process 
substitution, does the redirect and substitution all in one place. But the
idea here is that the shell already has this syntax, and IMO this is an example 
of a case where a specific decision about how to implement a common
feature can impact what you can do with it.

I think the only case I've seen of a Unix command that accepts a file 
descriptor number this way is "xterm", which lets the caller provide a PTY
instead of having xterm create its own. So it's a pretty speculative example I 
threw out there, to be fair.