Feature: Add 'File' support that can cross the curly-block barrier

[aghast]

Presently, the grammar supports redirection using hard-coded numbers, nothing else.

{ foo 2> error.log }

Notably, there is no mechanism for variable expansion within a redirection:

{ foo $out_fh> error.log }

In addition, there does not appear to be a way to pass file across the {}-barrier from "hush code" to "command code". For example, there isn't a way to open a file, advance to a particular offset, then begin writing to that position in the file from a command block:

fh = fopen('some_file.txt')
fseek(fh, 100)
{ foo > $fh }

Note:

This seems like an obvious "new type". It might be a dictionary wrapped around something (a bunch of methods, plus some internal data like fileno or something), but it kind of sets the stage for "How do you add new types that require compiled code for support?" So that is probably an important question to answer, too!

[gahag]

For conditionally redirecting stdout/stderr, you can do something like:

if condition then
  { command > file } # redirect from stdout
else
  { command 2> file } # redirect from stderr
end

As redirecting other file descriptors besides stdout and stderr is extremelly rare, I believe this is good enough for now.

Regarding overwriting a file from a given offset, as far as I'm aware, not even bash is capable of doing so. You may do something like cat <(head -100 $file) <(foo) > $file, but that's an workaround, and will face issues like overwriting the file before reading. I'm not sure it's a fairly common use case, but even so I'd do something like:

{
  head -100 $file > $file.tmp
  foo >> $file.tmp
  mv $file.tmp $file
}