You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ah I see, thank you. I was not aware you could close file descriptors stored inside a variable or array. So the parser indeed thinks that you wrote exec {foo[1]} >&-. This will require a bit of an internal refactor to add support for the syntax.
For my own convenience, here's the relevant bit of the docs:
Each redirection that may be preceded by a file descriptor number may instead be preceded by a word of the form {varname}. In this case, for each redirection operator except >&- and <&-, the shell will allocate a file descriptor greater than 10 and assign it to {varname}. If >&- or <&- is preceded by {varname}, the value of varname defines the file descriptor to close. If {varname} is supplied, the redirection persists beyond the scope of the command, allowing the shell programmer to manage the file descriptor’s lifetime manually.
I just got hit by this one as well 😄 Is there a way to disable this behavior for a file or a line? currently it blocks any usage of shfmt due to breaking flock usage like this
exec {lock_fd}>"$file"# (...)exec {lock_fd}>&-
being turned into
exec {lock_fd}>"$file"# (...)exec {lock_fd} >&- # notice the space here
Activity
mvdan commentedon Aug 16, 2021
I'm not sure I follow what the
execline is doing. What's the syntax there, and where is it documented?jmcantrell commentedon Aug 22, 2021
It's closing the file descriptor stored at index 1 of the
fooarray. The previouscoproccommand puts file descriptors into the array.The syntax for both closing a file descriptor and providing the file descriptor using a variable are described in the second paragraph here: https://www.gnu.org/software/bash/manual/bash.html#Redirections
And since there can't be any space between the file descriptor and the redirection, it produces the error.
mvdan commentedon Aug 31, 2021
Ah I see, thank you. I was not aware you could close file descriptors stored inside a variable or array. So the parser indeed thinks that you wrote
exec {foo[1]} >&-. This will require a bit of an internal refactor to add support for the syntax.For my own convenience, here's the relevant bit of the docs:
jippi commentedon Feb 10, 2024
I just got hit by this one as well 😄 Is there a way to disable this behavior for a file or a line? currently it blocks any usage of
shfmtdue to breakingflockusage like thisbeing turned into
Perhaps some other workaround?
[-]shfmt is changing some valid code into invalid code[/-][+]syntax: support {varname} redirects[/+]c0m1c5an5 commentedon May 6, 2025
@jippi For now, a workaround is to eval your command as a string:
syntax: add a regression test for issue #719
syntax: support array elements in {varname} redirects