A real downside is that the exec 6>&1 > ${CONSOLE_REPORT_FILE} is doing something different: doWork can’t access “the real” standard output (via fd 6) if it needs to. I sometimes use this trick also to tee off to md5sum for checksums.
I find it easy enough to agree that file opens/closes could be less weird, but it’s hard to imagine a world where I can’t do these things.
Also, you may have missed that builtin-bugsystem.sh wants to print the contents of the report - logic that suggests the (original) author just didn’t know about tee.
Yes, Oil will likely just have a C-ish / Python-ish file descriptor API and syntax. You wont’ use “6” literally, but you can use two file descriptors at the same time like any “real” programming language!
This is totally thinking aloud, but it could just be:
fd1 = open(CONSOLE_REPORT_FILE)
with redir(stdout, fd1) as fd2 { # fd2 is what stdout was saved to
echo hi # builtin output to disk file
ls # external output to disk file
echo hi > !fd2 # goes to original stdout, ! means file descriptor
} # fd state restored unconditionally here, like Python with
close(fd1)
And yes it seems like they could have just used tee.
Yes stdin, stdout, stderr would be the same as in C – 0, 1, and 2.
To distinguish it from a filename, you could spell it with the !:
echo hi > !2 # like echo >&2 in bash
echo hi > !stderr # same thing as above
echo hi !1 > !2 # like echo 1>&2 in bash, which is the same as >&2
echo hi !1 > !stderr # same as above
echo hi !stdout > !stderr # verbose way of saying it
Some people will like the names, but 0 1 and 2 are also good abbreviations for people comfortable with shell.
On the other hand, I don’t want anything but 0, 1 and 2, and 2 would be the most common.
I couldn’t agree more about this exec line noise - it takes a lot of mental gymnastics to figure out what even is happening in what parts of the program. One thing that I have found non-{0,1,2} FDs useful for however is when tools (e.g. gpg) take a --passphrase-fd argument, useful for when you are also redirecting some other thing into stdin.
The author’s example of with redir would be excellent - making it much clearer how the dup gymnastics work.
A real downside is that the
exec 6>&1 > ${CONSOLE_REPORT_FILE}is doing something different:doWorkcan’t access “the real” standard output (via fd 6) if it needs to. I sometimes use this trick also to tee off to md5sum for checksums.I find it easy enough to agree that file opens/closes could be less weird, but it’s hard to imagine a world where I can’t do these things.
Also, you may have missed that builtin-bugsystem.sh wants to print the contents of the report - logic that suggests the (original) author just didn’t know about
tee.Yes, Oil will likely just have a C-ish / Python-ish file descriptor API and syntax. You wont’ use “6” literally, but you can use two file descriptors at the same time like any “real” programming language!
This is totally thinking aloud, but it could just be:
And yes it seems like they could have just used
tee.Some protocols (like djb’s checkpassword or doit) rely on specific file descriptors though:
Is
stdoutthe same as1? Or is it something else?Yes
stdin,stdout,stderrwould be the same as in C – 0, 1, and 2.To distinguish it from a filename, you could spell it with the !:
Some people will like the names, but 0 1 and 2 are also good abbreviations for people comfortable with shell.
On the other hand, I don’t want anything but 0, 1 and 2, and 2 would be the most common.
I couldn’t agree more about this
execline noise - it takes a lot of mental gymnastics to figure out what even is happening in what parts of the program. One thing that I have found non-{0,1,2} FDs useful for however is when tools (e.g.gpg) take a--passphrase-fdargument, useful for when you are also redirecting some other thing into stdin.The author’s example of
with redirwould be excellent - making it much clearer how thedupgymnastics work.